Re: [yang-doctors] Yangdoctors early review of draft-ietf-ippm-stamp-yang-01

Greg Mirsky <> Mon, 23 April 2018 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8762812D873; Mon, 23 Apr 2018 09:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id juMZwYe_AJS2; Mon, 23 Apr 2018 09:53:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66E7012D86D; Mon, 23 Apr 2018 09:53:22 -0700 (PDT)
Received: by with SMTP id g203-v6so15995989lfg.11; Mon, 23 Apr 2018 09:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TKcyAVjkCrs8lA+YWSIXY/WN5wAUSqRwBIrCg9qJpJM=; b=YYEabmaKqrZmBpf1a0XE6lSHyZZU7lh8qD7dWqPyj0hSy4GyDp5b2s4925Rh0k/lZ2 sYQWRO6ah8O/tHqrXwZPSN1PAHUyLiG1A+NS4p66BhlHKgPc2oMg8W8KZCWTd7vHzqyC NeQdKuko4Y9rvUmzqjEQFmcvJJ1TwcT7sC/H13CpC0svXS6tGba5nhHOmWAQMa0sWyOl Eoljr9kY0JRnxlmUQ6Kp9T0mboLzr9QPRE7TuW673scIAMDJfCrtFsFvibTFH++EfTEk c5hTCIntE5BWYyukWb7uh7o6U4Q2qqFeWbMW+YaZkD+93RKbffh9CuR2pz749WYdBa3f NKvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TKcyAVjkCrs8lA+YWSIXY/WN5wAUSqRwBIrCg9qJpJM=; b=jz58RTDnOA4iYV9pNaCMa7M2UgP4MyuAQjxnN2vWE/TBDDQKd8GTSwSKoYwkR/Ze0q sZe+de4ulmIPMnaHGaBrl/pBVB/1urkkg7/2uf1rLhiCN6uSA6n7QFxh+RtFHH8AdotF ipnPQfxlt5p2EY8X9kOuKemoIfdhwhZZX8hSKtTbD5MsMewyt7sQv7qFfRmnf4z7Srm+ h0P37q6CYV1o9WRqj3+SiubhjkO2gxyY4/TaaZa9zAwBvqWBkazLc0N0+XyTdw5RRDt8 Iyyo/MjO47zFOCZcp7yVXs8kBpkUxD/QxiBoyrpbTn9VtfNcTSnuug1Yd+uCduBaR3nN MhUQ==
X-Gm-Message-State: ALQs6tCU1587OrlPpEOSCzNBkYjmHZT75KQyyCyM4gefpx5T5v9+Z9AR LE07KmPiKvZht/yJ2wz+3SM5KFa80biYQ4NOMhk=
X-Google-Smtp-Source: AB8JxZovhxYUaRF0mOwg/s+CdHrfeX8NI6ciyrVRJ1+vzNScxvRYT8yrHkThw11jV/okaBEHxzbIbChKPyhivbvooZ0=
X-Received: by 2002:a19:1398:: with SMTP id 24-v6mr9734552lft.106.1524502400505; Mon, 23 Apr 2018 09:53:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 23 Apr 2018 09:53:19 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Greg Mirsky <>
Date: Mon, 23 Apr 2018 09:53:19 -0700
Message-ID: <>
To: Mahesh Jethanandani <>
Cc:, IETF IPPM WG <>,,
Content-Type: multipart/alternative; boundary="0000000000000a9ef4056a86e09e"
Archived-At: <>
Subject: Re: [yang-doctors] Yangdoctors early review of draft-ietf-ippm-stamp-yang-01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Apr 2018 16:53:28 -0000

Hi Mahesh,
thank you for the thorough review and the most detailed and thoughtful
comments, suggestions. I'll work on the update in steps and will consult
with you to address all issues you've pointed to.

Best regards,

On Sun, Apr 22, 2018 at 10:14 PM, Mahesh Jethanandani <> wrote:

