Narrative Minutes interim-2020-iesg-02 2020-01-23 15:00
narrative-minutes-interim-2020-iesg-02-202001231500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-01-23 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
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
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
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Erik Kline
Tommy Pauly

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes from January 9? Hearing
none, so we'll get those posted. I saw final updated narrative minutes from
January 9; is there any objection to approving those? Hearing none, so we'll
get those posted as well.

1.4 List of remaining action items from last telechat

     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: That's still in progress, thanks.

     o Alexey Melnikov to think about how to analyze how successful WGs and
       protocols are and why they failed or not.

Alexey: All of my items are in progress.

     o Martin Vigoureux with Wes, and Alvaro to work on some
       mechanism to obtain wider or private feedback from people who are
       disenfranchised; anonymous flagging of offensive emails to inform
       leadership; more opportunities for private feedback.

Martin: No update from my side.

     o Alvaro Retana with Warren, Alexey, Martin, Barry, and Roman
       to work on more transparency in the Datatracker about how long each
       phase of doc process takes / New datatracker flag to indicate who
       has the ball, area directors, authors, or chairs.

Alvaro: This is in progress, as are my other ones.

     o Alexey Melnikov and Warren Kumari to add keyword tags to WG charters
       to identify specs that pertain to some general concept.

In progress as noted above.

     o Alvaro Retana to work on a framework for analyzing new proposals.

