[ippm] AD review of draft-ietf-ippm-multipoint-alt-mark-05

Mirja Kuehlewind <ietf@kuehlewind.net> Fri, 21 February 2020 15:47 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420D5120852; Fri, 21 Feb 2020 07:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 LAj72tAwjkck; Fri, 21 Feb 2020 07:47:15 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 BB6A2120876; Fri, 21 Feb 2020 07:47:12 -0800 (PST)
Received: from 200116b824c4be0061570d07dc536186.dip.versatel-1u1.de ([2001:16b8:24c4:be00:6157:d07:dc53:6186]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j5AWC-0000Cm-6C; Fri, 21 Feb 2020 16:47:08 +0100
From: Mirja Kuehlewind <ietf@kuehlewind.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <930239D0-701D-43AD-994E-233271EABD4D@kuehlewind.net>
Date: Fri, 21 Feb 2020 16:47:07 +0100
Cc: IETF IPPM WG <ippm@ietf.org>
To: draft-ietf-ippm-multipoint-alt-mark.all@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1582300035;4c92b3a6;
X-HE-SMSGID: 1j5AWC-0000Cm-6C
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/irW2AuXcW6Bpk0K4bGrCRDQXNPs>
Subject: [ippm] AD review of draft-ietf-ippm-multipoint-alt-mark-05
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 15:47:19 -0000

Hi authors,

I’m ready to request IETF last call for this document. However, I have one question I would like to discuss:

Why is this document experimental? I know that RFC8321 is also experimental, however, that was probably also a borderline decision but in RFC8321 there are at last mechanisms that will be implemented in interoperable protocols, while this document really only describes mechanisms that can be applied based on existed singling. Further if something is experimental, it also good practice to briefly discuss “what the experiment is”. However, I don’t see this approbate here. Therefore for me this document is clearly informational.  

As I’m stepping in March, and we are therefore running a bit out of time, I would like to start IETF last call today no matter what. If you read this mail in the next hours and agree to change to Informational, please do so right away and submit a new version. Otherwise I will request IETF last call anyway later today. Given that experimental and informational have the sam maturity level, we can still change the intended status later without having to re-do the IETF last call.

Also, as no normative language is used, please remove the Requirements Language disclaimer and reference to RFC2119 with the next update.

Find below some minor editorial nits that you may want to address now or in a later version!

Thanks!
Mirja


------
Some editorial nits:

1) Based on the RFC Style Guide RFC7322, you cannot use reference in the abstract. It fine to have an RFC named there, just remove the reference. Further I actually think the last sentence is probably not needed at all in the abstract.

2) In Intro:
OLD
"The alternate marking method, as presented until now, …”
NEW
"The alternate marking method, as described in RFC 8321 [RFC8321], …”

3) In Intro:
"Note that additional details about the
   Alternate Marking methodology are described in the paper
   [IEEE-Network-PNPM]”
Is this sentence really needed? Should the spec in RFC8321 be complete?
(Note that the dot at the end of the sentence is also missing)

4) In Intro:
s/BUM (Broadcast Unknown Unicast Multicast)/BUM (Broadcast, Unknown-unicast, and Multicast)/

5) sec 8.2.1:
s/if we would perform a delay measurement/If we would perform a delay measurement/

6) sec 8.2.2:
s/that don't match/that do not match/

9) sec 9
s/flexibility to PM/flexibility to Performance Management (PM)/