> Reviewer: Mahesh Jethanandani
> Review result: Not Ready
> Document reviewed: draft-ietf-stamp-yang-01
> Status: Not ready.
> Summary:
> This document specifies the data model for implementations of
> Session-Sender
> and Session-Reflector for Simple Two-way Active Measurement Protocol
> mode using YANG.
> Minor
> - Please update references of RFC6020 with RFC7950, as this is a YANG 1.1
> model.
> - Please add a separate paragraph or section of notes to the RFC editor,
> instead of scattering it across the document. RFC Editors appreciate not
> having
> to look for instructions all over the document. - Also what does “ref to
> draft” imply? This draft, some other draft, or RFC? - Please update
> references
> to NMDA architecture document.
> Major:
> If the data model is for STAMP, how is that RFC (or I-D) not referenced
> anywhere in the model? At the minimum most of data nodes should have
> references
> to the sections that describe them in the STAMP RFC.
> Please fix indentation issues in the model. I see use of 1 space, 2
> spaces, 4
> spaces and even 8 spaces in the model. It makes reading of the model very
> difficult.
> If statements carry into a subsequent line, consider indenting the second
> line.
> s/stamp/STAMP/g
> This document is NOT NMDA compliant. The whole idea of NMDA is that you do
> not
> need a separate -state container. NDMA does not advocate having a separate
> container with exactly the same nodes from config. An example is the nodes
> ‘packet-padding-size’ and ‘interval’, which are duplicated in both the
> config
> and -state container. On the other hand ‘duplicate-packets’ and
> ‘reordered-packets’ make sense. Once the duplicate nodes have been removed,
> rather than calling the container stamp-state, call it stamp-statistics, or
> something else that does not imply the same meaning as pre-NMDA models
> containers did.
> Section 2.1
> - The draft says it “describes all the parameters of the stamp data
> model.” I
> do not think you are describing the parameters of the STAMP data model.
> What
> you are describing is the block diagram (Fig 1) or the containers within
> the
> model, not the individual parameters.
> Section 2.1.1
> Once the -state container has been updated/removed, update the second
> paragraph.
> s/referenced by session-id STAMP/referenced session by the session-id of
> the
> Section 3
> I am not sure on the use of MAY. Is it that the use of IP and UDP port is
> sufficient? If so, when it is okay? There is also a use of ‘may’ w.r.t. to
> STAMP test sessions. How are the two mays related?
> Finally, even if one was to use 5-tuple as a key, which includes a DSCP
> value
> that can be remarked, how would one uniquely identify a session?
> Section 3.1
> Please add a informative reference to the Tree Diagram RFC.
> Section 3.2
> Please add references to any RFCs referenced in the model up front, before
> the
> model.
> Remove the comment “//namespace need to be assigned by IANA”. Instead
> update
> the IANA section with the information of what namespace needs to be
> assigned.
> Could a shorter prefix be used, e.g. “stamp”?
> For reference to RFC 6991 and 8177, please add the title of those RFCs.
> For contact, please add the name of individual authors instead of using a
> mailing list, per Section 4.8 of rfc6087bis.
> The description is very sparse. Consider adding more text. Also the
> document is
> missing the IETF Copyright statement, per section 4.8 of rfc6087bis.
> The revision statement should say something like “Initial version” instead
> of
> 00, as those numbers are not relevant once the document is published. Also
> consider replacing “” for the reference statement with something like “RFC
> XXXX: STAMP Data Model”, and have a note of the RFC editor to replace XXXX
> with
> the assigned RFC number.
> Consider updating descriptions for each leaf. A description “Packets
> received”
> for ‘rcv-packets’ is not descriptive. Also add references to sections in
> the
> Why is there a need for feature statements for ‘session-sender’ and
> ‘session-reflector’. Would there be a case that a customer would configure
> a
> ‘session-reflector’ without a ‘session-sender’ or vice-versa?
> What is ’type enable’? Did the authors mean ‘type boolean”?
> Would it not be simpler to have ‘number-of-packets’ or ‘repeat’ as a choice
> statement, where the choice is between a set number of test packets or
> ‘forever’? Same for the other union statements.
> Consider using ‘derived-from’ or ‘derived-from-or-self’ in when statements,
> instead of a string comparison.