Narrative Minutes interim-2023-iesg-23 2023-10-19 14:00
narrative-minutes-interim-2023-iesg-23-202310191400-00

DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-10-19 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------

Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jay Daley / IETF Executive Director
Dhruv Dhody (Huawei) / IAB Liaison
Lars Eggert (NetApp) / IETF Chair, General Area

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

Roman: Can we add an item to talk about my AI to add text to the Datatracker?
Thanks.

1.3 Approval of the minutes of past telechats

Liz: Are there any objections to approving the minutes from the October 5? I'm
hearing no objection, so those are approved and we'll get those posted in the
archive. Does anyone have an objection to the narrative minutes from October 5
being approved? I'm hearing no objection, so we'll get those posted as well.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Rob Wilton to find designated experts for RFC 9445 (RADIUS
       Extensions for DHCP-Configured Services) [IANA #1279159]

Rob: Genuinely in progress.

     o Roman Danyliw to find designated experts for draft-yee-ssh-iana-
       requirements-03 (Key Exchange Method Names) [IANA #1281831].
     o Roman Danyliw to find designated experts for RFC 9447, ACME
       Authority Token Challenge Types" [IANA #1281679].

Roman: I thought I did the ACME one. Maybe I'll find it and get it on the
agenda before the end.

   * OPEN ACTION ITEMS

     o Warren Kumari to follow up on a bis document for RFC 8126 regarding
       designated experts.

Warren: In progress.

     o Roman Danyliw to open a Datatracker issue suggesting a feature to
       better signal individual contributions.

Roman: That's what I wanted to discuss at the end.

     o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John
       Scudder, and Jim Guichard to draft text regarding document
       authorship/editorship with regards to the number of authors listed.

John: I think Andrew is the last person who did something on this. It's in
progress.

     o Lars Eggert to facilitate a community discussion on priorities for
       IESG processes.

In progress.

     o Lars Eggert and Warren Kumari to 1) draft a revision of RFC 4858,
       2) draft a revised IESG Statement on Document Shepherds (original
       statement October 2010), and 3) update the WG Chairs wiki to point
       to the new IESG Statement.

Warren: In progress.

     o Warren Kumari to follow up with the tools team regarding removing
       the requirement of needing an author email for deceased authors.

Warren: That's really in progress. I opened a new ticket and [the tools team]
linked it to an existing one.

Liz: Since the action item was to follow up with the tools team and they now
have it, can we mark this as done?

Warren: Yeah, I guess this is done.

     o Erik Kline to follow up with authors of draft-ietf-6man-rfc6874bis
       to schedule a conversation about the document.

Erik K: In progress. There are ongoing email threads.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-sedate-datetime-extended-10  - IETF stream
   Date and Time on the Internet: Timestamps with additional
   information (Proposed Standard)
   Token: Francesca Palombini

Liz: There is a Discuss in the tracker from Lars who isn't here; do we need to
discuss this now?

Francesca: No, I don't think so. Lars mentioned off-list that the resolution
the authors proposed was fine. There will be a revised I-D needed. Thanks
everyone for the review.

Liz: We'll leave this in IESG Evaluation with Revised I-D Needed.

 o draft-ietf-cellar-flac-12  - IETF stream
   Free Lossless Audio Codec (Proposed Standard)
   Token: Murray Kucherawy

Liz: We have a Discuss here; do we need to discuss this today? [Murray is not
on the call]

Roman: I had the Discuss here and I don't think we need to talk about it; I'm
in contact with the authors and we'll work through the issues.

Liz: Do you think this will require a revised I-D?

Roman: I think so but I don't want to speak for Murray so I'd just put it in AD
Followup.

Liz: Great, so we'll keep this in IESG Evaluation with AD Followup for Murray.

 o draft-ietf-intarea-rfc7042bis-10  - IETF stream
   IANA Considerations and IETF Protocol and Documentation Usage for
   IEEE 802 Parameters (Best Current Practice)
   Token: Éric Vyncke

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

Eric V: AD Followup, please. Maybe we want to discuss IESG ratification now or
later?

Francesca: As you prefer, as long as Sabrina or someone from IANA can be there.

