Re: [ippm] Ignas Bagdonas' Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 21 June 2018 22:25 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 87B8B1310EA; Thu, 21 Jun 2018 15:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rE9WzbVfmYLk; Thu, 21 Jun 2018 15:25:05 -0700 (PDT)
Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 553B0131109; Thu, 21 Jun 2018 15:25:05 -0700 (PDT)
Received: by mail-yw0-x244.google.com with SMTP id k18-v6so1727204ywm.11; Thu, 21 Jun 2018 15:25:05 -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=G8CcjlWkUp/UtYuethBbLgIRbS1QvTekCalTghjl7es=; b=pDH5LfwO1IApM9nS78dWsLDTSoefHXfQFKTpQuE0uNeZbE9/1924m980mb6vQZiDoO 0+DmweABvXsMXJri4HMAewNzLqlS2goqAemMS4BUY6JDqUQD5E7sQf4RETor+KCsHjZb HLfGlzZSEKg0F22c2uQsggGgdxpjMH2q+fAEddWQSDSMSLGc+U7SgaibYuCfSxJ9ZCsY zrpfSI8X6SmhXGrmDFrNrU9PBD/13o/NCxmiYYiwgmpT3FR4mYDDZUYTIsNA+6eUzMR/ pzBBLsuJmx8FNCPKMbsH5Yi4sa/Y9E+tFfzL4TnNBWRRQZWWnaUE/w+CrNnaF/hojCfI hvMQ==
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=G8CcjlWkUp/UtYuethBbLgIRbS1QvTekCalTghjl7es=; b=EpzVvD2t+TbCnStYatMmntjIvBuxR9OlUoj42GVRBv7tu6If2XiXT65pv4RkKiHO9p FSJFkfKjcdoOk5jNwodOMma7xmahBCkWb6ciHQxugzefyQK5ziVFMzjvSoy1U4hB/rvR GhUrMBGF1kZNFJHFcHTPe+kCjToUmMLpqExUfFDRcIXf0MDkEontTDbwtEbBxEgycuxp yATl0h42AUCQrWIKsxtIsjTmU+dtk/gl/YEcj6rzqahvCm4HxFeh3A6qswsMqYZ0GBLm 2/bq1Jiw+4LeoR1+UVGT0pnsGSfrRgQVWCabijX25j1QNSQDjZ2zNEIOBNIcJaesFf9q VwWA==
X-Gm-Message-State: APt69E0pFaxHXNxFJXK0dDuLrMa4Jh6a4Nx4cev7ETfwlOBri5FFL+0L Wv2yNsfVsRYPNbyhh+ZEqfogJB6GPsXQebKLNIZA6w==
X-Google-Smtp-Source: ADUXVKKBA77MkCRuorhpDbXjvKJZg2PLciHwOnRcVqYqOJDTPycWjjHJLCOktQ3y1N2ucXqfk9M9/u8FHlJBP1POasc=
X-Received: by 2002:a0d:fc46:: with SMTP id m67-v6mr13326651ywf.52.1529619904381; Thu, 21 Jun 2018 15:25:04 -0700 (PDT)
MIME-Version: 1.0
References: <152950984681.28540.15458643208076088093.idtracker@ietfa.amsl.com> <6F0F300E-F699-4DE2-8C13-710264957452@gmail.com>
In-Reply-To: <6F0F300E-F699-4DE2-8C13-710264957452@gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 21 Jun 2018 17:24:52 -0500
Message-ID: <CAKKJt-diyCNeR5aRDTMUd-Z-H95ebkBjqG_Egu+8pt1Et4fhTw@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Ignas Bagdonas <ibagdona@gmail.com>, ippm-chairs@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org, IESG <iesg@ietf.org>, ippm@ietf.org, Nalini Elkins <nalini.elkins@insidethestack.com>
Content-Type: multipart/alternative; boundary="0000000000000ac7e7056f2e634b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/SCITFrjpXG2XZGLgeCzeV0cVeDM>
Subject: Re: [ippm] Ignas Bagdonas' Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 21 Jun 2018 22:25:08 -0000

