Narrative Minutes interim-2018-iesg-07 2018-04-05 14:00
narrative-minutes-interim-2018-iesg-07-201804051400-00

IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2018-04-05. These are not an
official record of the meeting.

Narrative scribe: Liz Flynn (The scribe was sometimes uncertain who was
speaking.)

1. Administrivia
1.1 Roll call

0703 PDT Amy: Call to order; attendance from Webex participants list

    Ignas Bagdonas--- +
    Deborah Brungard--- +
    Ben Campbell--- +
    Alissa Cooper--- +
    Michelle Cotton--- +
    Spencer Dawkins--- +
    Heather Flanagan--- regrets
    Sandy Ginoza--- +
    Ted Hardie--- +
    Benjamin Kaduk--- +
    Suresh Krishnan--- +
    Mirja Kühlewind--- +
    Warren Kumari--- +
    Terry Manderson--- regrets
    Alexey Melnikov--- +
    Cindy Morgan--- +
    Eric Rescorla--- +
    Alvaro Retana--- regrets
    Adam Roach--- +
    Jeff Tantsura--- +
    Amy Vezza--- +
    Martin Vigoureux--- +
    Portia Wenze-Danley--- regrets

Guests
        None

Observers:

        John Leslie--- +
        Alexa Morris--- +
        Liz Flynn--- +
        Greg Wood--- +
        Susan Hares--- +
        Nils Ohlmeier--- +

1.2 Bash the agenda

Amy: Does anyone want to add anything new? I removed a document earlier today,
I missed a document that was assigned a shepherd earlier in the week and it's
under review now. Any other changes? No, terrific.

1.3 Approval of the minutes of past telechats

March 8 minutes -- approved
March 8 narrative minutes -- approved