In progress as noted above.

     o Adam Roach to work on a virtual social room for remote attendees
       (promoting #hallway)

Adam: I got some text to Warren yesterday and he's put it up on the affiliates
group page. I think we can consider this one closed for now.

     o Warren Kumari to work on acknowledging shepherds, directorate
       reviewers in a more standardized/formal way.

Warren: Still ongoing.

     o Alexey Melnikov to organize IoT overview discussion with interested
       ADs.

In progress as noted above.

     o Ignas Bagdonas to write a draft of an IoT Systems charter.

Amy: We'll mark that as in progress for him since he's not here.

     o Alvaro Retana and Adam Roach to look at updating the I-D Checklist.

In progress as noted above.

     o Roman Danilyw to find designated experts for RFC-ietf-lamps-cms-mix-
       with-psk [IANA #1156116].

Amy: We'll mark this as provisionally done since this is on the agenda as a
management item.

     o Roman Danilyw to find designated experts for RFC 8471 [IANA
       #1156118].

Roman: I have an inquiry out to some folks and hope to have this resolved next
time.

     o Eric Vyncke to write up draft text on Special Interest
       Groups and send to the IESG for comment.

Eric: Still in progress.

     o All IESG to submit their metrics data priorities to Roman (deadline
       January 23, 2020).

Amy: The deadline for this is today and I know a few of you still need to do
this.

     o Roman Danyliw to collect feedback from the IESG on the metrics
       data priorities for the IESG to discuss at a future meeting.

Roman: That future meeting will hopefully be at next week's telechat.

Adam: Incidentally, Roman, when I was going through this doing my own I noticed
there was a section added to the document that had no corresponding row in the
spreadsheet. I went ahead and added it and put my number in there, but I think
I'm the only one with a number now.

Roman: Thank you for catching that issue. I'll send a poke to everyone to help
fill out that row.

     o Ben Kaduk, Alvaro Retana, and Suresh Krishnan to skim the ietf@ietf
       list and collect a list of topics that seem to be the major concerns
       for the community from recent discussion threads.

Ben: Still in progress; we just agreed to sync up next week.

     o Martin Vigoureux to put together a proposal on disambiguating side
       meetings from IETF meetings.

Martin: I'll submit something in the course of next week.

     o Magnus Westerlund to draft an IESG Statement regarding the IETF
       as the default change controller for IANA Registration requests.

Magnus: Ongoing.

     o Suresh Krishnan to draft a "best errata practices" document and
       post it on the IESG Wiki.

Suresh: That's still in progress.

     o Adam Roach to draft a message to the WG Chairs email list
       regarding the ability to dispense with milestone dates in the
       datatracker.

Amy: I saw some email on this but I'm not sure I saw it on the wgchairs list.

Adam: It didn't go out. I wanted to make sure people made comments if they
wanted to. If anyone has any objections to the text, there was one suggestion
that sounded good that I was going to take. Please look at this now and let me
know because I intend to send this as soon as the call ends.

     o Roman Danyliw to find designated experts for RFC 7636 [IANA
       #1160634].

Amy: We added this yesterday, so you know you're on the hook for that.

Roman: I already sent out some requests.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-intarea-provisioning-domains-10  - IETF stream
   Discovering Provisioning Domain Names and Data (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: Not really. I think everything is in progress and all the positions are
clear; the authors have responded and I think we'll converge over email. Is
there anything you want to discuss, guys?

Adam: I'm happy. Thanks.

Suresh: I just asked the authors to not submit before the telechat so people
didn't get confused with versions so they should submit a new draft soon now.

Amy: So it sounds like it's going to get a Revised ID shortly and we can move
on.

 o draft-ietf-regext-login-security-07  - IETF stream
   Login Security Extension for the Extensible Provisioning Protocol
   (EPP) (Proposed Standard)
   Token: Barry Leiba

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

Barry: We do not. Just put it into Revised ID Needed, please.

Amy: Okay, we can move on.

 o draft-ietf-pce-stateful-flags-00  - IETF stream
   Updated Rules for Processing Stateful PCE Request Parameters Flags
   (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I'd prefer not because the authors are already discussing with Alvaro
and among themselves on how they want to handle this, because it may affect
other documents.

Amy: Okay. So it sounds like it might require a Revised ID?

Deborah: Yes, definitely.

Amy: Great; this will stay in IESG Evaluation, Revised ID Needed and we can
move on.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-nottingham-rfc7320bis-03  - IETF stream
   URI Design and Ownership (Best Current Practice)
   Token: Adam Roach

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

Adam: I have a quick question for Benjamin, do you want us to spin a new
version of this taking your nits into account? I haven't had time to look over
your review yet.

Ben: I don't think it needs to get a new ID. These are all minor things.

Adam: Okay, so let's call this approved. I might put an RFC Editor note on it
once I read Ben's comments. I think this is good to go.

Amy: Do you want us to wait for you to tell us it's good to go?

Adam: Let's do Approved, Announcement to be Sent. At a quick glance these look
minor and if they need changes I can do it in an RFC Editor note.

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

 NONE

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-carpenter-limited-domains-00
   IETF conflict review for draft-carpenter-limited-domains
     draft-carpenter-limited-domains-12
     Limited Domains and Internet Protocols (ISE: Informational)
   Token: Suresh Krishnan

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

Suresh: I'd like to. I did go through all the ballot comments and I agree with
many of the points that were made. Specifically the initial ones that came up
like Mirja's. One thing I just don't see the possibility of is disrupting IETF
work, which is probably what the conflict review is about. I have a harder time
believing that. But other than that I don't have objections to what's being
proposed. 5742 does give us a limited set of responses. Like Alvaro said we
could say it's related to work being done in IETF or like Barry said and put in
a list of WGs. One of them is the 'related to IETF work' without saying
anything. I'd think it's stating the obvious; most of the time something from
the independent stream is somehow related to the IETF. I think we can discuss
it but it's mostly going to be the case. I'm thinking about putting in the WGs,
I'm worried we'd miss out something it's relevant to and it becomes
counterproductive. That's my train of thought but I'm really open to hearing
from everyone.

Warren: I think a while back we had a discussion about the specific answers we
could provide and sort of agreed that the list of things we could provide were
things we could tweak slightly. I like the answer 'this is related to work
that's happening in the IETF but I don't think that it conflicts' so basically
the number 2 option but without listing specific WGs. That's not exactly a
quote from the RFC but I think we can just say this is related to work in the
IETF in a number of WGs but it doesn't prevent publishing. So Barry's thing
without the list of groups.

Suresh: Works for me.

Mirja: I'm fine with that as well. I'm maybe slightly more worried this could
be disruptive in the IETF but this is also a worry that I don't think anything
actually in the document would be directly disruptive, but the way people
interpret it, and that's probably not a good reason to say it's conflicted. So
a variation of option 2 is fine for me.

Suresh: So can I change this to exactly what Alvaro suggested, if no one has an
issue with that?

Barry: That works for me.

Suresh: Thank you very much, folks. Mirja, one of the things that made made not
worry about that - the future IESGs are going to say that if you're going to
use ISE stuff for reducing security requirements, I can see Ben and Roman
throwing in a Discuss faster than they can read the draft.

Warren: A lot of people believe that limited domains are perfectly fine and
always going to work, and nothing we can do is going to dissuade them from
that. So I don't think this document makes it better or worse, it simply
informs people. Those who believe their limited domains are perfectly
leak-proof will continue to believe that. Which is why initially I was unhappy
about this but after reading it I think this provides information to people
designing limited domains, points out the sharp edges, and so makes the
situation better.

Suresh: Sounds good. So I'll change the conflict review response. I'll change
the text and check back again tomorrow if everybody's happy.

Mirja: Should I clear as soon as you change or should I wait?

Suresh: I did put in the new text.

Mirja: Okay. I will.

Suresh: So this is pretty much Alvaro's text with Barry's change but a little
more fuzzy, saying multiple IETF working groups. Amy, just keep this on hold
until we resolve it. I'll send you a note.

Amy: It will sit in Approved, Point Raised once Mirja clears her discuss. So
we'll just wait for you to say it's good to go.

 o conflict-review-google-self-published-geofeeds-00
   IETF conflict review for draft-google-self-published-geofeeds
     draft-google-self-published-geofeeds-07
     A Format for Self-published IP Geolocation Feeds (ISE:
   Informational)
   Token: Alissa Cooper

Amy: I have a Discuss in the tracker. Unfortunately Alissa is not here to
discuss it, but would the group like to?

Magnus: Yeah, maybe a bit. I wanted a discussion more than anything else. How
do we deal with this situation? I don't think it's good form, it's the
intention to reference something which isn't existing so to say.

Barry: I agree with you. I was thinking of putting a Discuss on for the same
thing and didn't.

Warren: I should first disclose I'm an author. What if we modify this to say
"The IESG has concluded this is related to work that was previously done in the
GEOPRIV wg?" I think it's useful for the conflict review to note that the work
is related to stuff that was previously done, just so people know we've been
paying attention, but I don't see it's a conflict.

Barry: I would support that.

Magnus: It sounds fine. I need to review guidance for this. We're a bit beyond
what the intention was.

Mirja: Maybe we should look this up. I believe we did this at least once before
where we referenced a concluded WG and mentioned that it was concluded.

Adam: The way I think about this is, if we wanted to for example say 'something
should not be published because it should be put to the IETF, citing a
concluded WG in that context is perfectly fine. So for example, if someone
wanted to put something to the ISE that modified some core behavior in, say,
XMPP, we would probably have grounds to say this should not be published
because it conflicts wth work previously done in XMPP working group. If we can
cite that sort of thing, then the ... [crosstalk]

Magnus: But in that case you could say it violates the IETF stream RFCs and try
to change the behavior.

Adam: Right. But the flip side of that coin is that we can say even though it
corresponds to work that was done in a particular WG there's not a relationship
that prevents publishing. In that context I think including concluded WGs in
this kind of response is perfectly fine.

Magnus: I'm fine with noting that it's closed.

Adam: I think that should be added and that's a good change. With that
modification I think citing GEOPRIV in particular is the correct thing to do.

Warren: At some point we might want to go through and think about updating RFC
[5742] to make it clear that what should be communicated is what the IESG
thinks, not here are four options you can choose and you have to stick to
those. I think this should fall into Spencer's "do the right thing" and the
reason for there being a conflict or not is what's important, not the exact
wording. We seem to spend a bit of time discussing the wording of the
responses, not the intent behind them.

Mirja: The intent of having those options only was to not have discussions
about wording.

Warren: Yeah, but for things like 'it's related to work in WG x' we just
decided to modify it to 'multiple working groups' but we spent ten minutes on
that. Maybe we should say these are largely what they should be but the wording
can be tweaked. You're probably right. I'm bike-shedding.

Magnus: Okay, so it's Alissa that's the one who's owning this conflict review.
Should we edit it now?

Adam: I think we probably send her an email indicating that we're okay with the
addition of some note that indicates the WG is concluded.

Magnus: Okay. I guess it falls on me with the Discuss. I'll send that and
remove my Discuss.

Amy: We'll put this into Approved, Point Raised so Alissa can pick it up from
the email.

3.4.2 Returning items

 NONE

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

 o Reliable and Available Wireless (raw)

Amy: I have a Block on the charter, so it sounds like we need to have a
discussion. Deborah?

Deborah: I think discussion would be good. Magnus, we already had an email back
from Thomas, who's in the German aeronautical groups. He clarified that maybe
this was your concern, that among their industrial partners they already are
looking at IP solutions. He clarified this work in RAW would be over the
multiple wireless links. That's what kicked RAW over to the Routing area early
on, when it seemed to be more of a routing type of use case. If for that
sentence you wanted to delete about the aeronautical work, if it were clarified
to say in developing an IP connectivity solution for ... something to the
effect of, the selection over multiple wireless links. Would that help you?

Magnus: It sounds strange from this perspective. From the rest of the
description of the WG I'd say it would be to analyze the particular case for
architectural options for how to resolve this for that particular use case and
see if there are any gaps or further needs in IETF. That would be going into
the gap analysis for this area. It can't be this group's purpose to develop a
complete solution. Do we have thoughts about how they would resolve that based
on the architecture in general, can they conclude on shortcomings with IETF
parts we have and we should try to address it, or consider addressing it.

Deborah: So you don't like the word 'solution' there.

Magnus: No.

Deborah: That was DETNET's concern, that there's no solution work until we
understand the problem. The chairs gave me that architecture document because
they didn't want a new architecture being done that would require a new
solution. How about over email we'll send you a sentence to the effect to
understand the use case for, something to that effect, and we'll take solution
out of it.

Magnus: My general block is actually on saying that there's so many comments
from IESG, this looks like you're going to have to do some rewriting. That's
really what my block is; I expect you to do edits here. Or are you not
expecting to do edits before you send it out for external review? I think there
are too many different things in these comments that should be captured and
addressed before it goes out.

Deborah: I don't quite see it that way. I'll do an update and if you have any
specifics that you don't like, you can let us know or remove the block and we
can get going.

Magnus: My question to the rest of the IESG is if there are more people who
feel like they want to see how the charter text looks after the edits before it
goes out.

Mirja: I agree with Magnus and other people as well that I think the charter is
very open at the moment and not very concrete in what the outcome and the
purpose of this group is. I don't think it's a good charter for anybody who
needs in future to care about this group and for the chairs to still work in
the group.

Deborah: If you have any specifics to help, that's good, but the charter was
really carefully crafted to get agreement with the DETNET chairs.

Mirja: First of all I think it's important to have concrete deliverables and
milestones and make clear what the purpose and the outcome of this group would
be.

Deborah: I think we have that. They already have pretty comprehensive
documents, the use cases...

Mirja: But it's not clear to me if those documents are intended to be published
as RFCs or not.

Deborah: At this time they are intended to be published. I will put that as the
milestones. I intend to have dates and to say those three documents will be
RFCs.

Mirja: I think this still applies here. I understand the political situation
here but the point is that we now spend a lot of time getting those use cases
and requirements ready before any actual solution work can be done. The
intention should always be to form a WG when there is a concrete solution that
needs standardization, and to get to this point as quickly as possible and not
spend all your time and energy with just writing support documents. That's why
I'm just not happy with such an approach here.

Deborah: I understand that. On this case it's very similar to DETNET, it's
important to get the use cases understandable, and actually there is a solution
hanging around and I think a lot of people would be very upset if that would go
forward in a fast track way. Including the author of that document; he's very
much in agreement to get the use cases nailed down and understand the gap. The
intention is not to go on for years on use cases.

Adam: I think one of the implied questions here is, what the value of having
the output documents published as RFCs is vs having them as drafts that are
used by the WGs?

Warren: I've got a standard soapbox rant here. I always think having the use
case documents and architecture documents published as RFCs is really useful.
When you are running a network and someone says 'go off and implement this
protocol,' it's really useful to be able to go back and see what the protocol
was supposed to do, if you're trying to use it in a way it was intended, what
the overview of the protocol is. We often end up with documents that just
explain how the bits go on the wire, but without a use case architecture
similar, it's really hard to know what it's supposed to do, if you're using it
in the right way, etc. So I think if someone writes a use case document or an
architecture document, it's worth publishing as an RFC and it's usually the
first place I look when I'm trying to learn a new protocol or technology.

Mirja: Then you didn't read all the use case documents that have endless
amounts of not well written text that's not very useful, right?

Warren: I read those and I skip over them.

Mirja: I think it's good to have this information but an architecture and a use
case is not the same thing. You can't apply an applicability statement to the
protocol itself if it's a newish thing. You can add design principles to the
protocol itself so people understand where it's coming from. You don't need a
bunch of separate documents for that.

Warren: That's true, you don't need a bunch of separate documents, but the
person who's writing the protocol is writing them.

Deborah: I agree with Warren. The use case is the one place that operators can
coauthor. If you just put this document on a wiki or something, it's not really
a solid contribution for them. I believe if they turn out a good use case
document, let them do it and we can publish it as informational. That is the
operator contribution.

Mirja: I'm not against writing use case documents. That's always the first step
to make people understand why you do this work, why the protocol is useful. I'm
not against publishing these documents because someone wants their name on an
RFC; that's also fine to me. The whole point about not pushing those documents
through the process is to save everybody else's time who have to work on these
documents and to have the limited energy we have in the IETF and put the energy
in the actual protocol specifications. In this case when you say there's
already a proposal, and it might not be perfect, then I don't understand why we
need to hold up this proposal and delay it to do all this random work. That's
kind of already done. The important part about the use case is to describe
them, it's not important to agree on the use case.

Deborah: Well, like always, that's one vendor's proposal for a solution, and
without understanding the use case and requirements, there's no measurability
to say if that solution is what it should be. It's not aligned with DETNET, and
DETNET folks feel their solution can apply here, along with other IETF work. So
without understanding the use case and requirements, what are we supposed to
do? Rubber stamp a vendor's new  solution just because it's a solution?

Mirja: No, the important part is if other people are interested in implementing
the solution. If enough people interested in implementing the solution it's
fine. If enough people are interested to extend DETNET that's fine too. It
doesn't have to be the best and optimized solution that covers every use case.
The question is if people want to implement it.

Deborah: I disagree. One does need to start off with some requirements and use
cases, especially on this one as it's a new technology for IETF and I think
it's a very good opportunity to bring in new folks and we can help to
understand their requirements. To shut them down and say to go away, we know
everything and we'll start on solutions for you, is not the right approach.

Magnus: No. I want to add I have no problem with this and publishing them is
probably very good in this context; if it's new to us it makes sense.

Mirja: just to clarify, I was not proposing to tell people to go away because
we're not interested in their requirements, I was proposing to tell people to
come and work on a solution instead of spending all their time on requirement
documents.

Deborah: It's not how operators approach problems. They don't jump on board on
one vendor's solution; if they really want interoperable solutions they want to
know what the best solutions are and do requirements first.

Warren: I think the discussion on use cases and requirements and discussions on
the solution generally happen in parallel and there's some back and forth.
There's no, we're going to do a bunch of use cases and requirements with no
thoughts on if they can actually be implemented or what they would look like...

Mirja: But that's actually also what I'm saying. If you talk about a protocol
solution, of course you also have to talk about requirementss and of course you
have to agree on requirements. But I don't think there's a need to spend a year
on talking about requirements without having a concrete solution in mind and
publishing that in as separate document.

Deborah: Everybody's welcome to bring any document, including a solution. If
you're really concerned on the waste of time of the IESG or the RFC staff on
informational documents, you should bring it up. That was part of the earlier
BoF. When we had the RFC Editor BoF several operators went to the mic and said
they did find informational docs valuable. So if we feel IESG-wise we're
wasting our time, perhaps we can find another way to track these through.

Mirja: I think there's actually 2 things. One is about publishing those
documents and having everyone's time and money spent on these documents that
have a limited value to be archived or limited readership or don't need IETF
consensus. That's one concern about the documents themselves. But forming a
whole WG to only create these kind of documents is giving a very different sign
to the community than I think we should give.

Deborah: That's your view and I hope it's not everybody's view. If you're
interested in really doing away with or another approach for informational
documents, write a document and we can have a BoF on it and see where other
people are at.

Warren: If that happens, I'll happily come to the BoF and say I find these to
be one of the most useful types of documents that we have. It's one of the
first types of documents I look for when I need to understand something.

Deborah: Okay, so this stays in our review and Magnus has his block. I'll tweak
some sentences and we'll get it out.

Amy: Great, so it sounds like we will be waiting for instructions from you,
Deborah.

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

Mirja: I don't think there's any real new news but last week I forgot to
mention the IAB is working on a conflict of interest policy and that went out
for external feedback. There was a lot of feedback so they will now try to sort
out the feedback and it's still ongoing.

Ted: The other thing I'll mention is we have received the IESG slate from the
Nomcom.

Mirja: When is this scheduled for discussion again? In two weeks?

Ted: We're going to try to do the discussion by email as much as possible.

6. Management issues

6.1 [IANA #1156116] Designated experts for RFC-ietf-lamps-cms-mix-with-psk (RFC
8696) (Roman Danyliw)

Amy: Roman has identified Jim Schaad and Russ Housley as the designated experts
for this registry. Is there any objection to naming them experts? Hearing none,
so we'll send official note to IANA.

6.2 [IANA #1160634] Designated experts for RFC 7636 (IANA)

Amy: We discussed this at the top of the call; it was added yesterday.

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

Suresh: I just sent out a call for feedback for the Trust appointee from the
IESG, so I'll summarize comments in about two weeks.

Ben: The TLS working group has started discussing what we want to recharter to,
so you'll be seeing that in the next month or so.

Amy: A reminder from me that the doodle poll for the BoF coordination call for
IETF 107 is still active until tomorrow, so please fill that out if you haven't
already.

Magnus: I'd like to discuss this obsoletion of IRTF stream RFCs. Especially as
we have Ted here. I would like some other input into this too. Ted, could you
go through a bit of what you think the issues here are, especially process-wise?

Ted: I think there are two very distinct issues. The first is whether or not
this agreement the IESG seems to have made with the IRTF needs community
discussion, given that it relates to RFC mechanics generally. The way it's set
up is personally fine. I had early comments and those have been dealt with. But
I think if this is going to get used, it would be better if it went out for
community discussion first because there are people who get wrapped around the
axle about the relationship among streams pretty easily, and having it
announced as a policy along with its first use is a little bit problematic.
Particularly problematic because you didn't, as far as I can tell, actually
follow the process exactly this time anyway. From a process perspective the
cleanest thing to do is to take it out to the community and say the IESG and
IRSG are both okay with this, we want to announce it to you because it came up
in this other context, and this is what we think is the best way to do it going
forward. With that, you an deal with whatever objections come in pretty easily.
The second question is for this particular document, if you're going to do
that, how do you get this document unstuck? My suggestion is to say that the
document that describes how to do bundled protocol v7 should not have to wait
while all that works itself out. As you can tell it was rough consensus in that
group around whether or not this should obsolete bundle protocol v6 since it's
still going to be in use. My understanding is there was discussion about
whether to appeal that and they decided they'll use a different reference
instead, which is non ideal but not blocking. I'd say the simplest way to do
that is to simply carve this out and say BPv7 the document isn't going to do
this work; we will create a document that's in essence a one-pager that says
BPv6 is marked historic in favor of BPv7 and then you take that document
through this new process. That gives you a little bit better cover for running
the process cleanly and it gives the people who want to have a discussion about
this a way to have the discussion that doesn't block progress of BPv7. I think
that's the problem right now, everyone is frustrated with this conversation
because it's holding up publication of the document. You can separate those out
and my suggestion to you was to do that. Now this is clearly not an IAB
statement of any kind, consider it as an old IESG piece of advice / it's
clearly not something I'm going to appeal you over myself. It's just advice.

Magnus: I know at the minimum I need to redo the IETF last call. If we're going
to try to obsolete this now there's a minimum new IETF last call anyway. You're
right, I missed that part. I think you have some merits. I'd like to see if
there's other feedback.

Mirja: I'm afraid this is a much larger discussion to have at some point. A
similar question comes up too, should one document on one stream be able to
update or obsolete a document on another stream? Maybe the answer is not the
same for every stream. It's more likely that work moves from the IRTF to IETF.
But I guess it could go from the ISE to IETF too.

Magnus: Yeah, the process is not symmetrical.

Mirja: But I agree that a cleaner solution would be to publish a separate
document that moves this document to historic on the IRTF stream, and says this
new document exists. This is just more processing of a small document and I'm
not usually a big fan of that, but I don't know.

Magnus: Thank you for the input. I'll consider what to do next.

Amy: We've come to the end of our agenda so that's it for today. Thanks
everyone.