Re: [yang-doctors] Yangdoctors last call review of draft-ietf-dots-rfc8782-bis-02

mohamed.boucadair@orange.com Wed, 02 December 2020 06:27 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6AE3A1144; Tue, 1 Dec 2020 22:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 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, 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 syq-u1L7ruqm; Tue, 1 Dec 2020 22:27:22 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBB63A115E; Tue, 1 Dec 2020 22:27:19 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4Cm8CB1pnYz7tTB; Wed, 2 Dec 2020 07:27:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1606890438; bh=/5XkC+MJ7wef2vjj9fOfORzQRB/aKNltrGXWcJWD2Qc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=mS8Hn2ltA1R1wuqZG48FWnfCzSjiU85kTzcFtbD+rsHkSvMp56YFk/9KEKJqO2cnd 028lqnwxHXCK2gSnr/U5hg70ePx/U+DEVIF7bvEHO2N16Ap+5EkxHpusSHJ/UMrxGp 4D49Vgd7jRH5Sg1ZT5d0Fyz2lWVlmYBtfV8Zy0tuLLXCYZf3DG09nRfmYrEWjZKeLV zjYZkDJfWTceIt8mhnHnh1Z75gnvbfeousv0OSxvANznglnU0A2spjGfyPC8qDg2f6 FuK4q/L6VOLXmc1GBSLinQs+bnJHZPVm5e6XixFjPdmIRifHEBzApFEEiOgYA9gP7U zVGHkQOu7nXng==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4Cm8CB0Xl2z3wbD; Wed, 2 Dec 2020 07:27:18 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Ebben Aries <ebben.aries@nokia.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "dots@ietf.org" <dots@ietf.org>, "draft-ietf-dots-rfc8782-bis.all@ietf.org" <draft-ietf-dots-rfc8782-bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Yangdoctors last call review of draft-ietf-dots-rfc8782-bis-02
Thread-Index: AQHWyDjM9AmiMrs1DEaAhG8kuNZu16njVGqg
Date: Wed, 02 Dec 2020 06:27:17 +0000
Message-ID: <14692_1606890438_5FC733C6_14692_114_1_787AE7BB302AE849A7480A190F8B9330315926BE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160686493001.17117.9724616300764054197@ietfa.amsl.com>
In-Reply-To: <160686493001.17117.9724616300764054197@ietfa.amsl.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/Krvwciz4o8CT5YQFf0_VOWOAuuU>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-dots-rfc8782-bis-02
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 06:27:31 -0000

Hi Ebben, 

Thanks for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ebben Aries via Datatracker [mailto:noreply@ietf.org]
> Envoyé : mercredi 2 décembre 2020 00:22
> À : yang-doctors@ietf.org
> Cc : dots@ietf.org; draft-ietf-dots-rfc8782-bis.all@ietf.org; last-
> call@ietf.org
> Objet : Yangdoctors last call review of draft-ietf-dots-rfc8782-bis-
> 02
> 
> Reviewer: Ebben Aries
> Review result: Ready
> 
> 2 modules in this draft:
> - ietf-dots-signal-channel@2020-09-24.yang
> - iana-dots-signal-channel@2020-09-24.yang
> 
> YANG compiler errors or warnings (pyang 2.4.0, yanglint 1.9.2)
> - No compiler errors or warnings however pyang 2.4.0 is currently
> the only
>   compiler verified to emit YANG sx:structure data in tree format.
> Instance
>   data could not yet easily be validated given the current
> linters/compilers.
> 
> 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-14-
> yangdoctors-lc-lindblad-2020-11-26/
> 
> Updates/comments since prior review
> ------------------------------------
> 
> While there is a -02 version of the draft posted since the YANG
> Doctor review request against -01, the updates reflect textual
> wording of the draft and YANG module contents have not changed thus
> this review encompasses the latest -02 version as well.

[Med] I confirm. 

> 
> Since the -00 version, the following previous review comments have
> now been
> addressed:
> 
> - Textual wording in the draft around IPv4/IPv6 prefix lengths
> - The prefix for 'ietf-dots-signal-channel' is now updated to a more
>   descriptive 'dots-signal'
> - Import prefixes are updated to reflect usage of the imported
> module prefix
> - Author email address corrections
> - The prefix for 'iana-dots-signal-channel' is now updated to a more
>   descriptive 'iana-dots-signal' and thus this module now carries
> with it a
>   revision bump
> 
> Updated nodes:
> 
> The 'lifetime' node has now been updated from a single 'int32' value
> to a union of uint32 and int32 with a range restriction.  From a
> modeling standpoint for the uint32 value, while '0' is invalid in a
> request, it appears the status retrieval could very well still
> report '0' for a brief period of time thus assume this is the reason
> for not implementing a range restriction on the uint32 value as well
> indicating "1..4294967295"?

[Med] Yes. 

> 
> Now, when this translates into CBOR representation, the wire
> protocol I will assume (Sorry just briefly researched this re: CBOR)
> will differentiate 2 separate types here so we don't run into -1 and
> 4294967295 both representing indefinite lifetime?

[Med] Whether this is an indefinite lifetime is determined from the CBOR major type (1 in this case for CBOR key 14 (lifetime)).    

> 
> While I share similar opinions to Jan's review in
> review-ietf-dots-telemetry-14-yangdoctors-lc-lindblad-2020-11-26 in
> relation to the draft and data structure definitions, I believe from
> a YANG doctor review standpoint, we are ready to move forward with
> this draft/module-set.

[Med] Thank you.


_________________________________________________________________________________________________________________________

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.