I'm not Ignas and can't answer whether these responses address his Discuss,
but if I might make a couple of comments ...

On Thu, Jun 21, 2018 at 3:46 PM Mahesh Jethanandani <mjethanandani@gmail.com>
wrote:

> Hi Ignas,
>
> > On Jun 20, 2018, at 8:50 AM, Ignas Bagdonas <ibagdona@gmail.com> wrote:
> >
> > Ignas Bagdonas has entered the following ballot position for
> > draft-ietf-ippm-twamp-yang-11: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I have three large areas of questions related to this model. They are not
> > related to the contents of the module itself but to the broader scope of
> where
> > this model can and should fit in the overall context of practical
> manageability
> > and usability.
> >
> > 1. Operational state. Section 2 defines operational aspects of the
> configured
> > TWAMP mechanisms as being out of scope. How does that relate to the
> motivation
> > goals in section 1? Having no common machine readable mechanism for
> retrieving
> > measurement results and verifying the operation of measurement processes
> does
> > not seem to help in reducing the need for proprietary mechanisms.
>
> The idea behind describing operational part of the model as out of scope,
> particularly as they relate to measurement results, relates the work that
> is currently going on in the “Registry of Performance Metrics (PM)”,
> something the IPPM WG is trying to finish. Once that work is complete, this
> model can be enhanced or another one written to provide the data needed for
> PM.
>

Somewhere between this response and Al's related response, I suspect it
would be helpful to say this in the document, for readers who aren't
specialists like you folks.


>
> >
> > 2. What is the compatibility of this model with NMDA?
>
> This model is compatible with NMDA.
>

The IESG has been balloting on several YANG model revisions lately, because
the original versions predated NMDA and needed to be updated to be
compatible with NMDA. That turned out to be big enough to appear in the
Abstract and Introduction - for example, in the protocol action for
draft-ietf-rtgwg-lne-model-09.txt, you'll see

RFC Editor Note:

Please update first sentence of Abstract from:

"This document defines a logical network element YANG module."
to:
This document defines a logical network element NMDA-compliant YANG module."

and the first line of the Introduction from:

"This document defines a YANG [RFC6020] module to support the creation
of logical network elements on a network device. "
to:
"This document defines an NMDA-compliant YANG [RFC6020] module to support
the
creation of logical network elements on a network device. "

This is to make sure the point is captured. Authors & RFC Editor are welcome
to improve the text or change how the point is made.

If you already did the work to make the model compatible with NMDA, the
IESG seems to want people to take credit for having done the work ;-)

I hope that's helpful, and not just in resolving Ignas's Discuss.

Spencer


>
> >
> > 3. Key storage. The document defines its own way of storing keys - while
> there
> > are multiple existing ways to store keys (routing key-chain model,
> I2NSF, IPsec
> > model, netconf-keystore). Why yet another key storage mechanism is
> required?
> > What could be reused from other existing mechanisms?
>
> Precisely. When we started work on this draft, there were plethora of
> ideas on how to store keys. We borrowed the idea from what is now the
> ietf-key-chain module to define the key chain. And we followed the KISS
> principle by incorporating what was absolutely needed by TWAMP.
>
> Having the answers for the three points that you have raised, would you
> still have a DISCUSS. If so, which issue, do you want to see addressed?
>
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > RFC1305 is obsoleted by RFC5905.
>
> Updated.
>
> >
> > A nit suggestion - YANG examples typically look more readable in JSON
> encoding.
>
> I am reading this is more as a suggestion than as a nit.
>
> >
> > IANA considerations section - likley the registrant contact should be
> the IESG and not the IPPM WG?
>
> Will fix.
>
> Thanks.
>
> >
> >
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>