IETF Logo Mail Archive

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 17 January 2018 17:36 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E5C1314BD for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 09:36:10 -0800 (PST)
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_PASS=-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=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 XxxPBznXbSOa for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 09:36:09 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 4E6E212E04A for <netmod@ietf.org>; Wed, 17 Jan 2018 09:36:00 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id j3so11924516pfh.8 for <netmod@ietf.org>; Wed, 17 Jan 2018 09:36:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=aB+Y+xDHF0tPcOm53X2ktKglkPQ37Pa3EPkFkJ9BH+8=; b=N7R9Mq0er5Uo+DBTUGDAhLJ7KG4YNgyMNoDNJonqWHPS34RjhfT06qS+Tx4P7W48xE 7gmvV4NPBKedlpHY40WYR100WrsVnvfR4nrwv2qGJY4i2ZvNRy3k91Sy6//IAEJ0tNs0 vADQfIRiLzZ3nhZkCVTfk4NcIDsFXxQWvmOCgsrsbPDh+cczJBd2zb/qOkCiG7eQzfco ZuJJGGSp7PiQfTEKINe4NL6kVFfGGbYJ23vUnUCQ3/NSrRN8oVA6iZE9WKYpObD+etLP UD7dLSzfpyswpDuma9UQovFaubYvxflTyF3ivQ+TOaCGjZIaX/ReWHk5Saxy8sOUTwRK kJdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=aB+Y+xDHF0tPcOm53X2ktKglkPQ37Pa3EPkFkJ9BH+8=; b=pNvHMJJjNcXoBG7eBKufVRhdm/WNsoQNLQ/NBfK4z4lXNDcqeKTHNf1beq6Uv0PkBe dsG10QcWQCvoGZg7VGjd3buC0FeM8d7b6FpctHuCEUhvYvwJSEeOG/DhV3Sp3OsM9aM1 YnhFk2bAeBvK//a20zybyhnCdkIEwAaRLsI84YWqTFGrrzMpPFlsl9z3MROge+mhwcoD 88GtsA3rtV2UR2ncjTrs3hc91nojKOI17ckDkahJrwTgc/1o9Q5nR5IfJu/ZcwC87XFC j7G9ESGpMKdwAoRyUT46bxEnlGruYhN8cV/8MS9Rmnj/fqoJPZWeZGB55a9EPWWzhBJO vb9w==
X-Gm-Message-State: AKwxytdwpqa6Jft2JzRhC00VSPwWIHZdX26S8L5Nz02hdd6VGjPqWSX0 hsp/ZEc53Oyy6A65Z7cA7KQ=
X-Google-Smtp-Source: ACJfBosOZDqWDQhIpTga6zLSCap1gaq2hmGhyV+p7e4pTvy6fpO3Dv30GsHyswlP6txobHk3lhoKMA==
X-Received: by 10.98.198.2 with SMTP id m2mr13651557pfg.113.1516210558277; Wed, 17 Jan 2018 09:35:58 -0800 (PST)
Received: from [192.168.1.25] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id v186sm8801997pfb.5.2018.01.17.09.35.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 09:35:57 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 17 Jan 2018 09:35:57 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>, vladimir@transpacket.com
CC: netmod@ietf.org
Message-ID: <4544C128-E82E-4D9C-9EF1-BD799C8A6AEB@gmail.com>
Thread-Topic: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
References: <aa7a1449-fd6e-e4c6-7568-41061c09d9f2@transpacket.com> <20180116.115606.561861432247288407.mbj@tail-f.com> <e94d1ed3-e859-3167-501f-ce23e77804df@transpacket.com> <20180116.164053.2123534827829006518.mbj@tail-f.com>
In-Reply-To: <20180116.164053.2123534827829006518.mbj@tail-f.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6v_zg5w3Gn_snFa9RC7BGnqhZ2c>
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2018 17:36:11 -0000

+1 to 2

Cheers,
Jeff

On 1/16/18, 07:41, "netmod on behalf of Martin Bjorklund" <netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:

    Vladimir Vassilev <vladimir@transpacket.com> wrote:
    > On 01/16/2018 11:56 AM, Martin Bjorklund wrote:
    > 
    > > Vladimir Vassilev <vladimir@transpacket.com> wrote:
    
    [...]
    
    > >> There is also undocumented alignment space count function before
    > >> <type> that pyang uses to align the <type> fields of child data leafs
    > >> with common ancestor. If this is specified in the draft the tree
    > >> output can be deterministic and for me this is an advantage. This is
    > >> currently one of the few underspecified pieces of the tree format so I
    > >> had to check pyang implementation in oder to generate same alignment
    > >> space counts and binary identical tree output results.
    > > I think that we at least should write that there may be more than one
    > > space between <opts> and <type>:
    > >
    > >    There may be any number of additional space characters between
    > >    <opts> and <type>.
    > For the sake of the argument (at least having this on the mailing list
    > as reference):
    > 
    >   <type> should be aligned at a common offset for all sibling nodes
    >   from the start of <name> by adding trailing spaces. The recommended
    >   offset is 3 plus the length of the longest node name among all
    > sibling nodes
    >   including those siblings defined under choice and case nodes.
    > 
    > This is what pyang does now. It is not a perfect solution but it
    > allows identical output down to the bit.
    
    Does anyone else have an opinion on this?  I can see three
    alternatives:
    
      1) allow any number of addtional spaces
      2) allow any number of addtional spaces + define a suggested
         alignment algorithm
      3) mandate the alignment algorithm
    
    
    /martin
    
    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod

v2.23.0 | Report a Bug | By Email