1.4 List of remaining action items from last telechat

 o Benjamin Kaduk to find a designated expert for RFC 5793 [IANA #1050763].
Amy: [This used to be Kathleen's.] Clearly that's going to be Benjamin's going
forward. Benjamin: No movement yet, still in progress.

 o Adam Roach to find a designated expert for RFC 8225 [IANA #1055836].

Amy: This was added to the list just a few days ago, so Adam, you are on the
hook. Are you aware? Adam: Yes, I am, I have some queries out already. Amy:
We'll mark that as in progress and move on, thank you.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-sidr-slurm-07  - IETF stream
   Simplified Local internet nUmber Resource Management with the RPKI
   (Proposed Standard)
   Token: Alvaro Retana

Amy: I currently have a couple of discusses in the tracker for this and
unfortunately I don't think Alvaro was able to join us. From the discuss
holders, do we have an idea whether their discusses are going to merit a
revised ID or should this go into AD followup? Adam: The author is being
responsive, I think it will be taken care of, they agree changes need to be
made. Warren: I haven't gotten a response for mine, but it might just be me
being dumb. Benjamin: I had the same question you did, Warren, so I think we
should wait to hear from the authors. Warren: Okay, surprised no one wanted to
call me dumb! Amy: It sounds like this is going to require a revised ID and
maybe some continued conversation.

 o draft-ietf-6tisch-6top-protocol-11  - IETF stream
   6top Protocol (6P) (Proposed Standard)
   Token: Suresh Krishnan

Amy: I've got a couple of discusses in the tracker. Do we need to discuss those
today? Suresh: Not really, some came in this morning and the others are from
email. I think the discusses are clear and it's just a question of getting them
taken care of. I'll wait for the authors to get back on this and if something
doesn't work out I'll put it back on the telechat. I don't think we need to
discuss it today. Michelle: We are waiting for Tero and Pat to get back with
the expert reviews, so that will allow them a little more time. Amy: Suresh, is
this going to require a revision? Suresh: Absolutely. Thank you.

 o draft-ietf-mmusic-trickle-ice-sip-14  - IETF stream
   A Session Initiation Protocol (SIP) Usage for Trickle ICE (Proposed
   Standard)
   Token: Ben Campbell

Amy: I have a number of discusses in the tracker, do we need to discuss today?
Ben: I think we need to discuss one point. Most of the points just need to be
worked out with the authors and that process is starting. There has been a
structural issue where JSEP referenced some things from ICE that are no longer
there. We've had a separation in the current versions from trying to decouple
ICE from SDP. The structure we have right now has orphaned some of those
references. There's an ongoing discussion about how to fix that. The
frontrunner is to create a new draft that is for the Trickle SDP and separate
the SDP aspects vs the SIP aspects into the second draft and then make that the
one that is referenced from JSEP. I've asked the authors to look through and
find how many references we have a problem with and how deep this goes, that's
in process now. We've got some feedback that it's more than one. From my own
scan reading this draft from that perspective, I see there are some places
where the use of SDP and SIP are fairly intermingled. For example, the 
discussion of the SDP that is used to trickle new candidates is part of the
discussion of sending an own SIP info request. What I wanted to find now is
that the people who are concerned about this, if their WG agrees, would you be
okay with the structure that says we have a separate new draft for the SDP
aspect of Trickle, and JSEP would make its relevant references to that.

Adam: I am perfectly happy with that; that is probably the ideal structure, I
was concerned that people would balk at the amount of work involved in teasing
this apart.

Ben: They haven't exactly decided if they're balking yet.

Adam: If they want to go down that path I think that's the best structure we
could hope for once things actually land as RFCs. Ekr: I concur with Adam, by
the way.

Ben: This is obviously going to require some working group discussion to get
the WG to agree to that path. Some people have come out in favor but I wouldn't
say there's consensus yet. That is the direction I'll recommend and we'll see
what happens.

Ted: I hesitate to make a comment as IAB chair, but as RTCWEB chair, I agree
with you that this is ideal, however if you look at the actual reference that
JSEP needs, it's quite modest. Had we realized that inheriting this
construction from the extra document was going to cause confusion and delay, we
almost certainly would have simply recommended that it goes into JSEP itself,
with some later document that's inheriting it from JSEP. Which is structurally
unsound, but far more practical than the proposal that is going to push Cluster
238 out about six months again. Six months is maybe not as optimistic or
hopeful as I usually am, since it's usually Ted the Pollyanna, but it's early
in the morning and I haven't had much coffee, so cynical Ted is saying Cluster
238 backing off by this amount of time, because that's going to happen, doesn't
seem like a win.

Ben: Let me talk about the other alternative then, the minimal change
alternative, would be to have JSEP change their references to point to this
draft. Ted: No, the alternative is having JSEP define the thing itself. Ben: I
think the thing is defined. Ekr: I think Ted's suggestion is that we simply
copy that definition by value, and have two definitions that are hopefully
identical. Ted: Yes. That means JSEP and 238 don't have to wait for this, they
don't have a normative dependence on SIP, and you don't have to go through the
pain and suffering of splitting these two documents up, because now the
definition for SIP and SDP are consistent with what's going on in JSEP, but
realistically SIP and SDP are intertwined enough in any case that they probably
don't need to do this extraction, except for the fact that JSEP is also a user.

Adam: I'm not sure what you're proposing is faster, Ted. There are a few things
that are referenced that would have to be formally defined. Pulling it out of
the RFC editor queue to add this syntax is probably going to take a significant
amount of time. I think you're underestimating that task.

Ekr: it also turns out the JSEP editors are actually not that responsive.

Ted: I'm not going to argue that with one of the editors, but I believe we may
be both underestimating the task. Ben is proposing something that nobody has
balked at, but nobody has gone and written a pr2, either. It's non trivial and
it's going to take an extra N months where N is large.

Ben: I'm going to hope it's not that large, because other than agreeing to do
this, the material exists. It’s just a matter of reorganizing it. It's not like
we have to get consensus on mechanism. I recognize that often that's the part
that takes the time, getting the editorial stuff right.

Alissa: It's on the same people either way. You can put it in another document,
you can put it in JSEP, it's the same people's time.

Ben: Based on what Adam just said, I'm going to reassert that what I thought
was the simplest approach was to retarget the JSEP references. In the past
people have balked at JSEP referencing its own document. [Correction from
Benjamin: referencing a SIP document.]

Ted: Dependence on SIP would be very hard to sell.

Ben: It's not like we would be saying you have to implement SIP, but I assume
what people are concerned about is the structural dependency of the document.
Is that correct?

Ted: The idea we would hand to a JSEP person a document that then they would
have to read all of SIP to pull out the four bits they want is pretty hard to
sell.

Ben: I don't think they would have to read all of SIP.

Ekr: I agree with Ted, this would be a difficult sell. I know I would oppose
this, I believe Cullen and Justin would oppose it as well.

Ben: Cullen has already opposed it. I was just trying to understand the nature
of the opposition.

Ekr: The graph ought to look as clean as possible. So far the graph has avoided
pointing to SIP.

Ben: Okay. So it is the formal structure of document dependencies we're talking
about.

Ted: If you're fine with that I won't change the argument.
I still believe that's why putting the actual definitions into JSEP is the
cleanest thing we could possibly do here. Also point out a really bad idea
Cullen and I had: since we have Suhas's document lying around we could say look
it's' mostly examples, except for these three things that are actually
normative, upgrade it, and use it as this is an additional place you might
shove these things if you have trouble getting the structural stuff done and
just let the very small number of things JSEP cares about.

Ben: I think that would be almost identical to the effort of creating the new
draft, other than the boilerplate - extracting the same bits and putting it
somewhere else.

Ted: I think where we're having this mental disagreement is that in one case,
the number of bits you have to extract and put in a JSEP document or RTCWEB
document are a fairly small subset of the productions in this document. If you
wanted to say that it's simpler to take every single production and put it in a
different document, as opposed to figuring out which ones are JSEP specific, we
can certainly have that discussion. But its clear there is a larger number of
productions than the number jsep uses. I fear we are boring the larger
community here so I invite Ben to the RTCWEB chairs meeting on Thursday and see
if we can have the rest of this discussion there. It's at 1030 Eastern today.

Ben: I was going to say the same thing, we probably need to take the discussion
offline.

Ben: I want to make sure no one needs to discuss any points other than this one.

Amy: This will go into the state of revised ID needed. Discussions will
continue.

 o draft-ietf-pce-lsp-setup-type-09  - IETF stream
   Conveying path setup type in PCEP messages (Proposed Standard)
   Token: Deborah Brungard

Amy: I have a discuss in the tracker, do we need to discuss that today?
Deborah: Warren, do you want to discuss today anything?
Warren: The entire section 6 says any piece of document should answer all of
these questions, then there's a bunch of questions they didn't' answer. Until
they answer that there's not much we can do. Deborah: It's for any document
that will be setting up a new registry type. This document is only setting up
the registry, then any document that wants to add a co-point to that registry
needs to have those clarifications in it. Warren: Wow, I completely
misunderstood that! Deborah: I can see they should add a clarification sentence
there. They should've probably added that. Warren: I should have reread it. All
good now. Deborah: The author is on the call but the one holding the pen is on
vacation so we'll get to deal with it next week. Keep this one under
evaluation. Amy: You have a choice of Revised ID needed and point raised.
Deborah: Warren, you removed your Discuss already? Put it point raised, and
revised ID needed. It's definitely going to need to be revised.

 o draft-ietf-6man-ndpioiana-02  - IETF stream
   IPv6 ND PIO Flags IANA considerations (Proposed Standard)
   Token: Suresh Krishnan

Amy: There are no open positions and no Discusses for this document.
Suresh: It's going to require a revised ID but I don't think it's going to be a
big deal. I had a question for the IESG as well. I saw a lot of positions that
said this should update 6275. I personally don't think it should but I don't
have an issue making it update 6275. Because it's 6275 that needs to be fixed
to say there's 4861, because 4861 is the one defining the registry. Does
anybody feel strongly about this updating 6275?

Ben: As one of the people who brought it up, I wanted to make sure it wasn't an
oversight.

Suresh: Just put it into revised ID needed and i'll take care of it.

 o draft-ietf-6lo-rfc6775-update-17  - IETF stream
   Registration Extensions for 6LoWPAN Neighbor Discovery (Proposed
   Standard)
   Token: Suresh Krishnan

No discusses and no open positions, unless there are objections now.
Suresh: This one is also revised id needed, there's stuff that came in last
night and there's probably going to be something for Warren as well.

Amy: This one is approved, revised ID needed.

Suresh: one more thing, Ben, I sent this thing yesterday about the terminal X
requiring normative references, do you have thoughts on it? Ben: They are
normative references in the draft, at least at the time I looked at it. Suresh:
I don't think they should be, but if everyone else feels it I'll just say okay
and skip the last call. Ben: Since you called it out, my impression is that we
do not have a consensus about whether terminology drafts need to be normative
references. I've seen people argue both sides. Suresh: Are you happy if I move
it into normative reference and move on? Ben: If your belief is that it's not
necessary to read them to understand the document, Suresh: Thanks, I'll keep
you posted. I'll have another discussion with Adrian.

 o draft-ietf-ice-trickle-18  - IETF stream
   Trickle ICE: Incremental Provisioning of Candidates for the
   Interactive Connectivity Establishment (ICE) Protocol (Proposed
   Standard)
   Token: Ben Campbell

Amy: I have a Discuss in the tracker, do we need to discuss that today?
Ben: It's more of a process discuss due to the fact that it's caught up in the
structure issue with the other Trickle document. It seems to me that the
authors are being responsive to the other comments and we're working through
those, so unless someone else has something to discuss I don't think we do. And
yes, this is a revised ID needed. Peter is hovering over a submit button
waiting to hear from me.

 o draft-ietf-tls-iana-registry-updates-04  - IETF stream
   IANA Registry Updates for TLS and DTLS (Proposed Standard)
   Token: Benjamin Kaduk

Amy: I have no discusses in the tracker.
Benjamin: There is one question we could perhaps talk about. This document
exists to make changes to a bunch of registries and adds a recommended column,
that is to say there are some things we vetted and you should use, and we make
no opinion about the other ones. We have the ability to transition from yes we
recommend this to no we do not recommend this state, and it's currently listed
as IESG Approval. There was some question whether we want to just say that or
if we wanted to explicitly mention something involving IETF consensus or
standards track RFC or something like that. Do people think it's okay to leave
the IESG Approval, and have that also count toward the case where there is a
document describing why there are changes being made? Ben: [Correction from
Benjamin: Adam speaking] That sounds good to me and that's how I read it
originally. Benjamin: Okay, I'm happy to go with that. This should go into
approved, revised ID needed.

 o draft-ietf-tls-record-limit-02  - IETF stream
   Record Size Limit Extension for Transport Layer Security (TLS)
   (Proposed Standard)
   Token: Benjamin Kaduk

Amy: Unless there's an objection, it looks like this one is approved. Hearing
no objection, is this ready to go as is? Benjamin: It will need a revised ID.

 o draft-ietf-i2rs-rib-data-model-10  - IETF stream
   A YANG Data Model for Routing Information Base (RIB) (Proposed
   Standard)
   Token: Martin Vigoureux

Amy: I have a discuss in the tracker. Do we need to discuss that today?
Martin: No, I don't think so. The authors and the shepherds have replied that
this was effectively something that needed to be corrected in the document.
Suresh: I'll wait for the new text.

 o draft-ietf-l2sm-l2vpn-service-model-09  - IETF stream
   A YANG Data Model for L2VPN Service Delivery (Proposed Standard)
   Token: Ignas Bagdonas

Amy: I have a discuss in the tracker. Do we need to discuss that today?
Ignas: I don't think so. The authors are engaging and there is a way forward to
address the comments. Unless Alissa would think otherwise for her discuss.
Alissa: I could use just a little help understanding the purpose of this thing,
because I'm still not 100% clear on it. So the response the author sent said
something about changing from a cloud access identifier to cloud access, so
what is actually going to go in this field and why it expresses something
significant from the service provider to the customer or vice versa? Can you
explain that? Ignas: This is very deployment and very operator specific. We are
trying to define something which fits everyone. The authors have their own set
of use cases based on which they tried to generalize. The reason they use
specific terminology is based on their view. Other than that, it is generic
enough to provide a basic general level of service configuration. anything will
require augmentation via deployment specific models or revisions for this
model. Alissa: So it's not like there's some set of identifiers that are known
that the entity creating this model has a selection they will pick from.
They're going to have to negotiate anyway about what goes into this field,
right? Ignas: Generally yes, there;s no such thing as universal service
properties which are applicable to every operator. Alissa: Okay, I think that
helps. I will respond via email to the author. Ignas: Okay, let's see whether
their response is suitable and until then I suggest we hold the discussion.
This will definitely be a revised ID.

 o draft-ietf-i2rs-yang-dc-fabric-network-topology-08  - IETF stream
   A YANG Data Model for Fabric Topology in Data Center Networks
   (Proposed Standard)
   Token: Martin Vigoureux

Amy: Do we need to dicuss today?
Martin: It's up to Ignas. I'm not sure if it's worth it. We are currently having
discussion with the authors and the shepherd. There are a number of points to
resolve and address, and the base of them would say to clarify the scope and
applicability of the model. The discussion needs the involvement of the authors
and shepherd so we might be better off continuing on email. Ignas, do you
agree? Ignas: Yes, in general I agree with that. Regarding the comments, the
authors are engaging and that seems to be working. The general concern they
have is about the practical applicability of this document and that needs to be
clarified. What are the intentions of this document? Martin: There is an
implementation, a plan for deployment, I understand this model may not suit all
existing deployments, but since it is targeting at least one, they are trying
to look for one size fits all. I'm more inclined to, even if it's not perfect,
give a chance for this model to be deployed and used so we can acquire
feedback. Ignas: no disagreement with these intentions, just a comment:
implementation is radically different than what is in this model. That's my
main concern. Warren: I think this is the first time I ever balloted abstain,
and I did that because their definition of what a data center fabric is very
different than mine. That's quite similar to Ignas's point. Martin: I
understand that. I think we're struggling to find one universal definition of
what a data center fabric is. If that's the feeling you get, that it's
targeting universal definition, maybe there is a need to clarify. Warren: If it
says this is for a specific understanding or view, I would not be twitchy.
Martin: we need to continue the discussion with the authors and shepherd. I
think we need to hold the discuss for the moment and it will eventually require
some revision.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-ietf-trill-over-ip-16  - IETF stream
   TRILL (Transparent Interconnection of Lots of Links) Over IP
   Transport (Proposed Standard)
   Token: Martin Vigoureux

Martin: We met with Donald, Mirja, Alia at IETF in London and we established a
path forward. Donald is working on it. Mirja: Donald replied to my discuss
yesterday, it's ongoing. Martin: Alia had balloted on that one, I guess I need
to ballot as well? Amy: The document currently has no yes position, and it
needs a yes to move forward; usually that's the shepherding AD. It needs a yes
position from a current sitting AD; that would be you. Martin: I'll do that,
thank you.

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 o status-change-bier-core-to-proposed-standard-01  - IETF stream
   Promote BIER Architecture and Encapsulation to Proposed Standard
   (based on updating charter) (None)
   Token: Alvaro Retana

Sandy: Just wondering if you had a chance to review the email I sent yesterday.
Last time we handled something similarly, moving from informational to BCP, we
immediately received questions about the status of the document. Alissa: I
thought your proposal was fine. Warren: I replied to the email, I think it's a
better solution than the current thing which just causes confusion. I don't
know what the process for this would be. Does it need us at all or what?
Alexey: My understanding, we just approve the status change and the production
center does the right thing. Sandy: I don't think a new document needs to be
brought to the telechat but it would be helpful if there was a note on the
message that a new RFC should be published. Warren: Of course it will have an
auth48. Sandy: I had imagined skipping that because there aren't any content
changes, but I'm okay with an auth48. Warren: Who would need to approve an
auth48? Spencer: Seems to me it's worth having a conversation about the general
case. If we think this is the right way to do this, this is kind of not what we
told the community we'd do with status changes in the past. it'd be good for us
to decide if we're just doing this with this document, or all documents.
Alexey: I think most people outside of this group wouldn't care, unless they're
attached to a particular RFC number. Might be worth talking about at the
retreat though. Spencer: At the very least we could say we're not going to use
the procedure we've used in the past. I think that could even be the right
thing to do, I don't want to make anyone believe I don't think that. Not
confusing the community seems like a good thing to do. Sandy: The general case
could be a little more complicated, like if there were changes to the
boilerplate / copyright. Spencer: We could figure out what to do, we just can't
decide to do something different on every new document that comes through.
Sandy: Any pressing issue with getting these through, or do we want to hold
until that discussion takes place? If it helps, we could see what the diffs
would be. Spencer: we could decide this based on how many questions we think
the RFC Editor is going to get about the status. you've raised that as an issue
in the past, but there's been an answer to that. I don't know that anything
needs to be held up if there's a reason to do this now. Ekr: I don't think we
should hold this up, I see this primarily as a tools question. Spencer: what
we're talking about is the part where RFC text never changes but the way we
display it does. Warren: I had a document that went though a status change from
informational to standards track, and on the front page it still says
informational and on the datatracker it says standards track and people still
ask me about it. Ekr: If we want to have a broader effort to make sure RFCs are
more accurately labeled, thats different. Spencer: There's a number of choices,
making one would be awesome. Ekr: Let's advance this document now and discuss
later. Sandy: We're going to upgrade these two documents with a status change,
no new documents, and we can discuss this issue later. Spencer: If someone puts
a new version that says a status change on the top, I don't know why we
wouldn't proceed with that. Warren: I think it would be better if there were
two new documents published with new numbers that would obsolete the others. I
don't know who would do that but it seems less complicated to me. Sandy: I
could easily make those updates but since we're creating a new process, sort
of, i don't know what I'd do with those. Warren: in this case, the authors are
still around and could presumably submit new versions of the document, and we
could slap them on a telechat and nod at them. Or we can have this as an
informal topic and wait until then. Spencer: I'm visualizing the magic moment
when someone finds out they're an author on an RFC they've never heard of
because there's a new number. We've spent enough time on this for a telechat.
Warren: What exactly happens now? Amy: It's not that clear to us either. You
just outlined the old process for doing status changes, submitting a new
document and getting a new RFC name but changing none of the text. The new
process would be changing the status. We're a little confused as to what you
want us to do. Mirja: We can either do the old status change, or forget about
the status change and submit two new documents either way. It can be Alvaro who
decides. Amy: I guess we'll have to alert Alvaro to his choices here. Alissa:
Why don't we do that and move on. Amy: I'm going to keep this in IESG
evaluation and put it into AD followup. We'll have a conversation with Alvaro.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-teas-scheduled-resources-06  - IETF stream
   Framework for Scheduled Use of Resources (Informational)
   Token: Deborah Brungard

Amy: Unless there's an objection, this one is approved. Hearing no objection,
Deborah, are there any notes needed? Deborah: The authors are going to do a
revision, so do it as point raised.

 o draft-ietf-rmcat-sbd-11  - IETF stream
   Shared Bottleneck Detection for Coupled Congestion Control for RTP
   Media. (Experimental)
   Token: Mirja Kuehlewind

Amy: Unless there's an objection, this one is approved. Any further notes?
Mirja: This document is ready to go. The goal is to test it and move this
document to standards track.

 o draft-ietf-i2rs-rib-info-model-15  - IETF stream
   Routing Information Base Info Model (Informational)
   Token: Martin Vigoureux

Amy: Unless there's an objection, this one is approved.
Martin: The authors will issue a new revision based on comments. Beyond that,
we're good to go.

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-nir-cfrg-rfc7539bis-00
   IETF conflict review for draft-nir-cfrg-rfc7539bis
     draft-nir-cfrg-rfc7539bis-04
     ChaCha20 and Poly1305 for IETF Protocols (IRTF: Informational)
   Token: Benjamin Kaduk

Amy: This is ready to go back to the IRSG.
Michelle: There is an expert review we're waiting on.

 o conflict-review-mavrogiannopoulos-pkcs8-validated-parameters-00
   IETF conflict review for
   draft-mavrogiannopoulos-pkcs8-validated-parameters
     draft-mavrogiannopoulos-pkcs8-validated-parameters-02
     Storing validation parameters in PKCS#8 (ISE: Informational)
   Token: Eric Rescorla

Assigned to Ekr and removed from agenda to let him do conflict review

 o conflict-review-ribose-asciirfc-00
   IETF conflict review for draft-ribose-asciirfc
     draft-ribose-asciirfc-06
     AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc (ISE:
   Informational)
   Token: Spencer Dawkins

Amy: No discusses, hearing no objection, this is approved.
Spencer: Does the message that goes out say there are more comments in
datatracker? Amy: Typical text gives info on document, also separate comment
that there may be more comments in the datatracker to review.

 o conflict-review-irtf-nwcrg-network-coding-taxonomy-00
   IETF conflict review for draft-irtf-nwcrg-network-coding-taxonomy
     draft-irtf-nwcrg-network-coding-taxonomy-08
     Taxonomy of Coding Techniques for Efficient Network
   Communications (IRTF: Informational)
   Token: Alexey Melnikov

Amy: Hearing no objection, this will go out Monday and we'll move on.

3.4.2 Returning items

 NONE

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

 o IETF Administrative Support Activity 2 (iasa2)

Amy: No blocking comments.
Alissa: I need to make a small edit based on comments received before this goes
out. Is it possible for me to add some text to the mail that goes out with
this? Amy: I believe so. Cindy: We can edit it, but I'm not sure if you can. If
you tell us what you want to say we can make sure that happens. Alissa: Okay. I
just have a paragraph of context; I'll send that to the Secretariat.

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: I have three items.
1. IAB is identifying some new programs, I thought it would be interesting at
the retreat if they summarize the programs they're working on. 2. Yesterday
they released liaison back to study group 20, asked information about IPv6 and
IoT work items. There was interest from some of our WGs on it. It's on the
liaison tracker. 3. They had a presentation from ISOC on their IoT campaign I
thought was interesting. They're releasing a white paper on IoT security. I was
thinking it might be interesting to do a readout at one of our meetings on
their activities. We could get info on the type of programs they are doing.
Ekr: Could we get a copy of that document before it's published? Previous ISOC
documents have not been to my taste. Deborah: The IAB also asked if they could
review it and ISOC said it was already out the door. The IAB asked for
pre-review in the future. Ekr: Can our ISOC liaison speak to that? Alissa: This
is something we talked about before the changeover. Ekr: What was the outcome?
Alissa: In this case he forwarded the document to the IAB, right? Ted: No.
Alissa: He said he was going to send it but he didn't. Given that we have a new
liaison, that's something we can work on. Suresh: The stuff they are doing is
very high level. I think we should take a look at it but it should be fine.
Ekr: This one may or may not be fine. Some of their communications are not
fine. How do we ensure we see these things prior to being locked and loaded?
Suresh: I think Greg is probably the right person to get us in the loop.
Alissa: I don't think so; this is not Greg's job. This is the job of the
liaison we have to the IAB, so that's the channel we should use to work this.
I've seen stuff go out for comment with the org members, which is the trigger
to ask from the IAB, but it seems like those should happen simultaneously. Ted:
I'm not sure what the next steps are as a group. Two sets of issues, one is of
ISOC's autonomy, the other is our willingness to offer advice. We've made it
very clear as the IAB that we're willing to offer advice, but we can't require
them to have us review docs like this in the future. That's just not a role we
can play. Ekr: We can't formally require them, but ISOC's legitimacy in these
matters derives largely from their association with IETF, they should
coordinate with us. Ted: I'm not sure I agree with your analysis--perhaps you
and I should take that offline. Ekr: Happy to do so. Deborah: ISOC already
reached out from the fellows program and said they'd like to come talk to us
one meeting once a year and maybe we could ask them to also update us on other
programs they're doing.

6. Management issues

6.1 [IANA #1053888] Designated expert for
RFC-irtf-cfrg-xmss-hash-based-signatures (Amanda Baber/IANA)

Alexey: Can you add this as an action item for me? I'll come back to the IESG
with a proposal.

6.2 Network Configuration (netconf) Recharter

Amy: the IESG approved the revised charter for netconf on March 18 and sent the
announcement on March 20th.

6.3 IESG Liaisons and Assignments

Amy: These are the following assignments from IETF 101:
IAB Liaison: Deborah Brungard
Tools Liaison: Ekr
Nomcom Liaison: Adam Roach
EDU Liaison: Suresh Krishnan
IESG List admins: Terry Manderson, Suresh Krishnan
Comms review team: Mirja Kuehlewind, Alvaro Retana, Warren Kumari

6.4 Leadership Meeting with IEEE 802 in November (Alissa Cooper)

Alissa: We got a note from Russ inquiring about whether to have a half-day
meeting with the 802 leadership on the Saturday after the IETF meeting in
November. We need to get back to Russ about this. I think given how the
breakfasts have been working, my sense is that this makes sense for the parts
of our leadership for whom the IEEE 802 work is directly relevant. I wouldn't
want to say the entire IESG needs to attend this, which is different from how
we've done it in the past. I suggest we schedule this but we make this optional
for ADs, assuming those who have joint work will attend. Spencer: That sounds
exactly right to me. Historically, when we started talking to 802 again, we had
gotten in kind of a bad situation with them over things like TRILL. We had a
lot of IAB and IESG talent in the room reworking that relationship. But if
people know they need to be there, please be there, but you don't need to come
just because other people in the IESG or IAB are there. Alissa: Any objections
to that plan? Hearing none, I will respond to Russ. We can assume this will be
the first half of the Saturday after 103.

6.5 Expedited RFC Processing for draft-ietf-nvo3-hpvr2nve-cp-req (Martin
Vigoureux)

Martin: The text is pretty clear. The authors have pinged me because another
document is expecting to reference it. The document is in the RFC editor queue
in edit state so everything might work normally, but just in case, we were
wondering if we could get an RFC number earlier in the process. Warren: I can't
remember, what's the process for getting expedited stuff? Amy: You all agree
that you approve the expedited handling for an RFC number, and we send an
official note to the RFC Editor saying such, and they say okay. Warren: Can we
approve that all RFCs get expedited handling? Ekr: Then we'd need a process for
double expedited handling! Amy: Any objection from anybody for expedited
handling? Hearing none, Sandy, we'll be sending you an expedited handling
request for it.

6.6 [IANA #1055836] Designated expert for RFC 8225 (Sabrina Tanamal / IANA)

Amy: This has been discussed.

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

Alissa: I have one request. If you have agenda items for the retreat, please
add them to the retreat wiki in the topics section. Amy: I hope everyone is all
set for the retreat, please get in touch with us if you're still waiting for a
hotel confirmation. Thank you all.

0832 PDT Amy adjourned meeting.