Narrative Minutes interim-2021-iesg-23 2021-10-21 14:00
narrative-minutes-interim-2021-iesg-23-202110211400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-10-21 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Adrian Farrel
Lee-Berkeley Shaw
Donald Trump
Greg Wood
Zhaohui (Jeffrey) Zhang

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda? We had a document
that was deferred to next week. Any other changes?

Martin V: Just to let you know, I will progress all three docs as a batch to
the RFC Editor when I can approve them all, because there are dependencies
between the three and that's why I presented them to you in a batch.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to approving the minutes from October 7?
Hearing no objection. Any objection to approving the narrative minutes from
October 7? I'm hearing no objection there either. We will get both of those
posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 8739 and RFC 9115
       (Automated Certificate Management Environment (ACME)) [IANA
       #1210257]

Roman: We're still in progress on that one.

     o Francesca Palombini to find designated experts for RFC-ietf-httpbis-
       semantics-19 (HTTP Semantics) [IANA #1210675].

Amy: This is on the agenda to approve these experts later so this is
provisionally done.

   * OPEN ACTION ITEMS

     o John Scudder, Martin Duke, and Robert Wilton to review the document
       shepherd templates and propose changes to include updated questions,
       cross-area checks, and an expanded section on the use of YANG
       models.

Rob: We have had a meeting last week. We're making active progress and Sandy
has sent an email with some suggestions as well. I want to try and fold that in
and hopefully we'll be able to send this out fairly soon.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.
     o Alvaro Retana and Martin Vigoureux to draft text to include in the
       I-D submission tool warning about too many authors.

These two depend on the first item being completed.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling
       normative references to non-SDO documents.

Murray: That's been in discussion on the IETF list and is an active doc. One
person is saying it maybe shouldn't be an AD-sponsred document. It seems to me
we do a number of docs this way so it seems fine to me. That's a long way to
say it's in progress. Let's keep this on for one more week and mark it complete
at the next telechat.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in October 2021.

Amy: I'm going to get the stats from Ryan next week after the I-D submission
deadline, which is Monday. Sometime next week I will be updating that document
for you and we can put this on the agenda for next Thursday's formal telechat.

     o The IESG to review the feedback on whether to continue the RFC 8989
       experiment 2022-2023 cycle by October 7, 2021.

Amy: I think the answer here was yes. Is this item done?

Lars: This is done; we sent an announcement that we're going to continue it.
This must be leftover.

     o Warren Kumari to rewrite the IESG blog post on "Handling IESG ballot
       positions" as an IESG statement.

Warren: In progress.

     o Éric Vyncke to work with the Tools Team to update the references to
       the BSD License in the Trust Legal Provisions in the various IETF
       Tools.

Éric V: This is done and the ticket is closed.

     o Greg Wood to update the references to the BSD License in the Trust
       Legal Provisions on the IETF website.

Greg: It has not yet been updated but I will do it now.

     o Eric Vyncke to follow up with the Tools Team about updating the Last
       Call template to include a pointer to
       https://datatracker.ietf.org/doc/in-last-call.

Éric V: The ticket is open and has been accepted. Let's keep this here so I can
monitor it.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-bess-evpn-optimized-ir-09  - IETF stream
   Optimized Ingress Replication solution for EVPN (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: Not really. I perfectly understand your point, John. I see different
cases in drafts sometimes that do describe the situation that we should cover
and the exceptions to the SHOULD. I don't honestly know the specific situation
the authors were thinking of that would justify not respecting the SHOULD so I
prefer to let them speak. I don't think it's a big issue to resolve. We might
end up with examples but somebody might have something else in mind which will
never be written in the document.

John: I agree; let's just see what the authors have to say.

Martin V: I haven't looked at the other comments but I believe the document
will need a Revised ID.

Amy: IESG Evaluation, Revised ID Needed. Thanks.

 o draft-ietf-bess-evpn-bum-procedure-updates-11  - IETF stream
   Updates on EVPN BUM Procedures (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: Yes, a bit. Ben, i was about to give you an answer to your question
but you will also find it in an email by Jeffrey, who's online also if need be.
If you look into 7117, the Leaf A-D route is sent in response to a route you've
received. The route key is the NLRI of the route you've received. You're
copying back in the Leaf A-D route something you've received which has a very
well defined structure and length so you're able to find your way back when you
receive it.

Ben: My uncertainty was that I don't know how you tie the particular triggering
PMSI route and the response Leaf A-D route. Are they always going to be on the
same TCP connection or something like that? Maybe we should do this in email.

Martin V: Maybe. I think not, but let's follow up by email. The next one is
Lars's. I kind of think we're discussing editorial choices here. Paul has sent
a review to which Jeffrey replied and they had three or so emails each where
they were going through details and clarifications. I believe Paul's review has
been discussed.

Lars: There are two, right?

Martin V: No, they are the same.

Lars: I looked at it too and it looks like he sent the exact same review again.
And the earlier review his follow-on said to disregard it. I'm not quite sure
why he's sending it again with serious issues.

Martin V: I didn't understand that but I'm happy to re-discuss it. Jeffrey did
some small updates to the document in the introduction to try to better clarify
and set context from the beginning. To be honest, I took a second look this
morning and found two places where additional modifications could be brought to
the document but beyond that I don't know what we can do.

Lars: Roman also had in his comment some things that are related to the Discuss
so you can look at those as well.

Martin V: I've seen Roman's. The point I really like in Roman's comment is
about the security concerns. Maybe we should go a bit more in detail on the
security concerns which are relevant in 7117 and 7524 which apply to that
document.

Lars: I think this can be addressed if they roll in some of the changes you've
just outlined. I didn't see that there was an earlier discussion; I saw a
Gen-ART review that said serious issues and no reply which is why I filed this
Discuss.

Martin V: Interestingly, Paul's review only went to the Gen-ART directory
mailing list and the authors. I guess you're on that list so you should have
seen it.

Lars: I looked for a reply to the Gen-ART review and the original review had a
different subject. It was a Last Call review or something.

Martin V: To be clear, it's not updating 7117. It's borrowing procedures in
that document and applying them to EVPN. I think that's a world that's changing
when applied to EVPN, it's not changing the VPLS procedures.

Zahed: I had the same kind of comments. I can agree this is updating 7432 but
how this is related to 7432 was not clear to me. I wrote something about what I
think could help. When I was reading it I was missing how 7117 was related to
7432. Maybe I should have read everything together.

Martin V: 7117 is an ethernet VPN technology which is called VPLS and it's
about multicasting that VPN technology. Where it is confusing is that 7432 is
another ethernet VPN technology which is called EVPN. That EVPN technology
borrowed some procedures from VPLS but it didn't cover as much as 7117 had
covered, so there is a gap in the multicast space between VPLS and EVPN. What
the procedures document we have in front of us does is it simply fills the gap.
It follows the same editorial choice that was made in 7432 which does not
repeat the text. If the procedure applies, say that it applies and be done with
it.

Zahed: I think you have that described in a concise way in section 2. In
section 5 if we add more about what you just said that makes a lot of sense and
maybe we can get away with this.

Martin V: There is a change Jeffrey had thought of doing which I didn't see in
the latest revision, which is the name of Section 5.1. He had the intent to
complete the name of that section by saying "when applied to EVPN."

Zahed: That would really help.

Martin V: I think he's listening and taking notes.

Roman: I need to respond back to the authors because I think my intent is still
not clear. I did not raise it to a Discuss but the bottom line is a stack of
citations were made. If you look at the citations of those security
considerations, many of those are talking about technologies that are not
germane here. It would be incredibly helpful to future readers of this document
if the text was clearer on exactly which part of the security considerations
apply. For example, the MPLS does not, would be good guidance. What is not
clear to me is what are the residual security considerations that occur from
following these procedures, given that the security considerations are talking
about a different technology. This idea of patterning after how it was done
elsewhere is great to explain the design but it doesn't exactly explain if
there are residual security issues. I'm hoping for some clarity there.

Martin V: It's a different technology but it reuses the same mechanisms than
the ones cited in the security considerations.  I understand your point and I
hope the authors will address it. And the residual aspect is important indeed.
Murray, I think your Discuss is well understood.

Murray: They've already answered.

Martin V: Please keep in mind, for the document that was deferred, that's where
it really makes sense.

Murray: I put a very similar Discuss on that one too and it will be easy to
resolve.

Martin V: Okay. Thank you very much everyone. Revised ID Needed for that one as
well.

 o draft-ietf-cbor-cddl-control-06  - IETF stream
   Additional Control Operators for CDDL (Proposed Standard)
   Token: Francesca Palombini

Amy: I have no Discusses for this document; unless there are any objections,
this is approved. I have no notes; are there any needed or is it ready to go?

Francesca: It will need a Revised ID. Ben, I saw Carsten reply to you and I
posted in the slack chat just to see if you are happy with that PR. Rob, I also
just saw your comment and we can wait for the authors to reply but I don't
think this document should update CDDL; there is a version 2 coming at some
point but it's not there yet. It would make more sense to update that document.
And yes, you're supposed to find the control operators via the IANA registry.

Rob: The new version of CDDL, will that pull this functionality in? Or will
they still be separate?

Francesca: I'm not sure, because there is no draft right now. Initially it was
thought that this would go in CDDL 2.0 but this didn't need to wait for it.

Rob: It's really just from an implementation point of view, how do you know
what you have to implement vs what's optional and what performance there is, so
when you're writing CDDL you need to know whether or not people are going to
support it. That was my real concern here is fragmentation occurring.

Francesca: If you support the base CDDL in 8610 then you don't necessarily
support these additional control operators but I expect in version 2 they'll be
included.

Rob: Okay, thanks.

Francesca: We'll wait for the author's reply on that as well. Revised ID Needed.

 o draft-ietf-jmap-smime-09  - IETF stream
   S/MIME signature verification extension to JMAP (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have no Discusses for this document; so unless there are any objections,
this is approved.

Murray: It does need a new revision; is that Approved, Revised ID Needed?

Amy: Yes, it will be Approved, Announcement to be Sent, Revised ID Needed and
you can let us know when it's ready to go.

 o draft-ietf-extra-quota-07  - IETF stream
   IMAP QUOTA Extension (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a couple of Discusses for this document; do we need to discuss
those today?

Murray: One of them. They posted a new revision already in response to Ben's so
it's up to you to decide how they did.  Lars brought up a question about a
downref that we might want to pursue a status change for the target document. I
think they said they want to do that eventually but not yet. We could approve
this as a one time downref and then they can take up the work. This is being
considered so I don't know if that's enough to satisfy your Discuss.

Lars: That's fine. I think we should add it to the registry because if they're
thinking about doing a status change it seems to be stable enough to be a
downref. I wanted to ask, am I too obnoxious with the downrefs? I might be
applying outdated processes here given that it's been a while since I was AD.
If I should just not flag them when I see them I can stop.

Murray: I don't object to being reminded about process stuff like this, as long
as it doesn't freak out the authors to put a Discuss on it. For this one I will
add it to the registry and we'll take it from there.

Amy: Is that RFC 5257?

Murray: Yes. Do you normally add them, or should I?

Amy: You can't actually add it until the document has been approved. The
Datatracker is not very clear here but once we send the approval announcement
the datatracker kicks back a question to us about whether to add it to the
registry. Knowing ahead of time that yes this should go into the registry is
helpful.

Murray: Yes, it can go. They do want to upgrade 5257 from experimental to PS.
Whether that will be a new document or do it in place, I don't know.

Roman: Lars, on the question of whether to call this out or not, I'd like
everyone's opinion on this. You're correct that the document was not on a
downref, but I just checked the Last Call announcement and it had a reference
to that document and said it was a downref. I thought if you have the text in
the last call list that it's a downref, it clears without commentary as a
result and the only discussion for the IESG is whether or not to add it to the
registry. I don't know about this being a Discuss because it was in the Last
Call announcement.

Lars: I read Barry's document and that's not the process I get from it. Maybe I
need to read it more carefully.

Murray: The reason this was Discuss worthy is because there was also a
potential document status change in the works. If it was as simple as the
downref my view is the Discuss would not have been necessary and it would have
just run the process as it is.

Roman: I forgot there was that extra nuance. Whatever was the process I just
described, that's not from a document, I'm just describing the working practice
I thought we were doing the last couple of years. It might be wrong.

Lars: I'll take a virtual action item to reread 8067. I'll silently correct my
actions if I've been wrong and if not, I'll bring it up.

Roman: When I had those questions previously Barry was always the one who told
me what to do.

Murray: So we all had it right and this is one of the reasons I'm updating BCP
97, so it's topical.

Lars: The way I read 8067 is that if a downref was forgotten in Last Call, we
don't force another Last Call, but it doesn't say anything about the IESG still
needing to approve the downrefs. But I'll reread it again.

Francesca: I think at least for the time I've been here, that's what has
happened for all the documents. When there were downrefs in Last Call, no one
put a Discuss or anything like that, it was just silently approved by the IESG.

Lars: I know that's been practice, and Alexey was a little annoyed that I did
this, but I don't think it's actually what the document says. Maybe the
practice has been a little different than what the document says, which is
totally understandable, but maybe we should update that RFC. I'll read it and
report back.

Murray: 8067 is part of BCP 97, which I'm updating, so if there's something to
change now would be a great time to do it.

Lars: Okay. And I've cleared [my Discuss].

Amy: It still has a Discuss, so this will stay in IESG Evaluation, REvised ID
Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 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-zhu-intarea-gma-00
   IETF conflict review for draft-zhu-intarea-gma
     draft-zhu-intarea-gma-11
     Generic Multi-Access (GMA) Encapsulation Protocol (ISE:
   Experimental)
   Token: Erik Kline

Amy: I have a couple of Discusses; do we need to discuss this today?

Ben K: I'd like someone who actually knows the material to tell me whether I
should just clear and mine isn't an issue.

Erik K: Adrian's reply was in my original reading of that section. I think
you're probably right and at a minimum, there needs to be text about the inner
minimum MTU that needs to be supported. In that case fragmentation is not
optional. Either you generate an ICP error or you have to transparently support
the minimum MTU passing through. In rereading that section I reread 4.2 before
it which actually talks about header insertion. I think I probably got confused
about when was the IP payload a datagram and when was it an actual IP payload
as referred to by 791 and 8200. I think you should hold your Discuss.

Ben: Okay, I can do that.

Erik K: I don't actually know what to do in this case. I assume the conflict
process involves checking whether or not standards are being violated. Or is it
just that nobody else is doing this work?

Alvaro: Or whether it should be done in the IETF. If nobody else is doing the
work but it should be done here, then it's bypassing the process.

Warren: Is this going to break anything we're working on? Is it violating any
standards? Is it work that should be done in the IETF and it seems as though
people are going around the process by going through the ISE instead? Those are
the main ones I think of.

Erik K: I think only the middle one is possible here. We should get an answer
there.

Warren: I will note that even if it's work that we think should be done in the
IETF, if no WG is willing to do it, it's perfectly fine for it to go elsewhere.
For example there was a document recently that should have gone through DNSOP,
and the authors attempted to do it through DNSOP, and DNSOP said it sounds like
something within our stuff but we don't care, you might want to take it to the
ISE. That absolves the authors, if they've tried and the WG said it doesn't
violate our stuff but we're bored, that's an option.

Murray: I've got one of those in my area too. A WG has specifically said they
don't want to deal with it and nobody seems particularly interested in us
taking it up in any existing WG, and there's not enough momentum to create a
new WG, but enough people have opinions about it that it seems like it should
be a consensus document. No one cares enough to do the work but everyone cares
enough to have an opinion about it. Adrian perhaps can comment.

Eric V: This draft was presented in INTAREA but it was clear it would never be
adopted, so it went another path. Adrian knows more.

Warren: For my DNS document, the WG didn't really say they were bored, they
said it was within their charter but had political ramifications they weren't
really willing to get into.

Erik K: I don't know proper procedure but it does seem fair to give the authors
a chance to reply to Ben's comments.

Eric V: My last comment is about this INTAREA text. Did you change it?

Erik K: I didn't change it.

Warren: We mentioned Adrian in passing; I don't know if he actually wants to
chime in or if he needs to be more clearly called on. Please chime in if you
have comments.

Adrian:  I do actually but I think you need to invite me to speak. I think
there are a number of things going wrong here. Firstly, whether the IETF wants
to work on this or not, we've made rather a lot of attempts to persuade the
IETF to work on it and it does not seem like the IETF does. If there's any
evidence to the contrary, we'll jump at that. It's maybe a little late to the
point of rude for the authors, though. The next thing would be the use of the
114 protocol ID. That one has been round the houses a significant number of
times. We're still open to other suggestions but we ended up with 114 as nobody
had an objection that could be shown to be harmful. I'm also open to discuss
that. Fragmentation we should certainly discuss with the authors. I think you
as an IESG have a choice here. You can update your conflict review to say we
think this is actually a violation of some preexisting work and therefore the
draft must be changed, or you can resort to communication and actually say do
you think you could work on this so we don't have to put in this conflict
review? The latter is more friendly but you're open to do either. The last
thing I want to say is that it's entirely unclear to me what it means to
abstain on a conflict review. As far as I can see there's no documentation of
what an Abstain means, but it's useful to see comments however they show up.

Lars: I used Abstain as 'I think this document is basically useless' for the
reasons I put in the comment. I don't think it's necessarily harmful or should
be blocked from being published, but I also don't want to say no objection.

Adrian: That's cool, Lars, but you're not balloting on the document. You have
no ability to ballot on the document. You can only ballot on the question,
which is the conflict review. That's what I mean by being unclear what Abstain
means.

Lars: Okay. Well, I certainly got your attention. But I see what you mean.

Erik K: Is it fair then to see if the authors can address Ben's point and then
I can look at updating the ballot? Eric wanted INTAREA to be included; did we
want to say something about transport concerns? I know Martin had concerns as
well.

Martin D: Just that I think the multipath TCCP work is in the same problem
space and it should be noted in the same way DETNET is. That's all.

Zahed: I differ a bit on this. I do agree with Martin that it should be noted
in the conflict review response. I do think they are on different levels trying
to solve different problems. Multipath TCCP is still on layer. This is beyond
it and therefore I don't agree a little bit with what Martin said. The use
cases.

Martin D: I agree there are different layers, I think they're fundamentally
trying to solve the same problem. But regardless, for purposes of this process,
I think Zahed and I both agree that it should be noted as a partial conflict in
the conflict review.

Zahed: Yes.

Erik K: I can certainly update the list of partially conflicting WGs and then
we can see what the authors have to say about MTU issues. If that can be
resolved I guess it will be coming back to a telechat in the future.

Warren: I think we should have a standing position that the ISE is always
invited to speak on conflict reviews. A couple of times we've been waiting for
Adrian to speak and he's been waiting for us to call on him. I think the ISE
should be always expected and invited to provide useful comments for these.

Lars: That makes total sense.

Amy: So this will stay in IESG Evaluation and we'll put it in AD Followup, so
Erik can track how the authors are doing and update the conflict review for it.
Once the discusses are resolved you can bring it back to a telechat; you don't
have to, but you can.

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 System for Cross-domain Identity Management (scim)

Amy: I have no blocking comments, so unless there's an objection now, it looks
like this WG is approved.

Roman: First I'd like to say thank you to everyone for all the feedback. I
think it's ready to go as-is and I believe I've answered all the comments here.
It's ready to go and thanks for everyone's help.

Lars: Do you have a second chair? The Datatracker only shows one.

Roman: I'm in the process. It's hot on my list to make sure I close the loop on
that.

Lars: It's not that we can't charter it without two chairs, I was just
wondering.

Roman: I'm actually looking for three chairs; my usual two more experienced
ones and one to mentor in place. I may have to settle for two experienced ones
and hunt longer for the inexperienced one. It'll have two hopefully by the end
of next week and certainly by IETF 112.

Amy: Is ART the right area for this? Are you going to continue to be the area
director?

Roman: That was my understanding.

Amy: That's great; we've done it before and we can do it again. I just wanted
to make sure ART was the right area.

Roman: Since the origin is in ART I don't see any reason not to leave it there.

Amy: Great. We're not waiting on any edits so this can be approved and we'll
send an announcement.

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

Martin V: Nothing.

Lars: There is the news that we are looking for a new ISE. That was sent to
ietf-announce.

Mirja: Yes. We're looking for a new ISE and any ideas are welcome.

6. Management issues

6.1 BCP14 terms in non-IETF streams (Lars Eggert)

Lars: We have BCPs that clearly define what the BCP14 terms mean in standards
track documents but people also use them in informational and experimental
documents and in other streams. It's sometimes questioned whether this is
acceptable use or not. I was wondering if we should say something about if it's
acceptable or not. My personal feeling is that it's completely acceptable and
we have a lot of RFCs published that use these terms that are not on the
standards track and retroactively defining that to be a problem is not helpful.
The question is whether this raises a bar for doing an IESG statement or
something else. We tightly control the meaning of these terms for standards
track, and if people want to borrow them for their stream or their
non-standards track document I don't think we should prevent them. We should
probably encourage them, actually.

Martin D: If someone is doing an ISE document that describes an external
standard, I can't imagine how you would compose that without using those
keywords.

Warren: I raised this recently in some document completely external to the IETF
that I was a little bit twitchy about. They were using the term RFC and they
also used 2119 terms all over the place. It felt weird and a number of people
pointed out that we have all over the place where people can take our text and
do almost whatever they like with it, and that includes this sort of thing. It
would be weird for us to say here's all this text, except you can't use this
for external things. If it's used for external things, I don't see why people
can't use it for their informational documents or how they'd like their coffee
made. I'm in agreement with Lars and others. They are not strictly protocol
things, they are conventions explaining how we use specific words. It even says
that in the boiler around it.

Ben: This is clearly something other people can use and it's just a question to
me if we want to make an official statement or if we think the status quo is
good enough.

Eric V: Obviously outside of the IETF or non IETF streams, they can do whatever
they want. I'm always quite annoyed when I see an experimental or informational
document using those words, because they kind of give the illusion that it's
standards track.

Lars: [crosstalk] specify a standards track document and these words are
defined because they have precise meaning. It's my opinion that it's as useful
for an informational or experimental document.

Martin D: As a practical matter, it also makes it much harder to do a status
change if you have an experimental draft you want to bring to standard and you
have to add all these things, that would be a nightmare and very error-prone.

Warren: It's also often a way to say 'and we really mean this.' Autonomous
systems must not send packets with RFC 1918 space in them. It's clear that's
something we really really mean, even though it's in an informational document.
Obviously there are no protocol police but in some ways the way we use bold or
italics in other documents we use MUST and SHOULD in this.

Mirja: This is a little bit of a misinterpretation because I don't think
normative language is used to make something stronger. It would be as strong if
non-normative language were used, but it makes it clearer. If you use normative
language it's clear this is a rule you should implement, and that's also super
useful for operational guidance. This is what we expect you to do.

Warren: You worded that much better than I did.

Murray: It was pointed out to me by Pete Resnick some time ago that these words
are not the only way to be normative. You can say 'a client does this' and
that's normative. It provides more force but it doesn't mean that not using
these words causes the text to be non-normative.

Francesca: To go back to what Lars was saying, I also agree with your sentiment
but it's not really clear what the IESG would say. It's a non IETF stream.
Maybe we could also hear Adrian's opinion.

Adrian: Let me say what the concern I heard was, that 8174 very specifically
says this document defines how these words are interpreted in IETF documents. A
citation of 8174, some people claimed, gave the impression that the independent
stream RFC was a product of the IETF.

Warren: Would there be an issue if people use it in ISE documents, they take
the text and say how the terms are used in this document?

Martin D: There's pretty clear boilerplate on ISE documents that they're not
consensus documents.

Adrian: Love you, Martin. Some people disagree that boilerplate makes it
obvious.

Martin D: If people are going to be that obtuse about it, I don't know what we
could do to correct that. Put me down for not bothering to do an IESG
statement. The true documentation of our attitude is the massive archive of
RFCs that are informational and experimental that show you can do this. That is
a way more powerful signal than any IESG statement that everyone will forget
about. We have a ton of precedent; let's just let that ride and not bother with
a statement. It's not worth the effort.

Alvaro: I completely agree with that. With any document, we can't specify in
our documents what other people are going to do, we can only specify what the
IETF is going to do. Even if that consensus wasn't there, it'd be obvious that
it applies to IETF documents. In my opinion it would still be okay for anyone
to use anything we produce.

Warren: Now I'm confused/conflicted. I don't really in general think it's worth
us having an IESG statement on this because I also don't know what it would say
other than a clarification that it's fine for people to use these terms.
However, I am still a little bit on my hobby horse that we should try and make
IESG statements less, I'm not going to say special, but less something that is
viewed as a monster big hammer. In some ways, I feel that just having something
with a quick clarification that we know other people use these terms and
they're simply to make it easier for other people to understand, would be
useful in taking away the heavy weight of IESG statements. But it also seems
like this isn't hugely needed. I don't know.

Lars: It seems like we're all sort of agreed on what the sentiment is toward
these terms. If somebody feels strongly enough that we should publish
something, you can write a draft and we can continue the discussion. If it
doesn't go over that bar for anybody, I guess no statement will be made and
that's fine with me.

6.2 [IANA #1210675] Designated experts for RFC-ietf-httpbis-semantics-19 (HTTP
Semantics) (Francesca Palombini)

Amy: Francesca has identified a couple of people, Mark Nottingham and Roy T.
Fielding. Is there any objection to naming these two people as designated
experts for this registry?

Lars I'm not objecting, just pointing out that Roy can sometimes be a little
slow to respond and you might want a third one.

Francesca: We'll see.

Amy: I'm hearing no objection, so we'll send an official note to IANA.

6.3 [IANA #1206921] Renewal for early allocations for draft-ietf-lsr-flex-algo
(IANA)

Amy: This early allocation has expired and needs IESG approval to extend the
early allocation. John, you're the AD of record, do you want to speak to this?

John: The document is in my queue, we have implementations, and I think we
should extend the allocation.

Amy: Okay, I'm hearing no objection, so this is approved and we'll send an
official note to IANA.

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

Martin D: I'm probably going to shut down the TRAM WG soon. There is one
document still floating around and I'm looking for a home for it. It will
either go to TSVWG or I'll AD Sponsor it. There's nothing happening in that WG
and no reason to have that infrastructure. The chairs are cool with it; let me
know offline if you have any problems.