Re: [Pce] Rtgdir last call review of draft-farrel-pce-stateful-flags-02

"BRUNGARD, DEBORAH A" <db3546@att.com> Wed, 06 November 2019 17:37 UTC

Return-Path: <db3546@att.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CC41200DE; Wed, 6 Nov 2019 09:37:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE0Zbr9Igna1; Wed, 6 Nov 2019 09:37:55 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB294120020; Wed, 6 Nov 2019 09:37:55 -0800 (PST)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xA6HapdK046695; Wed, 6 Nov 2019 12:37:51 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2w41xfhgxp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 12:37:51 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xA6HboO6006257; Wed, 6 Nov 2019 12:37:50 -0500
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xA6Hbh9Q006144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Nov 2019 12:37:43 -0500
Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id 1746E402D871; Wed, 6 Nov 2019 17:37:43 +0000 (GMT)
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (unknown [130.9.129.148]) by zlp27130.vci.att.com (Service) with ESMTPS id EEC39402D86F; Wed, 6 Nov 2019 17:37:42 +0000 (GMT)
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.44]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0468.000; Wed, 6 Nov 2019 12:37:42 -0500
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: "pce@ietf.org" <pce@ietf.org>
CC: "draft-farrel-pce-stateful-flags.all@ietf.org" <draft-farrel-pce-stateful-flags.all@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <rtg-ads@ietf.org>
Thread-Topic: Rtgdir last call review of draft-farrel-pce-stateful-flags-02
Thread-Index: AQHVj3+PJNOs2JNe3EifHLBvdjFz0ad0rX2AgAa1tZCAAIRIgIABFnuggAFi7kA=
Date: Wed, 6 Nov 2019 17:37:41 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C8A3AAC693@MISOUT7MSGUSRDE.ITServices.sbc.com>
References: <157248059396.32502.7485483203706927333@ietfa.amsl.com> <032601d58fc4$b8564080$2902c180$@olddog.co.uk> <F64C10EAA68C8044B33656FA214632C8A3AA927C@MISOUT7MSGUSRDE.ITServices.sbc.com> <040c01d59359$555872d0$00095870$@olddog.co.uk> <F64C10EAA68C8044B33656FA214632C8A3AAB67B@MISOUT7MSGUSRDE.ITServices.sbc.com>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C8A3AAB67B@MISOUT7MSGUSRDE.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.249.177]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-06_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911060170
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/3ooZUwTEMo5GMDTDtSmpVVPQrWQ>
Subject: Re: [Pce] Rtgdir last call review of draft-farrel-pce-stateful-flags-02
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 17:37:58 -0000

Hi PCE WG,

I've talked with your Chairs and my fellow ADs (Martin and Alvaro). The intent for this document was to be a working group document as it is updating a PCE PS document. It was felt there was no need for renaming to reflect a working group document.

RFC6174 defines Working Group document states. Datatracker uses the filenames to determine the status and the I-D repository. For a document to reflect the source being a working group, the filename needs to reflect it as draft-ietf-wgname.

Martin, Alvaro, and myself agree the filename needs to reflect the wg. It only takes seconds to upload a revised filename. While Adrian is concerned on delays, there is no need for a Chair to poll for "adoption" or "Last Call" a document. What is critical is that a PS document has the appropriate visibility and adequate review for folks to raise concerns/comments. In IETF, the filename is used to identify and it is questionable if an individual filename document receives the appropriate visibility. It only takes seconds to post a new filename.

On this specific document, I noted -00 was posted in June, there were no comments before WG Last Call poll in September. On poll for WG Last Call, only the author responded supporting. Dhruv asked a second time on the list, there were 4 responses. This draft identifies a lack of specification in RFC8231, the proposed change is not backward compatible. A private poll was done and indicates existing implementations are ok with this modification. While among the PCE working group, there often are a small number of respondents, I am concerned the filename itself may not have provided the necessary visibility. Before IETF Last Calling, I have returned the document to the working group to allow the Chairs to change the filename. If anyone in the working group has any concerns/comments on the document, let the Chairs know and also there will be an opportunity to comment during IETF Last Call.

A note to all of you, for the Chairs to judge consensus it is critical for folks to be involved in discussions - support or not support. Do not be shy! The working group mailing lists are looked at by the IESG, IAB, and others (internal and external to IETF) to determine interest/participation level in our standards process. The IAB is evaluating now the process including RFC value (implementations):
https://www.ietf.org/id/draft-huitema-rfc-eval-project-02.txt

The conclusion is the working group process itself introduces the most delays - there are multiple reasons. Let's not have lack of interest by the working group be a delay.

And of course - do not be shy if any questions/concerns on my (or Alvaro's, Martin's) decisions-
Deborah 

