Subject: [tsvwg] Ben Campbell's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS)

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 09:45:41 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-le-phb-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this effort. The draft appears to be in good shape overall; I just
have one process point I would like to DISCUSS before approval:

Section 12 appears to be an update to draft-ietf-tsvwg-rtcweb-qos, which is
currently in the RFC Editor queue in the MISSREF state. It's not clear to me
what the intent of this section is, but if the idea is to formally update a
_draft_, then please do not do that. The right way to proceed would be to pull
draft-ietf-tsvwg-rtcweb-qos from the RFC editor queue and make the changes
there.

The UPDATES relationship is intended for updating RFCs, which are otherwise
immutable. Drafts, even post-IESG approval and in the RFC editor queue can
still be changed. Making readers figure out the update between two different
RFCs when there is an option to just fix the draft would be a disservice to
readers.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 20 Feb 2019 12:18:42 -0600

Dear TSVWG Chairs,

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/

That would be fine with me. Is it fine with TSVWG?

All - please note that resolving this question Really Quick would be
awesome, because there is only one more telechat after the one tomorrow,
and as of Wednesday of IETF 104, the ballots for draft-ietf-tsvwg-le-phb
from outgoing ADs "go away", including my Yes ballot ...

Spencer, who is wondering how many of the incoming ADs are familiar with
cluster C238 in the RFC Editor queue ...

---

From: "Black, David" <[email-masked]>
Date: Wed, 20 Feb 2019 18:56:42 +0000

>That would be fine with me. Is it fine with TSVWG?

I believe that TSVWG cares much more about the result than the means via which it is achieved.  It was important to include Section 12 in the le-phb draft in order to obtain WG consensus on the changes contained therein.

That said, I think I see a problem with Ben’s brief summary – a literal reading suggests a request to the RFC Editor to modify a draft in the RFC editor queue (rtcweb-qos) based on another draft (le-phb) that the IESG has not (yet) approved, something that the RFC Editor ought to decline to do.  That said, I suspect that this literal reading is not exactly what Ben had in mind, let me suggest a couple of alternate steps that are more likely to work:

  1.  The IESG instructs the RFC Editor not to publish the rtcweb-qos draft (or otherwise ensures that outcome) until IESG consideration of the le-phb draft is concluded.  No overt IESG action may be needed due to the current state of cluster C238 at the RFC Editor ;-).
  2.  The IESG approval of the le-phb includes an RFC Editor Note telling the RFC Editor to treat Section 12 of the le-phb draft as instructions to the RFC Editor about the rtcweb-qos draft, and requesting the RFC editor to make those text changes to the rtcweb-qos draft, add a normative reference to the le-phb draft (which is required by the text changes to be made) and then remove Section 12 of the le-phb draft prior to its RFC publication.

This also avoids having to submit a revision of the le-phb draft in short order, as the desired outcome is obtained primarily via the RFC Editor Note portion of the IESG’s protocol action announcement.

Will this course of action work for the IESG?

Thanks, --David

From: Spencer Dawkins at IETF <[email-masked]>
Sent: Wednesday, February 20, 2019 1:19 PM
To: Ben Campbell
Cc: The IESG; [email-masked]; Black, David; tsvwg-chairs; [email-masked]
Subject: Re: Ben Campbell's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS)

[EXTERNAL EMAIL]
Dear TSVWG Chairs,

On Wed, Feb 20, 2019 at 11:45 AM Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-le-phb-09: Discuss

All - please note that resolving this question Really Quick would be awesome, because there is only one more telechat after the one tomorrow, and as of Wednesday of IETF 104, the ballots for draft-ietf-tsvwg-le-phb from outgoing ADs "go away", including my Yes ballot ...

Spencer, who is wondering how many of the incoming ADs are familiar with cluster C238 in the RFC Editor queue ...

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 13:11:24 -0600

> On Feb 20, 2019, at 12:56 PM, Black, David <[email-masked]> wrote:
> 
> That said, I think I see a problem with Ben’s brief summary – a literal reading suggests a request to the RFC Editor to modify a draft in the RFC editor queue (rtcweb-qos) based on another draft (le-phb) that the IESG has not (yet) approved, something that the RFC Editor ought to decline to do.