Eric V: Sabrina is here, I saw her name. The point is that when I read it I had
the same question mark as you, Francesca and others. Don replied to me that it
has been done previously. Also I think it's the same name in IEEE, they are
using 'ratification' as well. As you have read, it's a two step procedure.
Designated expert followed by IESG approval in all cases, while IESG approval
is normally the exception. I don't mind either way.

Francesca: While I was reviewing 8126, I noticed that policies can be used in
combination and fifteen years ago that wasn't in the IANA guidelines. Why not
just use the things we have defined, a combination of IESG approval with expert
review, and I believe that does exactly what the authors want. They can leave
the text and all the instructions to IANA as they have done now, we just don't
introduce this term "IESG ratification". I understand  it's not "introduced"
now in the sense that it's been there for a long time, but we have the
possibility to use terms that are well defined somewhere else in the IETF, so
why not just do that.

Warren: I balloted DISCUSS largely on the same [idea of] why are we inventing
something new. As Don pointed out, we already have this, it's been like that
for a long time and hasn't caused any sadness yet.

Francesca: We've had that before but now we have something that allows us to do
exactly the same thing using policies that already exist. Expert review and
IESG approval. You can combine these and give more instructions. My comment is
really not to change much, just change ratification to approval plus expert
review.

Eric V: Maybe simpler to say that in this document, IESG ratification means a
combination of expert review and IESG approval? We can mainly leave the text as
it is.

Francesca: Of course. If you want to use the ratification term because that's
the same term they use in IEEE, I'm fine with that. It's not a strong comment,
just that we have these nice tools, why not use them. Sabrina can tell me if
I'm getting this wrong. I'm bringing it up because recently I've had another
document which used a combination of policies and I was surprised it was even
possible. Indeed, it is defined.

Eric V: Sabrina, what's your point of view?

Sabrina: I don't really have anything new to add. This was something we pointed
out to Donald when we reviewed the document during early review. He basically
pointed out that it was in the previous RFC so we didn't really argue iwth him.
As far as your suggestion, Éric, in still using the term and defining it as
IESG approval, we're okay with that.

Eric V: I will check with Donald and see if he has a strong objection. I think
Francesca's suggestion of defining it that way will be okay.

Warren: He did say to me they're not quite the same thing.

Francesca: It's not the same thing. We're not suggesting to change "IESG
ratification" to "IESG approval."

Warren: That's not what I was suggesting, but let's move on.

Eric V: Thank you everyone for reading this. Let's say Approved, AD Followup
and I will check all the comments. Thank you all.

 o draft-ietf-grow-bmp-registries-change-04  - IETF stream
   Revision to Registration Procedures for Multiple BMP Registries
   (Proposed Standard)
   Token: Warren Kumari

Liz: There are no Discusses in the tracker, so unless there's an objection now,
it looks like this one is approved. Warren, is this ready to go as-is?

Warren: Yes.

Liz: Great, then we will send this protocol action announcement.

2.1.2 Returning items

 o draft-ietf-calext-jscontact-15  - IETF stream
   JSContact: A JSON representation of contact data (Proposed Standard)
   Token: Roman Danyliw

Liz: There are no Discusses in the tracker, so unless there's an objection now,
it looks like this one is approved. Okay, this is approved. Roman, do you want
to put this in AD Followup and do any final checks or is this ready?

Roman: First of all I want to say thank you to everyone who re-reviewed this
document. Can we please approve it but put it in AD Followup? I'd like to take
a look at the link to SEDATE based on Lars's comment. Thank you.

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-irtf-icnrg-ccnx-timetlv-00
   IETF conflict review for draft-irtf-icnrg-ccnx-timetlv
     draft-irtf-icnrg-ccnx-timetlv-05
     Alternative Delta Time Encoding for CCNx Using Compact
   Floating-Point Arithmetic (IRTF: Experimental)
   Token: Roman Danyliw

Liz: There are no Discusses, so unless anyone has an objection now this
conflict review response is ready to go back to the IRTF. This is approved; is
this ready to go as-is?

Roman: I think it's ready to go.