-----Original Message-----
From: BRUNGARD, DEBORAH A <db3546@att.com>; 
Sent: Tuesday, November 05, 2019 2:56 PM
To: adrian@olddog.co.uk
Cc: pce@ietf.org; draft-farrel-pce-stateful-flags.all@ietf.org; rtg-dir@ietf.org; <rtg-ads@ietf.org>; (rtg-ads@ietf.org) <rtg-ads@ietf.org>;
Subject: RE: Rtgdir last call review of draft-farrel-pce-stateful-flags-02


Hi Adrian,

What you say is all correct. But it doesn't help with the confusion. I just need to know if this is an individual draft requesting to be PS or is it requested by a working group and (for whatever reason) the filename was not changed to reflect it. There's several guideline documents on filenames:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1id-2Dguidelines.txt&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=8qrvlOQg1GT4q_O677NusZSTqgkju7l-dX4uZotGXPw&s=qmvYdzxgPAjTZT9nVsMNJsjIhqGg9T9onROYLCEr07Y&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6174&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=8qrvlOQg1GT4q_O677NusZSTqgkju7l-dX4uZotGXPw&s=jIQEYvuJDL88KaOl6eDBZM5x75ZOcFDjdKo0C9ao0Rw&e=

There is no need for chairs to spend "weeks" adopting or last calling. What is needed though is for the filename to reflect the correct "source". RFC6174 provides the logistics. Uploading with a wg filename takes seconds (if all is working correctly😊).

As you say, you are an author hoping to quickly progress your document. I'll talk with the PCE chairs as they requested the publication and unless I'm mis-interpreting this can be quickly fixed.

Thanks-
Deborah


-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk>;
Sent: Monday, November 04, 2019 4:47 PM
To: BRUNGARD, DEBORAH A <db3546@att.com>;; rtg-dir@ietf.org
Cc: pce@ietf.org; draft-farrel-pce-stateful-flags.all@ietf.org
Subject: RE: Rtgdir last call review of draft-farrel-pce-stateful-flags-02

Hello Deborah,

I wonder whether something has changed in the IETF process that I'm not aware of. That is possible.

> Adrian, I'm also a bit confused on the intention of the draft. While 
> the tools are not error checking a draft with intended status of PS 
> against a title indicating an individual submission, the title does 
> indicate the source of the document. With the current title, this 
> document is an individual submission to the IETF stream. If this is a 
> product of the working group, the title needs to reflect it. As it is 
> requested to be "PS", it does need to reflect the associated working 
> group.

The document has not been adopted by the working group, but it has been last called by the working group.
While the WG chairs are allowed to adopt a document off their own bat, they prefer to use an adoption poll whenever they do an adoption. That can add a two week poll, but there is also a queue in many working groups, so a document can end up dying of boredom.

If you can point me at the process rule that says that document emerging from a WG must have a specific name format then I guess we can change the document (and also write a draft to change the rule ;-) 

If you can point me at the rule that says Standards Track documents must be the product of a working group (not, for example, AD sponsored) I'll be surprised.

> While it is a bit surprising this was not raised in WG Last Call 
> (hopefully folks have read the document),

The chairs did call out the direct progression of this draft to WG last call in a mail to the list prior to starting the last call.

> it will definitely be flagged with the other Area Directorate reviews 
> and IESG review.

I shall delight in helping them to understand the processes of which they are guardians :-)

> While the working group cycle was very short, the resulting 
> publication cycle will be very long.

Oh, I have long ago given up on doing things to simply follow the path of least resistance. The IESG needs to recognise that they are supposed to facilitate publication (of good documents) not get in the way! If the resulting cycle is long we will at least know why.

> As the WG LC was based on PS status, I would conclude the group is ok 
> with PS. Either you can change the title to reflect a product of the 
> pce working group or change the status to Informational and I'll take 
> it forward as an individual submission. If you change the title to a 
> product of the pce working group, I'll follow up with a note to the 
> list to double check if anyone has any concerns. And then we can move 
> ahead.

I do hope that we will not get hung up on any misunderstandings of process. As you observe, the publication cycle for drafts has become long. Many times they leave the WG and don't hit the RFC Editor Queue for four months.. I see the process including:
- Shepherd review
- Directorate review
- AD review
- IETF last call
- Late directorate reviews
- IESG review
Each of these has three steps:
- Queued for action
- Review period
- Update period

Even when the authors are immediately responsive to any review comments raised, this can drag on a long time. If each review is scheduled for two weeks, that's 12 weeks burned. If the "silent" time to queue for action is also a week or two, you can quickly see why the tail of our process has become a burden. Suddenly the RFC Editor's 8 week queue seems short!

> Looking forward to your choice😊

My choice as author is to follow IETF process.
You've had a publication request, from the PCE working group to publish an Internet-Draft on the Standards Track.
I hope we can proceed with that without further delay.

Thanks,
Adrian