Re: [yang-doctors] Yangdoctors early review of draft-ietf-babel-yang-model-03

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 16 October 2019 18:30 UTC

Return-Path: <mjethanandani@gmail.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 6BA38120241; Wed, 16 Oct 2019 11:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tuw0664imgcJ; Wed, 16 Oct 2019 11:30:38 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 51FFB12010F; Wed, 16 Oct 2019 11:30:38 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id f21so11654259plj.10; Wed, 16 Oct 2019 11:30:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XegQ/o8p3p0M4qZWdhHQ2tbI2BdcY7Rvyme5pYFLVvI=; b=VWOwScQPuOhdslwPNjSoP1niXdrJRXmhPoRxwEF7TnLs35H3aiNM+nKYjzOv8WVfGE xNGVBnjcLsBES3CrbUi2UkqUCX0xtcpuFk3CYvPPeoEIQO8FgwmMN5eQcWigyCPbkvma S+noUWHxSI3BaE+qhkHGXTbK+x6L3r8+2s2A7D+EmHojdC00QBmu9hTuqb6z8TLBVKQc svZdqdxv+FgievHiu9ytEhFZnpARobEus+Efe2bfUlaaMuOlxS/Q1eL0bLicoZaYoOyj 3d6p/P0QIIB/D8s7qXXWVeXS5xRTZZvyKOB3iOyZU0z4/3yPeFYvF29g7TdSDBWAuZfV w/9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XegQ/o8p3p0M4qZWdhHQ2tbI2BdcY7Rvyme5pYFLVvI=; b=lMjFTQJ62GX0la/fw1bPX48qpl2/BANMVblQxGVxm5dxYNwvyJlkV9/GzlDOwHh3U+ DgsoG9/KX0Ku4DNzhvzEAesscRqvDcGrsCD4XUH3kd8c93i5dhlfdXOii97T3IooNnBB 5u96VGNB8Kj3l5zUsMhxPAQ+kSuPdTsedb1YKUEVFek9b6N/1OWg3k1kdVNpehmI7kGK Gac5JWtn2904vPhCZkLdgwxQLHjjsI3osMqAWQpL772wNaxpOVMr2iLFu1IUeIT0rFA7 LiWp9lEE6+gz3xJyoyYz1lF2bba3NLL60lZXKlMgCU0m7THFtxSQDsGM9Pd6ZTGHHwnR Vh6Q==
X-Gm-Message-State: APjAAAVpljQIt2gO1lDZMDY1TUAFX9nC3NYjjr3i21v/xOe7s0vRKdfF BeYNtuMxFTtOPI9DgmQZU47YMj48
X-Google-Smtp-Source: APXvYqxlPTFVhPsm+5KadJbYgJdsi0r3FUVXD5BRW4nrv3wV0uMgbbjWlUTN3WkyzAtJRT8eWYt5Cw==
X-Received: by 2002:a17:902:54f:: with SMTP id 73mr41966024plf.329.1571250637477; Wed, 16 Oct 2019 11:30:37 -0700 (PDT)
Received: from [10.33.123.155] ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id p17sm24308157pfn.50.2019.10.16.11.30.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Oct 2019 11:30:36 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <e7f82974-b8f5-7efd-18ac-354af1954d5f@cesnet.cz>
Date: Wed, 16 Oct 2019 11:30:35 -0700
Cc: YANG Doctors <yang-doctors@ietf.org>, draft-ietf-babel-yang-model.all@ietf.org, babel@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D84A1F2-973D-4FF4-B9DE-BC36AECB2069@gmail.com>
References: <157106166738.24700.11185508261809138396@ietfa.amsl.com> <3532A7A2-E9C2-43AA-A214-4E2AF5470251@gmail.com> <e7f82974-b8f5-7efd-18ac-354af1954d5f@cesnet.cz>
To: =?utf-8?B?UmFkZWsgS3JlasSNw60=?= <rkrejci@cesnet.cz>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/EjDwpS1pzQ7Jsd43qG7W7ntYySU>
Subject: Re: [yang-doctors] Yangdoctors early review of draft-ietf-babel-yang-model-03
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, 16 Oct 2019 18:30:41 -0000

[Trimming it down to open issues]

>>> 
>>> - the text "The value MUST be one of those listed in
>>> 'metric-comp-algorithm'." in description just duplicates the type's
>>> information (identityref with metric-comp-algorithms base).
>> How about if it says “The value MUST be one of those listed in ‘metric-comp-algorithm’ typedef.”?
> 
> I see no such typedef in the module (neither in the information model). This is probably again a confusion between information model and yang model. If it refers to information model, I don't think it is a good idea, but it should be at least explicitly stated. If it refers to the leaf's base identity, I don't think that it is necessary to duplicate this information (but I'm not strongly against it, it just make me believe that actually it is some additional restriction to the type itself), because there is already:
> 
> type identityref {
>   base metric-comp-algorithms;
> }
> 
> which also says that the value MUST be one of the identities based on metric-comp-algorithms. And technically, such identities can be added so the possible values do not need to be listed in some text/list/typedef. If you really want to limit the values to some static list, the type should be actually enumeration.

How about we say just that, i.e. “The value MUST be one of the identities based on metric-comp-algorithm”?

> 
>>> - babel/interfaces/stats/reset
>>> - I'm confused, is it per-interface reset (as placed in the module) or
>>> system-wide interfaces stats reset (as information model defines it?). If it
>>> is the system-wide reset, why tha action cannot be placed in babel container?
>> The action statement defines an operation connected to a specific container. What would it mean to have an action statement on the whole babel container? Reset everything?
> 
> but that is what the information model says, right? System-wide reset of the stats.Or is the meaning different?
> 
>> Even though the information model calls for a system-wide reset of stats, the model defines it at a per-interface level. It can be called recursively for every interface instance to realize a system-wide reset of stats.
> 
> that's what I miss in the action description. There is what the reset is supposed to do by information model (system-wide reset) and that in YANG the reset action has to be placed where the action needs to be performed. So according to the description, the reset is in a wrong container because to perform system-wide reset, it probably don't need to be performed in a specific interface, right? There is no word about intention to change what the reset is supposed to do (reset of stats for the specific interface).

Ok. How about this text?

              The information model [RFC ZZZZ] defines reset
               action as a system-wide reset of Babel statistics.
               In YANG the reset action is associated with
               container where the action is defined. In this case
               the action is associated with the interfaces
               container, so the action will reset statistics at an
               interface level. 

               Implementations that want to support a system-wide
               reset of Babel statistics need to call this action
               for every instance of the interface.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com