Liz: Great, we will send that back to the IRTF.

 o conflict-review-makarenko-gost2012-dnssec-00
   IETF conflict review for draft-makarenko-gost2012-dnssec
     draft-makarenko-gost2012-dnssec-03
     Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG
   Resource Records for DNSSEC (ISE: Informational)
   Token: Paul Wouters

Liz: There are no Discusses, so unless anyone has an objection now this
conflict review response is ready to go back to the ISE. I'm hearing no
objection. Paul, is this ready to go?

Paul: It's ready to go.

Liz: Great, then we will send this no-problem message.

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 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

Roman: The two things I'd mention are that there was a great tech talk from the
Thread Group yesterday. The tech talks are extremely useful and you should join
them; I'll try to do a better job of surfacing them when they're interesting.
The other thing is that the IAB released a statement related to attestation and
the RATS WG had strong feedback. At the IETF 118 meeting some of the folks from
RATS are going to come and talk with the IAB.

6. Management issues

6.1 [IANA #1283141] RFC 2004 and IANA protocol number entry (Erik Kline)

Erik K: I don't think I have any update on this.

Liz: I think we just need IESG approval for listing this RFC as a reference.

Sabrina: In my message to Erik I forgot to note that the requestor is asking us
to not only list RC 2004 as the reference, tey're also asking us to update two
other fields in that registry. The registration procedure for this registry is
IESG approval or standards action, and this person also copied the person who
this registration belongs to. I didn't hear anything from that person yet so I
just sent this message to Erik asking what we should do here.

Erik K: I think I do remember looking at this and it looked okay to me.

Sabrina: So in addition to listing the RFC it's okay for us to go ahead and
update the keyword and protocol fields?

Erik K: I believe so, thank you.

Liz: Any objection to giving approval for doing those two things? I'm hearing
no objection. Sabrina, we can send you an official note; can you let us know
exactly what that should say?

Sabrina: Yes, thank you.

6.2 [IANA #1281698] renewing early allocation for
draft-ietf-mpls-egress-tlv-for-nil-fec (IANA)

Liz: Andrew is the AD for this document and he's not here. Can we go ahead and
approve this without him or do we want to wait and hear from him?

Eric V: It's only two years old. The document itself has been updated in June
this year so I don't see why we wouldn't.

John: I agree, it seems an easy shoo-in.

Liz: Great, then we can go ahead and renew this and we'll get that official
note to IANA.

6.3 Telechat dates between 118 and 119

Liz: This one is mine; we have two options for a telechat schedule between
IETFs 118 and 119. It's basically dependent on when you want to come back and
have a formal in January. Option 1 has a formal on January 4 and Option 2 has
an informal that week.

Eric V: We can set a 200 page maximum for the January 4 formal in option 1.

Rob: Can we also put another formal on March 7?

Liz: Definitely. Any objections? Okay, we're decided on Option 1 with a 200
page limit for January 4 and a back to back formal on March 7. Thanks everyone.

6.4 Telechat Agenda Wiki Update (Francesca Palombini)

Francesca: This document is just copy pasted from the wiki and I added some
comments. I'm bringing this up because I have been adding some documents to the
agenda that were not done with IETF Last Call at the moment I added them to the
agenda. I asked if anyone had any objection to it and Éric didn't like it so I
removed the documents that were not done. There's a telechat next week so it's
not that big of a problem, but I thought it would be a good time to go through
this text and agree as the full IESG to what is the correct process. I thought
I was following the right process by referring to this wiki, but if the process
has changed we should write that down. The first thing I highlighted is this
sentence that documents should be added no later than 5 pm the Thursday one
week before the telechat, and I think everybody is aware of that. Usually the
secretariat adds the documents and there's no objection there. Then if you go
down to the bullet list to get a document on an agenda, there is text about
where and when. According to this you can issue a ballot while a document is
still in Last Call. This is the major point where there was disagreement. Then
it also says that a document can be on the agenda a few days before Last Call
ends and that the Last Call should end no later than the Monday after the
telechat. That was surprising to me and I've never seen that happen.

Francesca: To summarize, according to the wiki we can and should put documents
on the agenda before the Last Call is over as long as we put them on the agenda
one week before, independently of the Last Call state. And ADs are supposed to
hold a document if Last Call comments arrive that aren't addressed, and I think
we do that.

Eric V: To be clear, my objection was that I try to spread the workload of
reviewing drafts on the two weeks. That's one thing, if I have only one week to
review everything, there's no point in reviewing something that may change due
to Last Call. That's selfish. The other one, I want to make the directorate
very involved in the reviewing and I can't really ask them to review something
for a telechat that's in Last Call. I can't ask them on Friday to review
something for Wednesday. Those are basically my two points. The selfish one, I
can deal with it, but the more important one is the directorates.

Warren: I don't think this was ever intended to be something that would happen
without an unusual circumstance.

Francesca: That's fine, but if that's what we mean, we should change the wiki.

Cindy: I think a lot of the content on this page is just very old. IESGs change
over time; back in the day ADs used to put all their own documents on the
telechat agendas and now the Secretariat can do it. This also may provide an
answer to something I've wondered about for 15 years, which is that when
something gets approved on a telechat we don't send the announcement until the
Monday after. I never quite understood why there was that delay but if once
upon a time the Last Call didn't have to end until then, that might explain it.
Once upon a time there also wasn't a Datatracker so balloting was a lot harder
to track.

Zahed: Francesca, I think we can all agree that this needs to be updated.

Francesca: I'm happy to take the action item to start updating but I want to
have agreement from everybody. If you're okay with it I can start.

Rob: My suggestion would be to document the common case of what normally
happens and then there may be exceptions. I'm not sure documenting every
possible exception is useful.

Warren: I'm still not sure what problem we're trying to solve here.

Francesca: The problem is I thought I was following process but that raised
concerns. I'd like to adjust the process which is outdated and make sure we all
agree on the new process. For example, if everybody agreed that having a
document on the first telechat after Last Call ends, we could change it to
that. I understand that's not the case though. I just wanted to talk about it
before making any changes.

Rob: I'm not sure this is what's really causing the delay so I wonder whether
optimizing for this is going to make much difference. We should handle the
exceptions as exceptions.

Francesca: I'll try to reformulate this as the current way we work. Any
objections? Okay.

Paul: Can you add some text that the announcement can be sent immediately
unless the Last Call is still in progress?

Cindy: If you don't want us to wait, we're happy to send those as soon as they
are approved and ready to go.

Warren: Not infrequently there's a revised I-D needed that's just a small
update done in a few days. I don't know if people think it's better for the
community to get all of the approvals happening in one go or if it doesn't
really matter. I don't know what's easiest for the Secretariat.

Cindy: I don't think it makes a difference to our workflow if they're batched
or not.

Francesca: I'll take an action item to modify this text and send it to the IESG
list so we can all agree on it. Thank you.

6.5 Approve Important Dates for IETF 120, 121

Liz: These are fairly standard important dates. Any objections to approving
these? Okay, we'll get these put into the Datatracker.

6.6 draft-ietf-core-sid (Francesca Palombini)

Francesca: Rob, I think you can probably lead this since it's your Discuss.

Rob: This was a document we reviewed in the IESG about six months ago or
longer, I had a Discuss on it, and it went back to the WG to be reworked which
took a while. I reviewed it in the WG before Last Call and said it should be
fine. Effectively there's some process stuff in here about managing SID files
for RFCs containing Yang modules. It's a mapping from Yang to some numerical
data file. These files are effectively managed and once they're published those
numbers don't change. What the document is currently suggesting is that the
authors maintain a SID file in the Internet-Draft through processing and then
it gets taken out of the draft before it becomes an RFC and gets stored in IANA
somewhere. My concern is I'm worried about the overhead of managing these SID
files being laborious for the authors and I'm also concerned about the fact
that these SID files won't be updated and they'll go out of date during draft
processing and not be that useful with stale information. The Discuss I raised
was a question of whether it's better not to do that. Instead maybe ask IANA or
the RFC Editor to generate these SID files if they're not there and check with
the authors or an expert reviewer that they're correct before publication. Any
thoughts?

Sabrina: I think we have already looked at the second Last Call and we have
wosme questions for the authors there. As far as maintaining the SID files, I
don't think we have any issues with that. I'll have to talk with the team as
far as tooling. We are currently generating the Yang modules using the RFC
strip tool that we do at the very end once the RFC number has been announced.
That's the current process.

Rob: So you could add an extra step which is not just to take out the Yang file
but also to generate a new SID file or check the one that's there with an
expert reviewer? Would that be reasonable from your side?

Sabrina: I think that should be fine.

Rob: Okay, great. I will suggest that to the authors.

Eric V: Then you need to get one SID file per revision, right? Becasue numbers
can change.

Rob: With a SID file now you're allowed to have a prereleased version to mark
as unstable, and then when the RFC becomes published you chagne it to a stable
SID file.

Eric V: But it means it's work to be done by IANA, not only at publication, but
at every revision?

Rob: No. I'm saying either if a WG wants to manage a SID file while the I-D
progresses, that's up to them to manage. At the point you publish it, then IANA
would be involved during the RFC processing stage and would make that
allocation final. The ones that authors wont' bother, it's not particularly
targeting that part of the network, you'd just have no SID file at all until
effectively the RFC is being published and then it gets generated.

Eric V: So the SID file in IANA would get holes in the numbers, right, non
consecutive numbers used by previous revisions? And then you're putting a
burden on authors because if they want a revised I-D and a SID file because
they're changings semantics, they need to publish a SID file somehow linked to
the draft. It was easier for them to put the SID file into the draft.

Rob: If the authors want to put a SID file in the draft, I don't have a problem
with them putting it in. It's more about [not] forcing them to put it in there.

Eric V: Okay, thank you.

Sandy: You said some RFCs will have a SID file and some won't?

Rob: Some drafts will have a SID file and some won't. The idea is that going
forward all RFCs that contain Yang files the IETF publishes will have
corresponding SID file generated for them. There's also a step in the draft
going back and generating SID files for existing Yang models published by the
IETF.

Sandy: So they don't appear in the RFC, it's just a step that happens as
publication happens?

Rob: Correct. I don't think we want them in the RFC. I don't really want Yang
files in RFCs. We do better here by not putting them there in the first place.
Any other comments today? If not, I'll follow up with the authors based on this
discussion.

Francesca: Sounds good, Rob.

6.7 Signaling Individual Contributions in the Datatracker (Roman Danyliw)

        Slide 1: Reducing Confusion on Standing of Drafts
        Follow-up to IESG Retreat 2023

        Slide 2: Numerous Areas of Confusion with Drafts
        - Existence of document streams
        - Next steps for a document
        - Submitted drafts vs. adopted drafts
        - In IETF stream
                - Tracks: Informational vs. Standards vs. Experimental vs. BCP
                - Standards tracks: PS vs. IS
                - Submitted I-D vs. adopted document

Roman: The background here is that at the retreat I brought up that there is
confusion with drafts about streams and status. What we ended up with is a
specific place we found consensus to signal whether a document has been adopted
or not and provide some caveats associated with it. AT the time there was not
any concrete text to propose about how we would signal that; that's what this
next slide is all about.

        Slide 3: Proposal: New banner text in the Datatracker

Roman: The proposal is that on every document that's not adopted there would be
this banner text signaling this is in the system, anyone can put an I-D in the
system, and it has no standing. The discussion I wanted to have was to get
consensus on the text itself.

        Slide 4: Proposed Banner Text
        "This document is an Internet-Draft (I-D) not an RFC. Anyone may submit
        an I-D, no prior
permission or membership is required. This I-D has not been adopted and is
therefore not an official working document of, or otherwise endorsed by, the
IETF (or any related organization)."

Roman: Éric, you sent two pieces of feedback on whether this should say "yet"
and the duplication of "or otherwise endorsed by."

Eric V: Correct. As you know, English is not my native language, so I will
leave it to you. To me it looks like it is not adopted, forever. That's how i
read it.

Roman: Got it. For 'otherwise endorsed by,' I volley back that there's not a
lot of understanding of the process. There's nuance here in saying something is
not an official WG document, it may not be clear that that's what confers a
little bit of endorsement and I feel like it should be explicitly stated so you
don't have to understand the IETF process.

Eric V: We are just bikeshedding here. I'm perfectly fine with a sentence.

Zahed: I was thinking if we can use this well known term 'individual I-D.' The
problem there is that an individual draft doesnt have a definition. Maybe it's
an internal draft, not an RFC. Individual internal draft?

Roman: You mean to add that this is an individual Internet-Draft?

Paul: That would be good, I think.

Roman: I see no issue with that. Does anyone object? Okay, i'll add that in.

Paul: I have another question. Would it make sense to have two different
banners, one for documents that have not expired and one for documents that
have expired? A document that expired ten years ago is probably different from
one submitted last week that is likely to get adopted.

Mirja: I thought the expired ones don't show up in the Datatracker, it's just a
block that it's expired and here's a text for you to read.

Warren: I think Mirja's right, an expired document there's just a box around
it. I don't really know if it's useful for us to add the 'or any related
organization.' I think we're mainly just speaking for the IETF and we should
drop it. Keeping it short and sweet is helpful.

Eric V: People do not know at this stage if it's IAB or ISE or whatever.

Roman: Channeling Greg, when the -00 comes in, it's unclear what stream this is
going to.

Warren: What's a related organization? IEEE?

Roman: I think that was meant to capture the IRTF and maybe other streams.
Remember when I tried to open with defining only some streams as IETF and we
didn't want to unpack that? Can you live with this?

Warren: Oh yeah.

Mirja: From the IAB side I don't care if it says related organizations. The
important thing is that it's not endorsed by the IETF.

Paul: I put a link in the slack to an expired draft. There's a banner at the
bottom of the page but the first page looks like it's just a regular document.

Rob: I think any version of this text that's tweaked to expired drafts to make
it more clear is fine with me. But you'd have to do it differently for expired
adopted documents vs. expired non adopted drafts.

Warren: We're trying to keep this short, I think. Maybe we can just remove the
"this has not been adopted and is therefore" and just say it's not official.
Just trying to keep it simple.

Paul: I like that idea.

        Slide 5: Revised proposed banner text
        Currently, this document is an individual Internet-Draft (I-D) not an
        RFC. Anyone may submit an
         I-D, no prior permission or membership is required. This I-D is not an
         official document of, or otherwise endorsed by, the IETF (or any
         related organization).

Rob: I like the idea of adding "currently." This reads a bit negative, like
it's something that shouldn't be here and you should ignore it. If you put in
'currently' it softens it.

Warren: We could put "Currently" at the beginning.

John: Can we remove "working" in "working document"?

Roman: If we were just talking about the IETF stream, I'd say 'this I-D does
not have official standing in the standards process' but that won't cover the
other streams.

Mirja: For me that would be fine because this issue is less urgent for the
other streams.

Martin: Isn't it still accurate for the other streams because there's no
official standing in the standards process?

Mirja: There is no standards process in the other streams.

Martin: I think that's a feature, not a bug. Ideally every non-IETF stream
document, even if it was adopted, would say it has no official standing in the
standards process because it doesn't. I think it's fine.

Zahed: To me, the first sentence says it all. I don't need the last sentence
about official document, endorsement.

        Updated slide: Currently, this document is an individual Internet-Draft
        (I-D) not an RFC. Anyone
may submit an I-D, no prior permission or membership is required.

Alt 1: This I-D is not an official document of, or otherwise endorsed by, the
IETF (or any related organization).

Alt 2: This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.

Roman: I don't know that we can not do either alt, because we can't rely on
people knowing what an I-D is versus an RFC. I think that's too much inside
baseball.

Martin: I think the first paragraph plus alt 2 is completely correct. We can
argue about the phrase 'official document' but I think it's accurate and
reduces confusion for people who aren't familiar with the IETF process. Strong
plus plus.

[crosstalk]

        Updated slide: Currently, this document is an Internet-Draft (I-D) not
        an RFC. Anyone
may submit an I-D, no prior permission or membership is required. This
individual I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process. [RFC2026].

Warren: Maybe we should link to the Tao at the end.

Francesca: What about linking to RFC2026?

Roman: Thank you for the feedback on that. I'll double check this with Greg and
run this by Lars.

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