Narrative Minutes interim-2018-iesg-21 2018-10-11 14:00
narrative-minutes-interim-2018-iesg-21-201810111400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2018-10-11 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Deborah Brungard (AT&T) / Routing Area
Ben Campbell (Oracle) / Applications and Real-Time Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
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
Mirja Kuehlewind (ETH Zurich) / Transport Area
Warren Kumari (Google) / Operations and Management 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
Jeff Tantsura (Nuage Networks) / IAB Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

REGRETS
---------------------------------
Heather Flanagan / RFC Series Editor
Terry Manderson (ICANN) / Internet Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
chs8108181
Karen O'Donogue

1.2 Bash the agenda

Amy: Anyone want to add anything new?

Alissa: Did you get the agenda review item on this one?

Amy: Yes, that's been added as the last management item.

Alissa: Great. Thank you.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the September 27
teleconference being approved? Hearing no objection, looks like those are
approved. Narrative minutes from September 27 came out a couple of days ago;
any objection to approving those? Hearing none. And the BOF coordination call
minutes for 103; I sent slightly revised minutes yesterday. Any objection to
those? Hearing none, we'll get those posted too.

Spencer: I have a question on that. I'm not remembering that we've published
minutes from the BOF Coordination call before.

Amy: We've published minutes from the last couple years.

Spencer: This was more blow by blow than I'm used to. Maybe the IAB could look
at that too, since they were talking?

Amy: The IAB has seen both sets of the minutes.

Spencer: Thank you; I was just curious.

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].

Amy: I have this as a management item so I'll mark this as provisionally done.

Amy: All the rest are for Ekr.

Ekr: I haven't done any of these.