Oh, no, I didn’t mean that at all. I suspect the implied subject in my sentence starting with “The right way…” was unclear. :-)

>  That said, I suspect that this literal reading is not exactly what Ben had in mind, let me suggest a couple of alternate steps that are more likely to work:

> 
> 	• The IESG instructs the RFC Editor not to publish the rtcweb-qos draft (or otherwise ensures that outcome) until IESG consideration of the le-phb draft is concluded.  No overt IESG action may be needed due to the current state of cluster C238 at the RFC Editor ;-).
> 	• The IESG approval of the le-phb includes an RFC Editor Note telling the RFC Editor to treat Section 12 of the le-phb draft as instructions to the RFC Editor about the rtcweb-qos draft, and requesting the RFC editor to make those text changes to the rtcweb-qos draft, add a normative reference to the le-phb draft (which is required by the text changes to be made) and then remove Section 12 of the le-phb draft prior to its RFC publication.

I’m mostly okay with any approach Spencer wants to take. But I  was thinking more along the former lines. While an RFC editor note would be a perfectly fine way to execute the changes to rtcweb-qos, I think it would need to be a note attached to that draft, not this one. (Using a note to delete section 12 from this draft would be fine.)

---

From: "Black, David" <[email-masked]>
Date: Wed, 20 Feb 2019 19:37:04 +0000

> I’m mostly okay with any approach Spencer wants to take. But I  was thinking
> more along the former lines. While an RFC editor note would be a perfectly
> fine way to execute the changes to rtcweb-qos, I think it would need to be a
> note attached to that draft, not this one. (Using a note to delete section 12
> from this draft would be fine.)

Ok, two notes to the RFC Editor work for me (one note to revise the rtcweb-qos draft, plus a second note to delete section 12 from the le-phb draft after the rtcweb-qos draft is revised).

What would not work for me would be to pull the rtcweb-qos draft back into TSVWG and have the WG make the changes.   Section 12 of the le-phb draft has sufficient information for the RFC Editor to do what needs to be done to the rtcweb-qos draft, and that section of the le-phb draft has WG consensus.

Thanks, --David

> -----Original Message-----
> From: Ben Campbell <[email-masked]>
> Sent: Wednesday, February 20, 2019 2:11 PM
> To: Black, David
> Cc: Spencer Dawkins at IETF; The IESG; [email-masked]; tsvwg-chairs; draft-
> [email-masked]
> > I believe that TSVWG cares much more about the result than the means via
> which it is achieved.  It was important to include Section 12 in the le-phb draft
> in order to obtain WG consensus on the changes contained therein.
> >
> > That said, I think I see a problem with Ben’s brief summary – a literal
> reading suggests a request to the RFC Editor to modify a draft in the RFC
> editor queue (rtcweb-qos) based on another draft (le-phb) that the IESG has
> not (yet) approved, something that the RFC Editor ought to decline to do.
> 
> Oh, no, I didn’t mean that at all. I suspect the implied subject in my sentence
> starting with “The right way…” was unclear. :-)
> 
> >  That said, I suspect that this literal reading is not exactly what Ben had in
> mind, let me suggest a couple of alternate steps that are more likely to work:
> 
> >
> > 	• The IESG instructs the RFC Editor not to publish the rtcweb-qos
> draft (or otherwise ensures that outcome) until IESG consideration of the le-
> phb draft is concluded.  No overt IESG action may be needed due to the
> current state of cluster C238 at the RFC Editor ;-).
> > 	• The IESG approval of the le-phb includes an RFC Editor Note telling
> the RFC Editor to treat Section 12 of the le-phb draft as instructions to the
> RFC Editor about the rtcweb-qos draft, and requesting the RFC editor to
> make those text changes to the rtcweb-qos draft, add a normative reference
> to the le-phb draft (which is required by the text changes to be made) and
> then remove Section 12 of the le-phb draft prior to its RFC publication.
> 
> I’m mostly okay with any approach Spencer wants to take. But I  was thinking
> more along the former lines. While an RFC editor note would be a perfectly
> fine way to execute the changes to rtcweb-qos, I think it would need to be a
> note attached to that draft, not this one. (Using a note to delete section 12
> from this draft would be fine.)
> 
> >
> > This also avoids having to submit a revision of the le-phb draft in short
> order, as the desired outcome is obtained primarily via the RFC Editor Note
> portion of the IESG’s protocol action announcement.
> >
> and as of Wednesday of IETF 104, the ballots for draft-ietf-tsvwg-le-phb from
> outgoing ADs "go away", including my Yes ballot ...
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Feb 2019 08:54:32 +1300

