Skip to main content

Narrative Minutes interim-2018-iesg-20 2018-09-27 14:00

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

Narrative minutes for the 2018-09-27 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
Ben Campbell (Oracle) / Applications and Real-Time Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Terry Manderson (ICANN) / Internet Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Eric Rescorla (Mozilla) / Security Area
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

Ignas Bagdonas (Equinix) /  Operations and Management Area
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Heather Flanagan / RFC Series Editor
Mirja Kuehlewind (ETH Zurich) / Transport Area
Jeff Tantsura (Nuage Networks) / IAB Liaison
Portia Wenze-Danley (ISOC) / Interim IAD

Luigi Iannone (document shepherd for draft-ietf-lisp-gpe, draft-ietf-
 lisp-rfc6830bis, and draft-ietf-lisp-rfc6833bis)

Mahesh Jethanandani
Mickelly Rodrigues

1.2 Bash the agenda

Alissa: I will have to drop after one hour.

Warren: I also have to drop after an hour.

1.3 Approval of the minutes of past telechats

Amy: Anyone have an objection to approving the minutes from September 13?
Hearing none, so those will be posted. I saw slightly revised narrative
minutes, any objection to approving those? Hearing none, so those will also be

1.4 List of remaining action items from last telechat

     o Suresh Krishnan to find designated experts for RFC-ietf-6tisch-6top-
       protocol [IANA #1119883].

Suresh: Still in progress.

Amy: The next are all for Ekr who I don't see in the Webex, so hopefully he
knows those are still there for him. We'll move on.

     o Eric Rescorla to find designated experts for RFC 8411 [IANA

     o Eric Rescorla to find designated experts for RFC 6509
       (mikey-payloads) [IANA #1121057].

     o Eric Rescorla to find designated experts for RFC 6043
       (mikey-payloads) [IANA #1121239].

     o Eric Rescorla to find designated experts for RFC 6267
       (mikey-payloads) [IANA #1121240].

     o Eric Rescorla to find designated experts for RFC 6309
       (mikey-payloads) [IANA #1121241].

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-opsawg-nat-yang-16  - IETF stream
   A YANG Module for Network Address Translation (NAT) and Network
   Prefix Translation (NPT) (Proposed Standard)
   Token: Ignas Bagdonas

Amy: Ignas could not be here today. I have no Discusses so unless there's an
objection it looks like this one is approved. I'll put it in Point Raised so he
can do his final checks.

 o draft-ietf-tram-stun-pmtud-10  - IETF stream
   Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)
   (Proposed Standard)
   Token: Spencer Dawkins

Amy: Spencer unfortunately could not be with us today so all the folks with
Discusses are going to have to take it up with Spencer offline. I'm guessing
these probably require a Revised ID?

Adam: Based on the conversations with Spencer it might not be a Revised ID, it
might just run through the process again, but we'll have to hear from Spencer
before we make that call.

Amy: This will go into IESG Evaluation, Revised ID Needed, and we'll let
Spencer make that call.

 o draft-ietf-netconf-nmda-restconf-04  - IETF stream
   RESTCONF Extensions to Support the Network Management Datastore
   Architecture (Proposed Standard)
   Token: Ignas Bagdonas

Amy: There are no Discusses in the tracker so unless there's an objection it
looks like this one is approved. Hearing none, this is approved and as he is
not here we'll put it into Point Raised and he can follow up and make sure all
final checks are done.

 o draft-ietf-netmod-acl-model-19  - IETF stream
   Network Access Control List (ACL) YANG Data Model (Proposed Standard)
   Token: Ignas Bagdonas

Amy: I have quite a number of Discusses in the tracker and unfortunately Ignas
isn't here to discuss them. Do we think this is going to require a Revised ID
so Ignas can pick this up when he's back?

Suresh: Yes, for sure.

Amy: Okay, this will stay in IESG Evaluation and go to Revised ID Needed.

Ted: On the point Alissa raised, there's an IETF/IEEE coordination meeting
later today. Do we want to get this in front of one of the people who will be
on that call?

Alissa: I had sent mail to Dorothy and Russ and the person who was on the IEEE
side previously listed as owner, four or five days ago and I didn't get a
response, which is why I put it in my ballot. I'm going to have to miss that
call so if someone who's going to join the call can take an action to bring
this up I'd appreciate it.

Suresh: I'll be there; I'll take it up.

Ted: I have a memory it's tracked but if you could reconfirm that would be

Alissa: I looked at the minutes from the last meeting and it's ambiguous if
they were going to start work on it or not.

 o draft-ietf-netconf-nmda-netconf-06  - IETF stream
   NETCONF Extensions to Support the Network Management Datastore
   Architecture (Proposed Standard)
   Token: Ignas Bagdonas

Amy: It has no Discusses in the tracker so unless there's an objection it looks
like this one is approved, to go to Approved, Point Raised.

 o draft-ietf-ospf-segment-routing-msd-21  - IETF stream
   Signaling MSD (Maximum SID Depth) using OSPF (Proposed Standard)
   Token: Alvaro Retana

Amy: I have one Discuss in the tracker. Alvaro, do we need to discuss that

Alvaro: I don't think we do. We're just waiting for an update, so we'll
definitely need a Revised ID for this.

Amy: This will go into Revised ID Needed.

 o draft-ietf-isis-segment-routing-msd-17  - IETF stream
   Signaling MSD (Maximum SID Depth) using IS-IS (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: We'll also need a Revised ID for this one.

Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-softwire-mesh-multicast-23  - IETF stream
   IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network
   (Proposed Standard)
   Token: Terry Manderson

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

Terry: Approved, Point Raised. The authors look like they're on the ball but I
just want to double check they've covered all the comments.

Amy: Great. This will go into Approved, Announcement to be Sent, Point Raised,
and you can let us know when it's ready to go.

 o draft-ietf-dnsop-kskroll-sentinel-15  - IETF stream
   A Root Key Trust Anchor Sentinel for DNSSEC (Proposed Standard)
   Token: Terry Manderson

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

Terry: I think we do. Not specifically on the Discuss item, but tangentially to
an issue that is raised as a sidebar: what we're going to do with regards to
reserving left hand side labels in domain names. Adam, you had lots to say.

Adam: I did and I said most of it in email. I raised this issue when the MTSTS
draft went through and I think it's as applicable here as it is there, which
is: it seems problematic to start taking names out of delegated name spaces
when historically this is something we've left to operators. I pointed out
parallels to what we've done with BCP 190 for HTTP when we say we're not going
to standardize use of URL components with the exception of this well defined
space. It seems like it might be a good idea to start a similar policy in DNS.
The email back and forth was converging, I think, on the idea that maybe we
could do something like that. I'm not sure how much appetite there would be to
pursue this. Warren made a comment that there might not be stomach in DNSOP to
take on a work item along these lines. I think it is a place where we could use
some clarity and guidance. I don't know if this is a recent thing where we've
had two docs come through as a fluke, back to back, that tried to do this sort
of thing or if we're starting to see use cases where this is going to become
necessary and having a well organized and partitioned part of the namespace to
do this in would be helpful.

Warren: We had a reasonable amount of discussion on this in DNSOP. According to
Stuart Cheshire, who wrote the RFC 6761 special use names document, his
document allows for reserving special use names anywhere in the tree. In
theory, this could be an RFC 6761 reservation. We asked in the WG if people
thought this actually counted as a special use name and I was kind of pushing
for that. The WG's interpretation of 6761 is different to Stuart's. The WG
didn't feel what Stuart thought it said is what they think it said. The WG came
to the fairly strong view that it's not a 6761 special use name, which is why
there isn't anything in the IANA Considerations section, suggesting it's a 6761
reservation. We have all the text and it was nicely written but the WG asked us
to remove it. This is definitely weird and odd. I think it's just a fluke that
we've got two of these recently but yes, this is sort of an open wound and it
should be dealt with. From my long interaction with DNS on special use I think
this falls on the special use names topic. Trying to get anything more done
there is just going to end poorly. Even an AD sponsored thing; the topic is so
toxic at the moment there's going to be a world of drama. Maybe that's fine.

Terry: Warren, do you think a very simple doc structuring a registry to put
these left hand side names in one place would be sufficient?

Warren: Possibly if it were just that, but it would reopen the question of
isn't this what 6761 is supposed to do? It could be a very short clarification
document explaining that 6761 either does say this or doesn't.

Ted: It's quite sure that we can make reservations anywhere in the tree because
IDNA relies on that. We actually reserved with xm-- that portion of the label
space for every part of the DNS hierarchy. If that's not going to be considered
something you can do through the special use names registry, we have to have a
mechanism for doing something in the future or we can never upgrade from IDNA
2008 to something that needs a different Ascii compatible encoding. You'd
certainly have my support and I suspect the support of anyone who thinks IDNA
might ever need a rev, for documenting that this is a special use name under
the meaning of the act.

Adam: Quick clarification: IDNA actually reserved any two characters followed
by two dashes.

Ted: You can use that portion of the name space for the uses you had laid out
in your email. I agree with that, that if you want to make ar registry that
says these are the uses of that portion of the already reserved name space, you
are well within what we've already reserved. The advantage of that is that
means we don't have to go back and have ad discussion with ICANN about why
we're taking yet more pieces of the namespace they might want to sell.

Adam: That's a good point I hadn't thought of.

Warren: The xm-- does make a good analogy. That's another spot where it's not a
new registry as far as I know. It's another one of these. I think having a doc
saying we already have this xm-- space we can use for stuff. Here are two other
ones which have already one similar things. there's another example which
Andrew Sullivan pointed out where some names are reserved. Somebody a while
back also made an analogy: postmaster, hostmaster, etc, are kind of reserved
because of the m name convention in DNS, and naming a machine
postmaster.whatever would probably end badly. I don't remember where that
conversation was. I think it would be useful to have a doc which creates this
registry and says we already have this one, you should try and use it. I'm not
sure where that leaves us.

Terry: I think that leaves us with me asking Benjamin to hold his discuss, and
Warren, are you able to follow up with the idea of creating that document which
may inform KSK roll sentinel?

Warren: I can try and create that document. It's going to be a long thing to
get through the DNSOPS discussion. There was also discussion of using xm-- for
KSK sentinel and the WG did not like that. I can figure out why if that would
be interesting. We suggested underscore and xm-- and the WG got annoyed.

Ted: I think maybe a part of the discussion with the WG it would be quite
useful to get that pulled out and if they have a belief that that's not
deployable for some reason, we really need to know it and to work on what we're
going to do about it. If they have an objection that is more aesthetic, let's
say, then I think we need to strongly encourage them to consider the advantages
that Adam has put forth.

Warren: Paul Hoffman had a thing that he thinks it's a bad idea because some
software has letterletter-- reserved even though it shouldn't. It seems some
software has been stupid and implemented some workarounds. The WG did not like
it. We could try again.

Adam: To be clear, the issue with the underscore prefixes in this context. Is
that limited to not being able to perform these queries from web browsers?

Warren: Most implementations will still fetch things, or will still resolve
place names that have that. Some implementations, Android and some linuxes,
will not fetch things that start with an underscore.

Adam: That was kind of the point. You can resolve them but you can't use them
as host names. The point of this draft are that you can resolve these.

Warren: And fetch resources from them. Somebody needs to fetch the resource so
the browser can say whether or not it was able to resolve the name properly.

Adam: That was my question. Is the fact that we can't use underscores limited
to the fact that we can't use them in web browsers? Is that the only driving

Warren: I believe so yes. The whole point of this is that it can be tested in a

Benjamin: If I can jump in, Terry, you asked me to hold my discuss. Is that
because wee'r thinking this document might change to use whatever new scheme is

Terry: That's where I was heading, but I get the feeling now after Warren's
replay that I don't think that's going to change the situation. I think we're
at a point here that this label may simply just go through but we will have to
do some additional work in dealing with future issues.

Benjamin: That's the conclusion I was coming to. I noticed in some of the DNSOP
archives that there was grumbling about changing which host names we're using
for this multiple times, and there would no doubt be more grumbling if it were
going to change again. We may just let this doc go through with the current

Ted: if you do that you need to follow up on two fronts. One, if this does
still need to get registered in the special use names registry, because it is a
reservation that other people in the DNS ecosystem outside the IETF need to be
aware of it. The second is you need a plan for going forward. Although this
seems like a pair of docs coming through that could be coincidence, my gut
tells me that if there are a couple of documents that start coming through
people are going to begin to see a pattern.

Warren: I think everyone recognizes that this is a bad pattern and should not
be repeated.

Ted: Why are they preferring it?

Warren: During the discussions it was that we shouldn't do this but the pain of
not doing it in this particular instance outweighs the pain of doing it.

Adam: In both of these cases the rationale has been we want to shove this in an
https url. I think hat's going to happen more frequently in the future than it
has int he past.

Warren: I can write an email to DNSOP that we need to figure out what we're
doing in the future. This is another looming problem.

Adam: What I would prefer to see is an update to 6761 that clarifies that all
of these uses are something that should be registered, and also adds both
MTASTS and these two patterns to the IANA registry.

Warren: I fully agree. I'm happy to push for that.

Terry: That seems like a reasonable path forward; let this go through but draw
the line here and any future attempts at left hand side reservations will be
stopped until we deal with a registry for this.

Warren: Sounds great to me. I would still like to remind people that we the
IESG still have an open thing that it's unclear what the use of special names
status registry means to people. Suzanne was the last person holding the pen on
coming up with a clear updated statement. That's a longer topic.

Alissa: I think it would be helpful to capture that line drawing in this
document. Some words that explain that for future reference.

Warren: Do you have any example proposed text? Basically we understand this is
a bad pattern?

Alissa: The thought occurred to me while you were talking that there are lots
of people who understand right now we're only doing this under exigent
circumstances, but it's helpful to write that down in the document so when
people come along later we can point them to it.

Warren: Sounds like a plan.

Benjamin: I will continue holding my discuss.

Terry: We can move on.

Amy: Sounds like this is going to require a Revised ID.

Terry: It will require a revised ID, but Benjamin will be holding his discuss
until we come up with appropriate text.

Amy: Okay, it will stay in IESG Evaluation, Writeup Needed.

 o draft-ietf-lisp-gpe-06  - IETF stream
   LISP Generic Protocol Extension (Proposed Standard)
   Token: Deborah Brungard

Amy: I have some Discusses in the tracker, do we need to discuss any of those

Deborah: I don't think so. I see Luigi is on the call if anyone has anything
they want to ask him.

Suresh: This doc is taking a flag from LISP; since you're basing the LISP
protocol should the flag be acknowledged?

Deborah: I don't know, we'll have to look at it.

Luigi: On the last comment, I agree yes to update this document. [muffled] We
have to solve a couple of things in this document but it looks good looking

Deborah: I think we can discuss more over email with the chairs.

Amy: Are the current discusses going to require a Revised ID?

Deborah: Yes.

Amy: Okay, we'll move on.

 o draft-ietf-lisp-rfc6830bis-20  - IETF stream
   The Locator/ID Separation Protocol (LISP) (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I would say not. There's discussion going on on the list; I'd put this
as Revised ID Needed.

 o draft-ietf-lisp-rfc6833bis-16  - IETF stream
   Locator/ID Separation Protocol (LISP) Control-Plane (Proposed
   Token: Deborah Brungard

Amy: I have Discusses; do we need to discuss today?

Deborah: Michelle added a very late discuss. We'll keep this as under IESG
evaluation and Revised ID definitely needed.

 o draft-ietf-extra-imap-savedate-01  - IETF stream
   Internet Message Access Protocol (IMAP) - SAVEDATE Extension
   (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Can I have this in Point Raised please, to make sure the comments are
reviewed by the authors?

Amy: You absolutely can.

2.1.2 Returning items


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-dnsop-isp-ip6rdns-07  - IETF stream
   Reverse DNS in IPv6 for Internet Service Providers (Informational)
   Token: Warren Kumari

Amy: I have no discusses in the tracker so unless there's an objection it looks
like this one is approved. Hearing no objection, this is approved. There are no
notes; is this ready to go as is?

Warren: I believe so; I think there are some editorial things to be cleared up.

Amy: This will go into Approved, Announcement to be Sent. Thanks.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items

 o draft-mahesh-etsi-urn-03  - IETF stream
   URN Namespace for ETSI Documents (Informational)
   Note: This is to add ETSI namespace identifier, specifically
   targeting YANG model development by ETSI.
   Token: Ignas Bagdonas

Amy: Ignas could not be with us today. I have a consensus flagged as Unknown.
Do we know if this is going to be yes or no?

Warren: I believe it will be yes.

Amy: Alexey, do you have a feeling if this is going to be Revised ID?

Alexey: I think it probably will be Revised ID.

Amy: We can put this in Revised ID Needed and Ignas can follow up as needed.

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


3.4.2 Returning items


3.4.3 For action

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

 o Source Packet Routing in Networking (spring)

Amy: The charter version is 01-02. I have no blocking comments for this; unless
there's an objection it looks like the recharter for SPRING has been approved.

Martin: Alissa, were you okay with my reply to your comment?

Alissa: I thought your answer was good. Do you think everybody who reads the
charter will have that same understanding?

Martin: I'll see if I can tweak the wording in the charter. I'll take a look.

Alissa: It seems a little bit ambiguous to me so the more clear it can be for
the standards are it will be better.

Martin: Okay, I'll see what I can do. Then the next step is to send this for
external review, correct?

Amy: No, do you think it needs an external review?

Martin: I think the original plan was to have an external review.

Alvaro: I thought we just did.

Martin: This is where I got confused. It went through internally and went in
front of us once, then I moved it to external review.

Cindy: An external review message was sent on September 10.

Amy: I was almost positive that had happened already.

Martin: I missed it! We are good then.

Amy: It generally doesn't show up as proposed for approval until it's been for
external review. If you want to make additional edits, it looks like it's
approved pending edits. With that you just let us know when your edits are in
the tracker and you're satisfied; then you can send us a ticket and we'll get
the recharter message sent.

Martin: Excellent, thanks.

5. IAB news we can use

Amy: Deborah, any news this week?

Deborah: No, I don't think so.

6. Management issues

6.1 Request from the tools team: update id-nits to allow for non ASCII in
drafts? (Alexey Melnikov)

Amy: Alexey, you added this and sent some text.

Alexey: I think after feedback from Sandy it looks like tools will be ready
around the end of the year, and then it will take 6-9 months for RFC editor to
implement. I see a couple of options; one is to say we'll review in six months,
but Robert asked about this because Paul Hoffman wants to publish a draft and
at the moment he needs to do manual posting and it's quite annoying. We might
want to consider allowing documents with non-ASCII on the condition that if
they are going to be approved by IESG for publication then they'll be delayed
until the RFC editor is ready.

Sandy: Our optimistic goal is to be publishing these documents 6 to 9 months
from now, not from December.

Alexey: You're suggesting we can move this decision point a bit earlier? One
option is to review in 3 or 6 months. Another option is to approve this now on
the condition that drafts can be posted with non-ASCII, but if they're approved
they won't be published as RFCs unless the editor is ready.

Sandy: As long as we're clear that if it gets approved the characters either
get reverted if they don't want it to be held or it's going to be delayed until
the tools are ready.

Adam: My understating is right now if you try to submit a draft to the website
it says it won't take it.

Alexey: Yes. IDNITS has warnings which would allow you to submit. This is
triggered as an error.

Adam: I think given the time frame it would be reasonable to demote this to a
warning; point out the caveats that if this goes to the IESG before the RFC
editor is ready it will be changed or held. When we talk to the tools team
about this we want to be careful not just about changing the status of this but
look at what characters are triggering it. For a lot of times you end up with
smart quotes and em dashes, which we do want to flag and prevent from going in,
so we want them to look at the rules in the format documents and allow those
things through but block things that aren't allowed by that.

Alexey: Yes, I don't think this will help you with smart quotes. The document
recommends that you always use unicode code in the text, or a unicode

Adam: These things are detectable. It's not as simple a change, I think.

Alexey: I tend to agree with you that I think Henrik thinks it's easier than it

Ekr: Is your thinking that smart quotes are a defect, whereas some other
characters are intentional? So we went to flag the things that are probably
screws vs the things that are intentional?

Alexey: Smart quotes can still be intentional, but they're probably unlikely to

Adam: They appear in weird places. A lot of the things that didn't match in
errata were because the quoted section had smart quotes, so someone had copied
and pasted out of an RFC, then on the way to the errata page had managed to
turn quotes into smart quotes. These things get put in myriad places apparently.

Alexey: All right, so with caveats about some characters that need to be paid
attention to, are we happy to allow non-ASCII by idnits on the condition that
if any of the drafts get approved by IESG it will be held or the non-ASCII

Adam: I'm good with that, yes.

Ekr: Sounds good to me.

Alexey: Okay, I think I can give Robert and Henrik the good news then.

6.2 Approval of port assignment for E1 interface (3GPP) (Mirja Kuehlewind)

Amy: Mirja added this but unfortunately she couldn't be here today. I guess the
question is, does anyone object to approving this?

Alexey: No objection.

Amy: Okay, I'm hearing no objection. Michelle, I'm assuming we need to send you
an official note.

Michelle: Yes, and also I probably need more details than what's in the
management item. I can get those from Mirja. I've been combing some old tickets
to see if I can find it. I do need some more details from Mirja so I'll drop
her a note today. If you send us the approval we'll make sure we get what we
need from her.

Ted: I think I have the start of this thread in email so I'll send you that and
if it doesn't trigger the right thing you can find Mirja.

Michelle: Thank you, Ted.

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