Re: [Dots] [yang-doctors] Yangdoctors last call review of draft-ietf-dots-telemetry-14

mohamed.boucadair@orange.com Fri, 27 November 2020 06:22 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EDB3A124C; Thu, 26 Nov 2020 22:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 KWMkgN7xZU2o; Thu, 26 Nov 2020 22:22:16 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D15C3A1248; Thu, 26 Nov 2020 22:22:16 -0800 (PST)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4Cj4Kf66Fhz8tbw; Fri, 27 Nov 2020 07:22:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1606458134; bh=vRl+TaALZgFayIMLwjt2oa+Tx5hz/+Dms0zSzMblqOU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=oIcIaw+mHRcHST02EiMyw7DBM3C0rAQ1LELDiMPlC3sRsOiQSmi6Sw5e/FVgswGCf oH8gF9p9QfY2VgswWuxfxo1qf7UktZXhlZVHd1bOwqOFdmYvaEedp5IN16/YLPTcYz LiE042c+6O7k9QeSyB0AhD6ZY5MVHRibIvStq5+Zg2epOGnrIP9qiRCbePd1XxQISW A3tl/f0+f451IDY4NE8kHWPJCOnSDtVM2IS4CQAUfDI90JewGhteJiboK+y15ZoMwB fCJfvTun3O6LKz9md/yht+LIJ4Zh3bw9HPZQCixoPfqRcwFXFl+Hm1geq/nisCUlIJ E845FgK3Sl2YQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4Cj4Kf4TXRzCqjj; Fri, 27 Nov 2020 07:22:14 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Andy Bierman <andy@yumaworks.com>, Jan Lindblad <janl@tail-f.com>
CC: YANG Doctors <yang-doctors@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-dots-telemetry.all@ietf.org" <draft-ietf-dots-telemetry.all@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [yang-doctors] Yangdoctors last call review of draft-ietf-dots-telemetry-14
Thread-Index: AQHWxBwEzYV8/Rd8h0mhbYrkf10wbqnbfZqg
Date: Fri, 27 Nov 2020 06:22:13 +0000
Message-ID: <32155_1606458134_5FC09B16_32155_403_1_787AE7BB302AE849A7480A190F8B9330315849E9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160639060194.12249.1456224995663816670@ietfa.amsl.com> <CABCOCHSUQaAWZy+kwcavv21oOvBdzYECV=BmG+3D3kR4xGp5zQ@mail.gmail.com>
In-Reply-To: <CABCOCHSUQaAWZy+kwcavv21oOvBdzYECV=BmG+3D3kR4xGp5zQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330315849E9OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/L5vEwPU5B9d-srruoV26Wq6mQco>
Subject: Re: [Dots] [yang-doctors] Yangdoctors last call review of draft-ietf-dots-telemetry-14
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Nov 2020 06:22:19 -0000

Hi Andy, all

Thanks.

One clarification in reference to this comment:

« But you are raising an important point -- it is difficult to review groupings without any context.
(Without any "uses"). »

Please note that all defined groupings are used in this draft.

Cheers,
Med

De : Andy Bierman [mailto:andy@yumaworks.com]
Envoyé : jeudi 26 novembre 2020 18:46
À : Jan Lindblad <janl@tail-f.com>
Cc : YANG Doctors <yang-doctors@ietf.org>; last-call@ietf.org; draft-ietf-dots-telemetry.all@ietf.org; dots@ietf.org
Objet : Re: [yang-doctors] Yangdoctors last call review of draft-ietf-dots-telemetry-14



On Thu, Nov 26, 2020 at 3:36 AM Jan Lindblad via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
Reviewer: Jan Lindblad
Review result: Almost Ready

Dear Dots Authors, NETMOD WG,

This is my YD LC review of draft-ietf-dots-telemetry-14. This draft contains
two YANG modules, ietf-dots-telemetry and module ietf-dots-mapping. Both
modules are unusual from a YANG perspective in that they consist of solely
typedefs, groupings and sx:structures, and that their purpose is to define
message bodies for a domain specific management protocol.


This is consistent with the intent of RFC 8791.

People have realized that a formal message definition that can be integrated
into the tool chain is much better than 100 pages of ASCII art.  Augments,
annotations, and deviations are not only possible, but critical to deployment.

But you are raising an important point -- it is difficult to review groupings without any context.
(Without any "uses").

Since my previous review of this module (-09, June 2020) the underpinnings of
the modules have changed significantly with a new RFC in the works, addressing
the fundamental issues pointed out at that time. Very good & impressive. I
still think there are important issues to resolve, so I will call the current
state of -14 "Almost Ready".

Links to previous relevant reviews:
https://datatracker.ietf.org/doc/review-ietf-dots-rfc8782-bis-00-yangdoctors-early-aries-2020-09-23/
https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-09-yangdoctors-early-lindblad-2020-06-30/

Because of this hitherto unusual application of YANG, the usual YD review
procedures are not really applicable. Whoever reads this should feel free to
comment on which perspectives should be included (or not) in an YD review of a
YANG module defining a new protocol.

I think the YD review should not be expected to cover the
usability/interoperability of the newly defined protocol as a whole. E.g. which
messages are sent when, what is the relevant/reasonable content in each
message, are there any races or scalability issues, etc. IMO, such an analysis
is essential, but too much work for an YD review (and outside my area of
expertise). I have placed my review focus on the clear interpretation of the
YANG modules, since that will be key to interoperability.


Agreed.  The protocol document review is a separate matter.


When YANG is mapped to NETCONF or RESTCONF, there are entire RFCs devoted to
describing how that mapping is done, from what "mandatory" actually means in
the protocol and how keys are sent, all the way to how the XML or JSON payloads
are constructed and potential error messages. A lot more of that mapping is now
present in this document, but I still find many aspects that are
undefined/unclear.

But this is related to the message encoding, not the YANG definitions.
YANG is (trying to be) encoding-independent, and the YANG to CBOR and SID drafts explain
how to encode any type of YANG data in CBOR.



Andy


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.