Amy: We will mark all of those as in progress for you, Ekr.

     o Eric Rescorla to find designated experts for RFC 8411 [IANA
       #1120853].

     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-netconf-rfc7895bis-06  - IETF stream
   YANG Library (Proposed Standard)
   Token: Ignas Bagdonas

Amy: I have no Discusses in the tracker for this document so unless there are
any objections it looks like this one is approved. Hearing no objection. Any
other notes needed for this?

Ignas: Probably no, but can you keep it as Point Raised so I can check that
everything was addressed? Thank you.

Amy: Sure.

 o draft-ietf-netmod-schema-mount-11  - IETF stream
   YANG Schema Mount (Proposed Standard)
   Token: Ignas Bagdonas

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

Ignas: Probably not. The discussion with the authors is ongoing and it's
promising that it will be resolved. This simply needs time and I don't believe
there's anything to discuss here.

Amy: Will it require a revised ID?

Ignas: Probably.

Amy: We'll put that in Revised ID Needed.

 o draft-ietf-tictoc-1588v2-yang-10  - IETF stream
   YANG Data Model for IEEE 1588-2008 (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: One thing I would like to discuss is the issue of the paywalled
document. I do understand Ben's concern but I'm not sure how we can go about
resolving it. We did have this discussion with IEEE before and we didn't get
anywhere; I would like to spend a couple of minutes to see how we can move
forward.

Ben: There are two things in there, a generic and a specific. I just saw an
email from Karen that said they did have a liaison working with the WG and they
made the IEEE document available to people in the WG who weren't able to get it
through other channels. They probably could have made it available to other
reviewers too and maybe could have been more up front about that.

Suresh: They were willing to share it as long as we tell them who they are but
that doesn't raise the openness point.

Ben: I don't like paywalled standards but I wasn't trying to throw rocks at
that. What I was complaining about was the idea that we make a proposed
standard document which must have limited review because there's limited access
to the document necessary to understand and do a decent job of reviewing this.
I imagine most of the IESG didn't get a look at that document, maybe some did.
It seems to me that in that case, Proposed Standard might not be the best
status. We might be better off picking informational or in the case of Yang
documents, encouraging that other organization to publish their own.

Ekr: I concur with Ben. In the past when we had these same problems we would
produce a normative version of the same text with the other standards body's
documents and publish the RFC and use that as a reference. If we can't do that,
and this depends on that, I don't see how we can publish this as proposed
standard.

Suresh: One of the things is if you do an informational document there's no
value in it, right? The reason IEEE asked us to do it is they couldn't do it to
start off with. We could probably punt this over to them and be done with it.
The other thing is we can ask for access to the document. That's the two ways I
see forward. Taking this as informational I don't think adds that much value.

Adam: Can you unpack why having an informational version of this document
wouldn't be valuable?

Suresh: If you want interoperability we need some kind of standard track to say
what needs to get done. If this goes as informational someone is going to say
this is mandating stuff, it shouldn't be informational. Last time this happened
we had the discussion of the stuff from the IEEE standard copied into the
draft.  The IESG at the time was holding a Discuss saying we were copying
stuff. That's why the document is this way. There seems to be no good way out
of it. If the IESG feels we should go back and get more context or get the
document available that's something we can do. If we feel that making this
Informational would help, that's okay too. I don't want this to hang around for
a year like the last one did. One thing we know for sure is IEEE is not going
to budge on the copyright issue so I didn't want to go down that path.

Ben: It's been pretty common or us to publish informationals that describe
protocol mechanisms from the perspective that it's not a standard but we're
publishing this for your information because it's something a third party does.
If you want to interoperate with them you can, it's up to you. I would see that
to be kind of similar if we were to do it here. From the proposed standard
perspective, if you talk about making the document available that could solve
the problem, depending on what 'make it available' means. There's also the
issue of having a proposed standard out there that's not an open standard
because it depends on something that's not open. Which would be another
argument for making it informational or handing it back to the IEEE.

Spencer: The last time I looked, for 802 they make their stuff freely available
after six months. Is that still not the case?

Ben: I understand from Karen's email that is not the case for this WG.

Spencer: The 802 stuff isn't freely available until six months pass after
approval. I thought that was the way it worked.

Ben: That would make me feel better about this.

Spencer: If the answer is that we're not going to approve anything that you
can't implement without spending money, that covers a lot more than 1588.

Ben: That would cover patents and I don't mean that here.

Spencer: You can't get a copy for free of an approved 802 document for six
months.

Suresh: To be frank, we've done documents before where this is the case. There
are IOT documents that are more closed than this. I can ask people if they
think the review has been performed by the people who know this other document.
I think this is a bigger issue and I do agree with you. I can see if I can get
access to the IESG and then see if we can open it up. The open it up thing has
been tried before and it didn't pan out, sometime in 2016.

Adam: First I want to make a quick point that publishing this even without
access available to most people for the document is probably fine inasmuch as
It does provide a way to implement the client side of this without needing to
know the internals of the document, assuming we take on some of the suggestions
made by for example Benjamin. I don't think there's necessarily a problem with
that aspect of it. For the process side, what I would propose is that we take
the offer Karen outlined and make that clear on the IETF list. Put it out for
another last call and say if you're interested in reviewing this, here's the
process for requesting access to the document it depends on, allow interested
reviewers to do that, and then run it through another IESG telechat.

Ben: My cynical side says no one will actually do it, but that's okay.

Adam: That's okay, we can't force people to review, but people need to have the
opportunity to do so.

Suresh: Do we want to make this policy going forward for any paywalled
documents? If we go with that it's fine, but I don't want someone to come back
to me and ask why this one was selected.

Warren: What sounds like might be a way forward is I think many other people
who will be implementing it are likely to already be aware of the IEEE side,
but this document doesn't seem like the hill we want to die on. What we might
want to discuss at 103 is some boilerplate: This document relies on some
paywalled stuff which people might not have access to. We saw the document
while reviewing it.

Adam: That's assuming we can make the second half true, which is what I'm
asking for.

Spencer: There are two conversations; one if it's true and one if it's not.
Including information about this in the shepherd writeup is a question we're
asking people to think about. If this had started out with us knowing how many
people had seen the document and what the process was to see it in the WG.  I
think some of the discussion assumed that even the WG hadn't seen it. That's
more problematic to me.

Suresh: That's really not a concern for me. I know everybody who wanted to see
this had seen it. But the IETF Last Call point still stands. If someone wanted
to review it but couldn't because this wasn't available, that's a bigger
concern. I did have an idea, not for this document but in general. If you have
something like a downref, we could have something that says this has a
reference to a paywalled document and then go from there. That's pretty much
it. Also Karen is on the call if you have any questions for Karen, or if she
wants to say something too.

Ben: I said I would clear my Discuss after discussion and I plan to do that.
I'll echo Spencer's usual answer: do the right thing. I'm okay with the idea
that this isn't the hill we want to die on and we don't want to hold this WG
hostage to a potential change in policy. I'm happier with the idea of letting
this one go with better access to the base document and another WG last call as
Adam proposed.

Spencer: You're saying better access for the last call reviewers.

Ben: Yes. But I do think this is something we should discuss, in 103 or
elsewhere soon, because I'm not sure the policy we have now has looked at it
from the perspective of what it means to be a proposed standard.

Alissa: It sounds like we have the next steps here. I heard Suresh agree with
the idea of re-running last call and making it clear people could get access to
this specification if they wanted to review. We'll bring it back on a telechat
and in the meantime we'll plan for more discussion in Bangkok.

Suresh: That works. Ignas, for the Yang doctor review, if you want me to hold
it for that it's fine too.

Ignas: That can be done in parallel with the last call.

Suresh: Karen mentioned there are Yang doctor reviews too; we can send you a
pointer to it. I will make sure you have the information and do the last call.

Alissa: Would somebody like to be the stuckee for leading the broader
conversation in Bangkok?

Suresh: Me. I want to get this done.

Amy: It sounds like there's a lot going on with this document. I'm not sure
what to do with it.

Suresh: AD Followup and I'll cycle it back into Last Call once I set up the
groundwork with the IEEE.

 o draft-ietf-dhc-dhcp4o6-saddr-opt-06  - IETF stream
   Softwire Provisioning using DHCPv4 Over DHCPv6 (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: No thank you, we'll take care of it over email.

Michelle: We did send some requests for changes to the document from the
authors and never heard back. If I resend that message to you, can you help us
get those changes in thee document?

Suresh: Yes. I did ping them already to take a look at IANA comments already.
Send me the email and I'll make sure.

Amy: That sounds like it's going to require a Revised ID.

 o draft-ietf-dnsop-attrleaf-14  - IETF stream
   DNS Scoped Data Through "Underscore" Naming of Attribute Leaves
   (Best Current Practice)
   Token: Warren Kumari

Amy: I have no Discusses in the tracker for this document so unless there are
any objections it looks like this one is approved.

Warren: Can I ask a question? There are no Discusses, but does anyone have any
heartburn about this?

Adam: I want you to do your own evaluation of the issues surrounding overlap
between this and the ENUM services registry.  I think it's highly problematic.
I want a second opinion on whether moving forward in this fashion is going to
cause more harm than good. If you could look through that issue I'd appreciate
it.

Benjamin: I'd also like to hear Ace's thoughts on that. The impression I had
from that exchange was the intent was to make it a distinct operation to have
an ENUM service vs having an ENUM service that is used in a URI DNS record. It
was intended to be an additional step that you do if you want to use the ENUM
service thing in DNS records. But not all ENUM services would inherently be
added to the DNS registry.

Adam: I understand that position but I think it's at odds with what RFC 7533
says on its face.

Benjamin: Were they updating [RFC 7533 in draft-ietf-dnsop-attrleaf-fix] in the
other document?

Adam: Well if they did it wasn't to explicitly say the rules surrounding when
these can be used are explicitly changed, so you have to register this as a
separate concern.

Warren: I don't actually know. Would it be reasonable as a compromise to have a
note in the ENUM registry saying if you're making changes you almost definitely
want to update this one as well?

Adam: Yes, that's what I asked for.

Warren: So not a formal tie, but a: if you do this you should probably also do
that too. Make sure you know what you're doing.

Adam: What I asked for was more formal than that, but if we do he updating of
7533 that explicitly decouples the actions, saying you need to take this extra
step for it to be allowable to use it in this way. And we add a note to the
ENUM services registry to say you want to make sure you have examined the issue
of if it should be registered in this other table, and I think that's a
perfectly fine path forward as well.

Warren: Thank you. I don't know if this would be Revised ID Needed or if it's
the other document.

Benjamin: I think I had some comments that could produce a Revised ID if you
want to leave it in that.

Adam: There are still missing entries in the tables.

Warren: In that case, Revised ID Needed.

 o draft-ietf-dnsop-attrleaf-fix-05  - IETF stream
   DNS Attrleaf Changes: Fixing Specifications with Underscored Node
   Name Use (Best Current Practice)
   Token: Warren Kumari

Amy: I have some Discusses in the tracker. Do we need to discuss today or did
we cover most of the issue?

Warren: I think if we can discuss it would be helpful.

Alissa: One thing I realized as I was going through this: This is not going for
BCP. The shepherd writeup says BCP, the document says standards track. The
shepherd writeup clearly was not for this document, it was for the other one.
There's still an issue there but I wanted to clarify that what I wrote in my
ballot is probably wrong.

Benjamin: The intended RFC status in the datatracker [document status] page
says BCP.

Alissa: There's something to clarify here, one way or the other.

Warren: I believe the authors resubmitted the most recent version today; they
swapped it from BCP to Standards track, posted yesterday. So either it goes
back to BCP, which seems like a bad option, or it needs another last call.

Spencer: I thought BCPs and Standards track were treated interchangeably for
stuff like that. Is that true?

Alissa: That is true. The premise of my discuss is off but I do still think
there's a problem there. Essentially what I understand is that it went to last
call as BCP but it has a giant list of informative references to standards
track documents, because those are being updated by this; but those are all
listed as informative references. There's a huge list of downrefs in the last
call announcement and also a huge list of unused citations because they're not
actually cited in the body of the doc, they're just listed in the updates
header. This kind of gets me to the core question I have: what's the point? I
understand basically what the point is but is it actually meant to be that
these documents are updated by this, in which case if a new version of that
document were to be published you'd include this text in the IANA
considerations section? If so it needs to be specific which changes need to get
made to which document.

Warren: A fair bit of the problem is in many cases it would be an IANA section
and a please update section. That might be tricky to word. Many of these could
simply be, when doing this, the IANA sections should have said this. I
understand it's an odd case.

Alissa: You have the other document already, why do you need this one? Most of
these documents aren't going to be revised.

Warren: I think part of it was the WG became tired with how long the other
document was and it felt cleaner to split this in half and move all the updates
into this. But I think when that happened, the assumption was the updates would
be more standard - replace this text with that text.

Alissa: Do you think it needs to be published, in general?

Warren: I can go back and ask the WG. I remember they felt very strongly about
a lot of the stuff in these documents. An option would be to talk to them, and
the author. I suspect people will be fairly frustrated if it was one document
split into two and then we decided to get rid of the second one. The short
answer is, I don't know.

Benjamin: I do think there is value in changing these documents that are
effectively saying any registered protocol name can go in this _DNS label, to
instead say there's a registry for these things and _tcp and _udc make sense
but ignore the other stuff in the registry.  Whether we need the full extent of
this document's text is less clear.

Warren: Some of these documents will be updated at some point. When those get
updated, having a flag so someone says, it's also updated by this. I should
probably add this other stuff. I think it is actually useful to do this. It
seems like it would be incredibly long if we were to break up for each of these
documents if there was something useful in IANA considerations.

Benjamin: I don't think that was what Alissa was asking for. We have two or
three sections where it says this class of changes can be made and this class
of changes applies to X, Y, and Z. You wouldn't have to do an old and new for
each specific document that would be updated.

Alissa: There are basically 35 documents this document updates, but there are 3
classes of updates suggested and not all of them apply to each of the 35
documents. What I suggested in email was if we could just list to which
documents do the updates in each of those sections apply. That's it. Then make
those normative references and you solve the unused references, you solve the
downref problem, and you have clarity for anyone who eventually does go to
update these documents.

Warren: That sounds much less terrifying.

Adam: There was a little pushback from the author. I think all of that can be
backed out of the table that's currently in the base document. He implied there
was going to be a mass effort to go through every document in this list. But I
think that's already been done.

Alissa: Yes. That was my assumption.

Warren: Last thing. If this goes from BCP to Standards track, do we need to do
stuff for that? I can't remember if that needs a second Last Call.

Alissa: I think so?

Ekr: I think for avoidance of doubt.

Spencer: If the community comes back and tells you they're equivalent so this
isn't needed, you'll know what the community thinks. So that's not a bad idea.

Warren: Thanks everyone.

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

 o draft-ietf-tsvwg-fecframe-ext-06  - IETF stream
   Forward Error Correction (FEC) Framework Extension to Sliding
   Window Codes (Proposed Standard)
   Token: Spencer Dawkins

Amy: I have no Discusses but a couple of open positions. Unless there's an
objection now it looks like this one is approved. Hearing no objection. Any
notes required?

Spencer: This is probably an AD Followup to make sure we know where we are with
all the comments. There was a ballot that arrived during the telechat so I'm
not going to tell you there are no notes required.

Amy: Okay, Approved, Point Raised.

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

Amy: I have a few discusses, do we need to discuss those today?

Spencer: I believe most of the most critical Discuss points are talking about
the way C works in different architectures, and I think it's a very fine
conversation to continue in email and I appreciate that a lot from the people
who have contributed. The one remaining was the question about what can we do
with BSD licenses for code fragments? I believe Alissa has already sent off a
note to the lawyer asking for clarification on that, because different ADs had
different understandings and experience.

Ekr: I felt like there was a broader point Adam raised: is this code the
normative description of this algorithm? Or is this code example? And do we
really want to have this code being the normative description of this algorithm?

Spencer: I might have understood what was going on but I thought the question
there was: We know having normative code that depends on the architecture it's
running on is probably a bad idea. Can we do things to the code to make it not
depend on what the architecture is?

Adam: That's not quite right. The issue is normative code can be difficult to
maintain and it can surprisingly be ambiguous because of the portability issues
that Ekr identified. Fixing those just fixes the things we noticed, it doesn't
fix the issues with maintainability. Ideally we would have a prose description
of the steps involved. If you read the algorithm its pretty simple except for
this magic with assuming certain IEEE formats are floats. The operations are
pretty straightforward and can be described in English without a lot of work.
That would be superior to what's in there now. I thought after the opus codec
was published we could have a broader discussion about the use of code as
normative specifications. I couldn't find it; it must be a ghost memory.

Ben: I remember that too but I can't point to it. I will say members of the
opus working group have been on record to say we shouldn't do that again. Bear
in mind, opus is an entirely normative code and it's huge, compared to this
small thing. Scale makes a difference. The issue they ran into is that the
minute they published, the actual code people were using drifted from that. Now
when they make updates to match what the industry is really doing it's been
really hard. Had it been in prose, it would be easier to just do updates or
obsolete drafts.

Spencer: Thank you all for upleveling the conversation. The document shepherd
is the AD that I took over from, so I'm pretty sure he's going to understand
what kinds of issues we're talking about. I think I know what to do now.  So I
think this is at least document continues under discussion and Revised ID
needed.

 o draft-ietf-iasa2-trust-update-02  - IETF stream
   Update to the Process for Selection of Trustees for the IETF Trust
   (Best Current Practice)
   Token: Alissa Cooper

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

Alissa: You can put it in Point Raised; I just want to give the trustees time
to consider the update about the trust chair selection.

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

 o draft-ietf-httpbis-rand-access-live-03  - IETF stream
   HTTP Random Access and Live Content (Experimental)
   Token: Alexey Melnikov

Amy: The last call for this document ends tomorrow. It looks like I have one
active Discuss; do we need to discuss that today?

Alexey: Alissa had a good point; I'm not sure how this document made it on the
agenda before Last Call ends. If we could approve it on an informal next week?
I will also ask the authors to have a look at the comments. So my understanding
is that Alissa will clear once the Last Call is over.

Alissa: Amy, I'm curious if we know how this ended up on the telechat before LC
was over?

Amy: Yes, we've done this before; if it's within a couple of days and you issue
a ballot we add it. I thought the process was that last call ends and then you
issue a ballot, but this happened simultaneously so I thought there was a big
need to get it on a call.

Alexey: It wasn't urgent, sorry.

Amy: We will keep this in Last Call. Did you want to add it to next week's
informal for approval?

Alexey: Yes please.

 o draft-ietf-iasa2-trust-rationale-03  - IETF stream
   Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust
   (Informational)
   Token: Alissa Cooper

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

Alissa: Let's put it in Point Raised like the other one.

Ted: Quick question to Alissa: Are you waiting for the CCG for any of this?

Alissa: I think so, yes. I haven't seen a response from Russ.

Ted: You may want to explain to the IASA2 folks why it's waiting.

Alissa: Let me try to find Russ today.

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-historic-simple-ip-00
   IETF conflict review for draft-historic-simple-ip
     draft-historic-simple-ip-03
     Simple Internet Protocol (SIP) Specification (ISE: Historic)
   Token: Suresh Krishnan

Amy: I have no Discusses so unless there's an objection it looks like the
conflict review is ready to go back to the ISE.

Suresh: Ben, I think this one came before the other one, but I think I got your
point in there.

Ben: I didn't expect a change.

Suresh: I thought the thing was to put it like Karen's WG that it's relating to
5742. I wouldn't mind putting in the...[cut off]

Benjamin: I can definitely understand putting the current WG in. But the IETF
work that is most closely related to this was probably the IPNG.

Suresh: I thought about it but the 5742 has a set of canned responses and I
didn't want to put too much in there.

Mirja: It looks like the conflict review is okay but I'm wondering how we can
better coordinate this in the future. I think we've put concluded WGs in before.

Suresh: I think this is ready to go.

 o conflict-review-mst-lgapi-00
   IETF conflict review for draft-mst-lgapi
     draft-mst-lgapi-10
     Looking Glass command set (ISE: Informational)
   Token: Warren Kumari

Amy: I have no Discusses; unless there's an objection it looks like this is
approved to go back to the ISE. Hearing no objection, this will go back to ISE
wth the note currently in the tracker.

3.4.2 Returning items

 NONE

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

 o CBOR Object Signing and Encryption (cose)

Amy: Ekr, you are reanimating the COSE WG. I have no blocking comments so
unless there's an objection this is ready for external review.

Ekr: A number of people commented that they thought this had to go to external
review and that's what I intended to do.

Spencer: I think I started that ball rolling and I was saying thank you.

Benjamin: When you go to ballot they have the ballot question say "Is this
ready for external review or does this not need external review?" In this case
the question is explicitly, is this ready for external review? So you did it
exactly right.

Amy: This was a concluded WG; it's like if you're proposing a new WG it starts
all over again. Looks like external review is approved and we'll get it back on
the agenda for next time.

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

Deborah, from email: "The IAB is planning on a joint workshop of the IAB and
the W3C Technical Architecture Group (TAG), tentatively planned for January.
The logistics are still being worked out, it is not publicly announced yet. The
workshop is called "ESCAPE", Exploring Synergy between Content Aggregation and
the Publisher Ecosystem."

6. Management issues

6.1 [IANA #1125359] Management Item: Acceptance of media type registration from
standards organization CDISC (IANA)

Michelle: This is to ask if we should be adding CDISC to the list of standards
organizations that we accept media from.

Alexey: I looked at their website and they look legitimate but I haven't heard
of them before. I think I'm okay with adding it to the list.

Amy: Hearing no objection, they are approved and we'll send official note to
IANA.

6.2 Proposed Telelchat Agenda Dates Between IETF 103 and IETF 104
(Amy/Secretariat)

The schedule was discussed and will be as follows:

Thursday, 2018-11-08: IETF 103, Bangkok
Thursday, 2018-11-15: No meeting
Wednesday, 2018-11-21: Formal *Date change for US Thanksgiving
Thursday, 2018-11-29: Informal
Thursday, 2018-12-06: Formal
Thursday, 2018-12-13: Informal
Thursday, 2018-12-20: Formal
Thursday, 2018-12-27: NO MEETING Winter Holiday
Thursday, 2019-01-03: NO MEETING
Thursday, 2019-01-10: Formal
Thursday, 2019-01-17: Informal
Thursday, 2019-01-24: Formal
Thursday, 2019-01-31: Informal
Thursday, 2019-02-07: Formal
* Week of 2019-02-11: BOF Coordination call for IETF 104
Thursday, 2019-02-14: Informal
Thursday, 2019-02-21: Formal, Conflict resolution for IETF 104
Thursday, 2019-02-28: Informal
Thursday, 2019-03-07: Formal
Thursday, 2019-03-14: Informal
Thursday, 2019-03-21: No Meeting (travel)
Thursday, 2019-03-28: IETF 104, Prague

6.3 Proposed Designated Experts for draft-ietf-6tisch-6top-protocol [IANA
#1119883] (Suresh Krishnan)

Suresh: I sent in some name suggestions [Xavi Vilajosana Guillen, Thomas
Watteyne] about 10 days ago and didn't hear any adverse reactions, so I'd like
them to be approved.

Amy: I hear no objection so they are approved and we'll send the official note
to IANA.

6.4 Wrap-up clashing with side meetings (Alissa Cooper)

Alissa: Currently the wrap-up meeting at 103 is scheduled for 10 am on Thursday
and we have the time open for side meetings starting at 9 am. There are a few
that are scheduled already if you want to take a look. The IAB seemed to be
mildly in favor of breakfast meeting from 9 - 10 and then we could attend side
meetings afterward. Do you want to keep it at 10 am, or move it earlier in the
morning?

Adam: My feelings haven't changed, which is that by Friday I'm exhausted and
happy to take the extra hour of sleep. I'm in favor of keeping it in the brunch
slot we originally decided, 10 am.

Alissa: It sounds like the IESG wants to leave it where it is and there wasn't
strong momentum on the IAB to move it. So we'll leave it at 10.

6.5 IETF 103 agenda (Alissa Cooper)

The most recent changes to the 103 agenda were discussed.

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