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

["Black, David" <[e-mail]>]

>> 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.
>
>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 <[e-mail]>
Sent: Wednesday, February 20, 2019 1:19 PM
To: Ben Campbell
Cc: The IESG; [e-mail]; Black, David; tsvwg-chairs; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> wrote:
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.

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