[Gen-art] Genart Telechat review draft-ietf-p2psip-diagnostics-19

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 15 December 2015 11:19 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C19B21A21A8; Tue, 15 Dec 2015 03:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id u__lUefm_5iC; Tue, 15 Dec 2015 03:19:33 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com []) by ietfa.amsl.com (Postfix) with ESMTP id 081461A6EE8; Tue, 15 Dec 2015 03:19:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1450178369; d=isode.com; s=selector; i=@isode.com; bh=02jSNwACwVWAgdFdm7IicKM4U8GXzETotY+jKvd1q4I=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vBX1uwzCBhNapHtl5pnyGe3zGot6dnesGWeU83rCHs/JoUvXd8JgrkapDVe0PFQPf3ecQg CGE3hJwd+GrBDpnAhUX3KCKpRiLD0hdK7Uc9BLpLgZrbCVp7aOONa5QOVvTFBZeyMaHC5/ Z+KvN3OEjS0xAHsGRzsBMRTWTw27aYU=;
Received: from [] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net []) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <Vm=3PwBSXG0j@waldorf.isode.com>; Tue, 15 Dec 2015 11:19:28 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: General Area Review Team <gen-art@ietf.org>, iesg@ietf.org, draft-ietf-p2psip-diagnostics.all@ietf.org, draft-ietf-eppext-keyrelay@ietf.org
References: <56562C04.2060308@nostrum.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <566FF737.40103@isode.com>
Date: Tue, 15 Dec 2015 11:19:19 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <56562C04.2060308@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/haebhCzo0eFTBgxyk4NUHhSykt4>
Subject: [Gen-art] Genart Telechat review draft-ietf-p2psip-diagnostics-19
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2015 11:19:34 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-p2psip-diagnostics-19
Reviewer: Alexey Melnikov
Review Date: 2015-12-15
IETF LC End Date:
IESG Telechat date: 2015-12-17

Summary: Nearly ready for publication as Proposed Standard

I think this document has a list of issues, but they should be easy to fix:

In Section 5.3:

The dMFlags field described above is a 64 bit field that allows
   initiator nodes to identify up to 62 items of base information to
   request in a request message (the first and last flags being

But the IANA registration section uses flags 1 and doesn't seem to
reserve the highest bit either. If this text is now wrong, it should be
deleted. If the IANA section is wrong, please fix it. If I am wrong,
please tell me :-).

In Section 5.3:

SOFTWARE_VERSION: A single value element containing a US-ASCII
      string that identifies the manufacture, model, operating system
      information and the version of the software.  Given that there are
      very large number of peers in some networks, and no peer is likely
      to know all other peer’s software, this information may be very
      useful to help determine if the cause of certain groups of
      misbehaving peers is related to specific software versions.  While
      the format is peer-defined, a suggested format is as follows:
      "ApplicationProductToken (Platform; OS-or-CPU) VendorProductToken
      (VendorComment)".  For example: "MyReloadApp/1.0 (Unix; Linux
      x86_64) libreload-java/0.7.0 (Stonyfish Inc.)".  The string is a
      C-style string, and MUST be delimited by "\0".

Did you mean "terminated"? I don't see what can be delimited, as this
implies presence of multiple fields.

      "\0" MUST NOT be
      included in the string itself to prevent confusion with the

EWMA_BYTES_SENT (32 bits): A single value element containing an
      unsigned 32-bit integer representing an exponential weighted
      average of bytes sent per second by this peer. sent = alpha x
      sent_present + (1 - alpha) x sent where sent_present represents
      the bytes sent per second since the last calculation and sent
      represents the last calculation of bytes sent per second.  A
      suitable value for alpha is 0.8.  This value is calculated every
      five seconds.

I don't understand the formula. What is "x"?
Should the formula be on its own line for ease of understanding?


This flag doesn't seem to be defined in a useful fashion. You need to at
least provide some guidance here to insure interoperability.

In Sections 9.3-9.5: is RFC-AAAA this document or RFC 6940 (or something

Thank you,