Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-what-not-to-do-13
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 20 October 2020 21:07 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5A23A13B0; Tue, 20 Oct 2020 14:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9XFQCcq2y3ug; Tue, 20 Oct 2020 14:07:54 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A66C3A13AF; Tue, 20 Oct 2020 14:07:54 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id c129so3114376yba.8; Tue, 20 Oct 2020 14:07:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVnwiFOEs+AvpmInEvzm8+UdMiS5JY1ahvwrbxnUrhM=; b=sUVVByWfIdDpXUfeY/mc0qn1qBVsVDFgD8wa3Kxng7p9ZKAZqmi7SosZ9BgioTTcKz RvxHeQ7X6xOQxg+3ytwGnJtWO0G5XygCRje8HTQzZ8JRcPtC+C2pvrfrKbP3mIej4v5g bUvznYygZH7qdnE6Iqn7zdC0t2fEEufb7Yh1EqwOy/qOfuMhDywlb9FS5LwMhW0GeCcK JeGbhdCnDofwapClYT5pCZUIPJcGTH9u1mgJZLYZ5k33cUB3V8QsCAfdr9HgCSBHZVMN cxu6U1e+2mXXKwlu64KLrPBg0XLz28QwCsZyiUfXaLC9/HpHS0dQQDrzTGklqR5mB6yH xeXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVnwiFOEs+AvpmInEvzm8+UdMiS5JY1ahvwrbxnUrhM=; b=H5a1m4DqiSoWfLr/ADSgOuhsQfk1pOr6ItpP9gSmKJv7tzKcu0+BMo5dIseaV7oOQv unZNNEw0X2ngXCm7QucM900EnMhMuPbQHtLrYeWKvMWybsxdS8YGBOB+Fx5Vp1OclB7B +gUO8ecRysmGYMlmamBqyVxiALTp6ysvYbyl5edxa4qNuMZ1zh0Q4eLv4oBFH4JqRB+a 5rvw87Ws8KA7x3k2F4jLZ3o9YrWnVQpssIB3Otfo8+neS2a4oBNTZQLTpfJW4VonDMX5 LnKStEc2TTSCMZvPOCJXIi8wPnG/G6I+iBUx5hmEQ1CRf+ymabdkjxoeMp8R8CBy7Zpm ZhRw==
X-Gm-Message-State: AOAM532mkyk2ugJ1UyS7amZmU77R/7c+MvfvwE8PXL1TdsYI+hTuh1QI WwcJOklMil6stZ7+bPl8K2iAFPhiOieituSOoA8=
X-Google-Smtp-Source: ABdhPJzt0hYw3NxWAsGLul2VamzuDNziyDdIgvYYPVx0qbSrV9FLMPqvQQHkTavyBtvYGOUDyGQMtzXqVd9Xl/QPt60=
X-Received: by 2002:a25:4e43:: with SMTP id c64mr524363ybb.380.1603228073172; Tue, 20 Oct 2020 14:07:53 -0700 (PDT)
MIME-Version: 1.0
References: <383122CA-DB74-4E34-B7C9-B8E629871E98@csperkins.org> <86ae7b43-c3af-f233-4027-7341509bae34@cdt.org>
In-Reply-To: <86ae7b43-c3af-f233-4027-7341509bae34@cdt.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 20 Oct 2020 16:07:27 -0500
Message-ID: <CAKKJt-cyCk4vKH9SWD6-8xqvqj2CxZ4gzA-AdMmpX2B6VLKxfQ@mail.gmail.com>
To: Mallory Knodel <mknodel@cdt.org>
Cc: The IRSG <irsg@irtf.org>, panrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000cba67305b2209f3a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/rg9_-EhikSxvXLIl4DN6NQyZgxI>
Subject: Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-what-not-to-do-13
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 21:07:57 -0000
Hi, Mallory, Thanks for looking at this draft with new eyes! I'll see what the shepherd/chairs/research group think, and I hope we can resolve this before IETF 109 (but that's just me talking). Best, Spencer On Tue, Oct 20, 2020 at 2:47 PM Mallory Knodel <mknodel@cdt.org> wrote: > Dear Spencer, panrg and irsg: > > It was my pleasure to read this document as it was a thorough compendium > of Path Aware Networking in the IETF and serves as a great primer! > > My main comments on the draft are really to increase accessibility and > readability of what surely is thorough, complete and clear documentation > of a high quality appropriate for IRTF documents. I also realise that > because my suggested edits are quite structural, that it's very likely > you've had these conversations in the RG already and so if this walks > back a previous agreement, feel free to disregard. > > While I read, I did a lot of flipping back and forth, particularly > between Sections 2 and 5. I usually do a lot of flipping anyway; this > review was uniquely flip-heavy. You also have a lot of internal > references. I'd suggest a restructure thusly: > > * Section 1: Pairing down mostly meta information about the RG > (documented elsewhere), doc (not all the background is pertienent > context), etc so that the reader gets to the lessons quicker. > > * Section 4: Make this a methodology section right after the > introduction, also to potentially guide future contributions. You can > then explain how you first collected contributions and then extracted > the important details, drew lessons learned and conclusions. You can > explain here categories for Table 1. > > * Compress Sections 2, 3 and 5. I can see value in just getting the > lessons upfront, but if you perhaps nest the various contributions > wisely you can create sub-sections and even sub-sub-sections here, > allowing you to give the reader the highest points (Section 3), followed > by generalisations (Section 2), followed by Sub-sections (Section 5). > Your headings are well phrased, such that if one doesn't want to read > the details of Section 5, they can stop reading and/or skip. This also > allows your Section 5 to be sparse-- perhaps there's sufficient > documentation elsewhere on the internet that you could simply reference > and leave in just a summary/abstract of lessons learned without the > burden of having to include the data of a full contribution. > > If you take my last suggestion, you might want to add to your template > for contributions that you'd like a summary/abstract (a la Section 2) > and a suggested category (a la Table 1). > > Lastly I'll point out that "What Not To Do" is a terrific framing, but > then you need to ensure that your Section 2 headings/section titles have > the same value frame (positive vs negative). Eg "DO Justify Deployment" > or "DON'T React to Distant Signals". Whatever it is, just pick one and > then adjust the rest. Or spell it out in each sub-section title. > > Nits: > > * Someone like me needs just one sentence in the introduction about > the problem that PAN solves. It's probably just so obvious to you all! > > * The first paragraph of 1.1. seems to be missing a specific reference > to "path aware networking" otherwise it's quite generic a statement. > > * RFC 5218 seems like an appropriate reference for 2.1, 2.2 and 2.3? > Again, pretty generic and not PAN specific, seemingly. > > * 2.1 would suggest "_U.S._ American English" since most of America > (the hemisphere) doesn't even speak English, and we also appreciate > Canadian Anglophones who may or may not use this phrase. > > * 2.6 last sentence: You might have meant "These _changes_ may make > deployment..." > > * 2.7 Needs perhaps another sentence that answers "Why?". > > * 1.4, 2.12 there are sometimes notes about what might be done to > mitigate the problem faced. These might be out of scope? But probably > they are extra valuable and should be emphasized in a separate > sub-section or summary, somewhere. > > -Mallory > > On 9/6/20 2:45 PM, Colin Perkins wrote: > > IRSG members, > > > > The Path Aware Networking Research Group has requested that > draft-irtf-panrg-what-not-to-do-13 be considered for publication as an IRTF > RFC. To progress this draft, we now need *at least one* IRSG member to > volunteer to provide a detailed review of the draft, as follows: > > > >> The purpose of the IRSG review is to ensure consistent editorial and > technical quality for IRTF publications. IRSG review is not a deep > technical review. (This should take place within the RG.) At least one IRSG > member other than the chair of the RG bringing the work forth must review > the document and the RG’s editorial process. > >> > >> IRSG reviewers should look for clear, cogent, and consistent writing. > An important aspect of the review is to gain a critical reading from > reviewers who are not subject matter experts and, in the process, assure > the document will be accessible to those beyond the authoring research > group. Also, reviewers should assess whether sufficient editorial and > technical review has been conducted and the requirements for publication > described in RFC 5743 have been met. Finally, reviewers should check that > appropriate citations to related research literature have been made. > >> > >> Reviews should be written to be public. Review comments should be sent > to the IRSG and RG mailing lists and entered into the tracker. All IRSG > review comments must be addressed. However, the RG need not accept every > comment. It is the responsibility of the shepherd to understand the > comments and ensure that the RG considers them including adequate dialog > between the reviewer and the author and/or RG. Reviews and their resolution > should be entered into the tracker by the document shepherd. > >> > >> The IRSG review often results in the document being revised. Once the > reviewer(s), authors, and shepherd have converged on review comments, the > shepherd starts the IRSG Poll on whether the document should be published. > > Please respond to this message if you’re able to perform such a review, > and indicate the approximate time-frame by which you’ll be able to complete > it. The document shepherd write-up is available at > https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/shepherdwriteup/ > > > > Thanks! > > > > Colin (as IRTF chair) > > -- > Mallory Knodel > CTO, Center for Democracy and Technology > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > > >
- Re: [PANRG] [irsg] IRSG review request draft-irtf… Mallory Knodel
- Re: [PANRG] [irsg] IRSG review request draft-irtf… Spencer Dawkins at IETF
- Re: [PANRG] [irsg] IRSG review request draft-irtf… Colin Perkins
- Re: [PANRG] [irsg] IRSG review request draft-irtf… Spencer Dawkins at IETF