Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis
Andy Bierman <andy@yumaworks.com> Thu, 29 February 2024 03:17 UTC
Return-Path: <andy@yumaworks.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 4CC8EC15106B for <netmod@ietfa.amsl.com>; Wed, 28 Feb 2024 19:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6euSWPfLkEcE for <netmod@ietfa.amsl.com>; Wed, 28 Feb 2024 19:17:44 -0800 (PST)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D92CC151066 for <netmod@ietf.org>; Wed, 28 Feb 2024 19:17:44 -0800 (PST)
Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-299d3b09342so277784a91.2 for <netmod@ietf.org>; Wed, 28 Feb 2024 19:17:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1709176663; x=1709781463; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SKVlDrfZGH0jCQDvLebGGS9Q2eDzQwhRRb6qr4PP0Nk=; b=hznFvJXQ5rNo+gfWskxAig/UX9ldct1HKOq2sUkhJAJGYB2DR64iTmIBgjMdfd6JlF hsmapkOYvula0jkdfSF7kEQPPbx2SZYN8QPgbrTMyBt/+LX9ir3NI/0IL/4lypcPqT7N nOrtdjo4oFBvbVfeODLe9/aARDVFPYlySZ0/hmGoRTyi2qmU6DkgFMWY4o+BwqJMb66k G0DztfWEbPuIoR96DqOM8uiJKCVK0FadFEUTeH4pkanYJ3S0brsbmXzaygIoBONI5jUN 7sBAqEa3PG9saf89M2okRzkwHAnSgN4HcAdejuYNfqFk7a4J0A1Gm23E+6EmHcsbRiAV El0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709176663; x=1709781463; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SKVlDrfZGH0jCQDvLebGGS9Q2eDzQwhRRb6qr4PP0Nk=; b=Ulszhys9dniOM2RxNa1RBj4JBIiUxA6sq5PLqHuw+rAC6DznUrE/Up80z9KL1cVOQs BYTKu4r+SDYkYpy+VJhW7HbFY2+7wY6XBmSWDW1NoB3dqLi4gg/eFNc5xQdpuYrFSNDh gT9Zle0L7KF5Aw5xxf8Kp5SDkJptsuN891OHXJZnoqRO/2EJsXacROpgLcwtcdkKK7+t Q22aJa7MpXMsrp6urfNaWxUz5yBXCII1SAJC2Sss1c/umA1jfMCB4Ig/NSwQXXhIwrZ/ pyL9IviyWfXaPlOUrkuL/LgUj5eA+IhABRceZtuzfJ80y6+WJkILRrja3Oo1vKeJQ1GA BTGw==
X-Forwarded-Encrypted: i=1; AJvYcCUjqmuA4K5YsKkJhb5L3BfBarqY2OeFybExNJhmlXKBwStOgGvvnlRKGj0eMkLhwx2mTwOA4jWrXggCQpzdVsk=
X-Gm-Message-State: AOJu0YxWC58elT8Bls9J3XSyzTyNoKQ+CaC2GPlMvHvZxxMNBFrt6yLs KFd2SrlgO/ivSY3ChvFhLcqahr2Jn6hfC6HMkLXr7VBFTFOd6P3efncuzr6VSFW54/8sWOquoUT rli58NYzHvSyf4RaDi0JHHErzSXy2LJwKnbk2tDlPYGiYbf26
X-Google-Smtp-Source: AGHT+IHKMPwtJHiMOz1Qu/AAH2JDGSSlgkCsUN5po0HCSAisP1/hFyREG1I7JXW2l06rKzX057hFQ4079yyC+t11kjI=
X-Received: by 2002:a17:90b:883:b0:29a:da46:8d27 with SMTP id bj3-20020a17090b088300b0029ada468d27mr1268068pjb.0.1709176663016; Wed, 28 Feb 2024 19:17:43 -0800 (PST)
MIME-Version: 1.0
References: <7c4a1c855e51420f92e763bcefcd0221@huawei.com>
In-Reply-To: <7c4a1c855e51420f92e763bcefcd0221@huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 28 Feb 2024 19:17:31 -0800
Message-ID: <CABCOCHTNhAfSyONGv=PHPYy86vhcZesgRnc7=MSjqVrNMa9fsA@mail.gmail.com>
To: Qin Wu <bill.wu=40huawei.com@dmarc.ietf.org>
Cc: Jan Lindblad <janl@tail-f.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dba5a706127cb3b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-bwABJCodvyGeSRQaqRR_2ntUA8>
Subject: Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 29 Feb 2024 03:17:48 -0000
On Wed, Feb 28, 2024 at 6:30 PM Qin Wu <bill.wu=40huawei.com@dmarc.ietf.org> wrote: > + In section 4.2 about choice of prefixes, it is said that "Prefix values > SHOULD be short but are also likely to be unique." I used to say the same > thing. In recent years, however, I have started to stress the importance of > uniqueness much more. I'd say something like "Prefix values SHOULD be > selected carefully to be unique, and ideally not too long." > > > > *[Qin Wu] Fair statement, there is tradeoff between uniqueness of the > prefix and prefix length. Sometimes these two factor contradict to each > other.* > > The reason for my change is I have met several engineers who have been > deeply confused (to the point of costing real money) when the same prefix > has shown up in multiple places. It's just an unnecessary part of the > learning curve associated with YANG. > > > > > > In fact, I have started to recommend people to set the prefix to equal the > module name. This also solves another problem, which is that the "prefixes" > you see in RESTCONF are module names, and the confusion of what to use > where is sometimes suffocating. I understand if many think I'm going > overboard here, but when we pretend that modules don't have prefixes, only > module names, there is a lot less friction in learning the ropes. > > > > *[Qin Wu]:There are two challenges I see here:* > > *a. **sometimes the module name length is too long, which will make > prefix long as well.* > > *b. **Prefix definition rule for JSON is different from Prefix > definition rule for XML, see section 5 of RFC7951:* > > o namespace-qualified - the data node identifier is prefixed with > > the name of the module in which the data node is defined, > > separated from the data node identifier by the colon character > > (":"). > > *I remember there is on relevant discussion on mailing list:* > > *https://mailarchive.ietf.org/arch/msg/netmod/DmvrWxlm3RGgTnPGPiE2hM_TpR8/ > <https://mailarchive.ietf.org/arch/msg/netmod/DmvrWxlm3RGgTnPGPiE2hM_TpR8/>* > > > > + In section 4.11.5 regarding booleans, it is said that booleans can take > values true and false. This is true in mathematics :-) but in YANG a > boolean leaf can additionally take the "value" of "not set". Actually, "not > set" is a possibility for leafs in general, unless it is declared mandatory > true, or has a default. In my experience, one of the most common YANG > modeling issues is when people model a leaf foo, which isn't mandatory, has > no default and the description statement does not say what happens if the > leaf is not set. In many cases, there is a sort of natural meaning, but > with booleans leafs in particular, the absence of the leaf is typically > highly ambiguous. I think this hole merits a recommendation clause in the > I-D. > > > A missing leaf with no default means there is no instance in the data tree. This impacts XPath evaluation and leafref / instance-identifier validation. I think the RFC is clear on how to handle an empty node-set. Andy *[Qin Wu] Interesting, it seems you are talking about Qutrit Entanglement > in quantum communication. Yes, I agree this worth adding guidance. What is > your recommendation? Allow three states or add default in the description > statement?* > > Best Regards, > > /jan > > > > > > > > On 28 Feb 2024, at 10:51, mohamed.boucadair@orange.com wrote: > > > > Hi all, > > I think that this version is ready for the WGLC. > > The document fully covers the items promised when requesting adoption [1]. > As listed in the ACK section, we also solicited and integrated feedback > from many yangdoctors, solicited SAAG WG to review the security text, etc. > Refer to 1.1 for a comprehensive list of the changes. > > Cheers, > Med > > [1] Slide#7 of > https://datatracker.ietf.org/meeting/117/materials/slides-117-netmod-7-guidelines-for-authors-and-reviewers-of-documents-containing-yang-data-models-00 > > > -----Message d'origine----- > De : I-D-Announce <i-d-announce-bounces@ietf.org> De la part de > internet-drafts@ietf.org > Envoyé : mercredi 28 février 2024 10:01 > À : i-d-announce@ietf.org > Cc : netmod@ietf.org > Objet : I-D Action: draft-ietf-netmod-rfc8407bis-09.txt > > Internet-Draft draft-ietf-netmod-rfc8407bis-09.txt is now available. > It is a work item of the Network Modeling (NETMOD) WG of the IETF. > > Title: Guidelines for Authors and Reviewers of Documents > Containing YANG Data Models > Authors: Andy Bierman > Mohamed Boucadair > Qin Wu > Name: draft-ietf-netmod-rfc8407bis-09.txt > Pages: 84 > Dates: 2024-02-28 > > Abstract: > > This memo provides guidelines for authors and reviewers of > specifications containing YANG modules, including IANA-maintained > modules. Recommendations and procedures are defined, which are > intended to increase interoperability and usability of Network > Configuration Protocol (NETCONF) and RESTCONF protocol > implementations that utilize YANG modules. This document obsoletes > RFC 8407. > > Also, this document updates RFC 8126 by providing additional > guidelines for writing the IANA considerations for RFCs that > specify > IANA-maintained modules. > > The IETF datatracker status page for this Internet-Draft is: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod- > rfc8407bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C51672231 > 30c943a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 638447076716455966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s5VX9Hb%2Fl > P9v5QurysF69syyEyba9yYss7xd7K5E2FE%3D&reserved=0 > > There is also an HTML version available at: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis- > 09.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943 > a5a4c608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638447 > 076716464395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Br3nHahSq8OV24f > hFxBkJaqY43Q0GUxcbPZSFhji4uk%3D&reserved=0 > > A diff from the previous version is available at: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis- > 09&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C5167223130c943a5a4c > 608dc383bce6b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63844707671 > 6470644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zo%2FrtFJrYJkJXOceIpzR > mlGAQF2c8m9Z%2F0vShl5o8gQ%3D&reserved=0 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > > > ____________________________________________________________________________________________________________ > 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. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… Qin Wu
- [netmod] I-D Action: draft-ietf-netmod-rfc8407bis… internet-drafts
- [netmod] Next steps for draft-ietf-netmod-rfc8407… mohamed.boucadair
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… Jan Lindblad
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… Kent Watsen
- [netmod] Long trees RE: Next steps for draft-ietf… mohamed.boucadair
- Re: [netmod] Long trees RE: Next steps for draft-… Andy Bierman
- Re: [netmod] Long trees RE: Next steps for draft-… Mahesh Jethanandani
- Re: [netmod] Long trees RE: Next steps for draft-… Qin Wu
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… Andy Bierman
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… Christian Hopps
- Re: [netmod] Long trees RE: Next steps for draft-… mohamed.boucadair
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… Kent Watsen
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… mohamed.boucadair
- [netmod] On prefixes RE: Next steps for draft-iet… mohamed.boucadair
- Re: [netmod] Long trees RE: Next steps for draft-… Italo Busi
- Re: [netmod] On prefixes RE: Next steps for draft… Randy Presuhn
- Re: [netmod] On prefixes RE: Next steps for draft… Jürgen Schönwälder
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… maqiufang (A)
- Re: [netmod] Next steps for draft-ietf-netmod-rfc… mohamed.boucadair
- Re: [netmod] Long trees RE: Next steps for draft-… Kent Watsen
- Re: [netmod] Long trees RE: Next steps for draft-… mohamed.boucadair
- Re: [netmod] On prefixes RE: Next steps for draft… mohamed.boucadair
- Re: [netmod] On prefixes RE: Next steps for draft… Jürgen Schönwälder
- Re: [netmod] On prefixes RE: Next steps for draft… Per Andersson (perander)
- Re: [netmod] Long trees RE: Next steps for draft-… Kent Watsen
- Re: [netmod] Long trees RE: Next steps for draft-… Italo Busi
- Re: [netmod] On prefixes RE: Next steps for draft… Andy Bierman
- Re: [netmod] Long trees RE: Next steps for draft-… Kent Watsen
- Re: [netmod] Long trees RE: Next steps for draft-… Andy Bierman
- Re: [netmod] Long trees RE: Next steps for draft-… Xufeng Liu
- Re: [netmod] Long trees RE: Next steps for draft-… mohamed.boucadair
- Re: [netmod] On prefixes RE: Next steps for draft… Jan Lindblad
- Re: [netmod] On prefixes RE: Next steps for draft… Andy Bierman
- Re: [netmod] On prefixes RE: Next steps for draft… Per Andersson (perander)
- Re: [netmod] On prefixes RE: Next steps for draft… Andy Bierman