> What would not work for me would be to pull the rtcweb-qos draft back into TSVWG and have the WG make the changes.   Section 12 of the le-phb draft has sufficient information for the RFC Editor to…

+1. This is a clerical problem, there was clear WG consensus.

Regards
   Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 20 Feb 2019 14:42:44 -0600

Dear All,

On Wed, Feb 20, 2019 at 1:12 PM Ben Campbell <[email-masked]> wrote:

> which it is achieved.  It was important to include Section 12 in the le-phb
> draft in order to obtain WG consensus on the changes contained therein.
> >
> Oh, no, I didn’t mean that at all. I suspect the implied subject in my
> sentence starting with “The right way…” was unclear. :-)
>
> >  That said, I suspect that this literal reading is not exactly what Ben
> had in mind, let me suggest a couple of alternate steps that are more
> likely to work:
>
> >
> draft (or otherwise ensures that outcome) until IESG consideration of the
> le-phb draft is concluded.  No overt IESG action may be needed due to the
> >       • The IESG approval of the le-phb includes an RFC Editor Note
> telling the RFC Editor to treat Section 12 of the le-phb draft as
> instructions to the RFC Editor about the rtcweb-qos draft, and requesting
> the RFC editor to make those text changes to the rtcweb-qos draft, add a
> normative reference to the le-phb draft (which is required by the text
> changes to be made) and then remove Section 12 of the le-phb draft prior to
> its RFC publication.
>
> I’m mostly okay with any approach Spencer wants to take. But I  was
> thinking more along the former lines. While an RFC editor note would be a
> perfectly fine way to execute the changes to rtcweb-qos, I think it would
> need to be a note attached to that draft, not this one. (Using a note to
> delete section 12 from this draft would be fine.)
>

I'm almost positive that asking the RFC Editor what they want to see, is
the shortest way out of this cul-de-sac :-)

Let me drop them a note now.

Spencer

> > This also avoids having to submit a revision of the le-phb draft in
> short order, as the desired outcome is obtained primarily via the RFC
> Editor Note portion of the IESG’s protocol action announcement.
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 20 Feb 2019 18:40:28 -0600

Dear All,

On Wed, Feb 20, 2019 at 2:42 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> > I believe that TSVWG cares much more about the result than the means
>> via which it is achieved.  It was important to include Section 12 in the
>> le-phb draft in order to obtain WG consensus on the changes contained
>> therein.
>> >

After consulting with Heather and with Sandy, I have added this RFC Editor
note:

RFC Editor Note

   Because this draft formally updates draft-ietf-tsvwg-rtcweb-qos,
   which is approved but waiting in the MISSREF state, we ask the RFC
Editor
   to take the following actions:

   Please make the changes described in Section 12 of this draft to
   draft-ietf-tsvwg-rtcweb-qos.

   Please replace [RFCXXXX] in the updated text with the RFC number
   assigned to this draft.

   Please add [RFCXXXX] (with the RFC number assigned to this draft) as
   a normative reference in draft-ietf-tsvwg-rtcweb-qos.

   Please remove Section 12 from this draft (because all those changes
   have already been applied).

If this looks right, Ben, could you clear your Discuss?

Thanks,

Spencer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 22:20:38 -0600

> On Feb 20, 2019, at 6:40 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> After consulting with Heather and with Sandy, I have added this RFC Editor note:
> 
> RFC Editor Note
> 
>    which is approved but waiting in the MISSREF state, we ask the RFC Editor

If it works for Heather and Sandy, it works for me.

> If this looks right, Ben, could you clear your Discuss?

Done.

Thanks!

Ben.