Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
Kent Watsen <kent+ietf@watsen.net> Wed, 18 March 2020 20:07 UTC
Return-Path: <01000170ef41c649-255d0811-a030-4b60-9d1f-a06d39f4ebf8-000000@amazonses.watsen.net>
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 33C0F3A1BB6 for <netmod@ietfa.amsl.com>; Wed, 18 Mar 2020 13:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 2PxubUuJtU7R for <netmod@ietfa.amsl.com>; Wed, 18 Mar 2020 13:07:21 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81593A1B97 for <netmod@ietf.org>; Wed, 18 Mar 2020 13:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1584562030; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=//ULgho3Z7Zl/gbJbqREGpMkmZaOmbG+bABKUtXlG58=; b=NXEAxFBdacGwqBgtp0DGPFx7vOey9P6XTm18KgCOW28rd/wVVLVeZpT9Aypon2CM nIJfhlb0XSNLA9Po67Hl88FLG71KT9wW6ZeIY70oyd1GStVKvCNdi0eZk3ShVu6dgGC GsDkx9rhJRMhwN1c6bkeyd30P5vE5H74r3OuJlgE=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <01000170eb9368e1-3f3186d5-9792-492a-8a33-4bb589552b6d-000000@email.amazonses.com>
Date: Wed, 18 Mar 2020 20:07:10 +0000
Cc: "netmod@ietf.org" <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000170ef41c649-255d0811-a030-4b60-9d1f-a06d39f4ebf8-000000@email.amazonses.com>
References: <DB7PR07MB4011402E836C2FABCB3E7F42F0150@DB7PR07MB4011.eurprd07.prod.outlook.com> <0100017045205157-ba7a6e8f-0d4d-4540-b6ca-94d4d81dbe02-000000@email.amazonses.com> <DB7PR07MB40119ED41717889CFACC08F4F0E30@DB7PR07MB4011.eurprd07.prod.outlook.com> <01000170eb9368e1-3f3186d5-9792-492a-8a33-4bb589552b6d-000000@email.amazonses.com>
To: Balázs Lengyel <balazs.lengyel@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.03.18-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/s6bZCYiAUE9_fXteanZsaEgFUxg>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Mar 2020 20:07:34 -0000
One more thing, for non-mandatory nodes that don’t have a default value specified, please ensure the “description” statement states what it means for the node to be set or not set (whichever is easier)? For instance: OLD: leaf name { type string; description "Name of the YANG instance data set."; } NEW (assuming this makes sense): leaf name { type string; description “An arbitrary name for the YANG instance data set. This value is primarily used for descriptive purposes. However, when the instance data set is saved to a file, then the filename MUST encode the name’s value, per Section 3 of RFC XXXX."; } BTW, should the requirement of it needing to be encoded into the filename place constraints on the “string” type? Should a “pattern” statement be added? Kent > On Mar 17, 2020, at 10:57 PM, Kent Watsen <kent+ietf@watsen.net> wrote: > > > Hi Balazs, > > >> Have the YANG modules been validated and tested for formatting? >> >> (i.e., pyang -f yang --keep-comments --yang-line-length 69 filename) >> >> BALAZS: yes. With pyang offline and yangvalidator.com > > Okay. > > >> Have the examples in the draft validated against the YANG module? >> >> BALAZS: Only manually. How do you validate samples conforming to a yang data structure ? > > Hmmm, seeing that the examples are still not valid, here goes: > > Until such time as tools support validating structure-data-ext, > one can rewrite the YANG module via s/sx:structure/container/ > and perform the validation against the resulting YANG module. > > >> Please review the Normative/Informative status of the references. >> >> Not looking carefully, but RFCs 2119 and 8174 should be Normative, >> >> and I think RFCs 3688 and 6020 should be Informative, right? >> >> BALAZS: OK, changed in rev 08 > > Did you check all the other references too? (I’m trying to save having to do another roundtrip when I do the shepherd writeup...) > > >> All of the “import” statements in the YANG module are missing a >> >> “reference” statement. >> >> BALAZS: >> >> Added: >> >> rfc6991 for types added. >> >> Already present: >> >> rfc8342 for datastores >> >> ietf-netmod-yang-data-ext for ietf-yang-structure-ext > > Again, all the “import” statements in the YANG module are missing a “reference” statement. > > >> Please add a paragraph to Section 5.2 preceding the YANG module >> >> indicating all the aforementioned Normative references. >> >> BALAZS: OK, I did it, but >> >> this is not what is required by https://tools.ietf.org/html/rfc8407#section-3.9. >> >> I also see no value in this statement. > > I the "reference” statements mentioned above had been added, then s3.9 applies. > > >> The copyright in the YANG module needs to be 2020 (not 2019) >> >> BALAZS: OK >> >> >> >> Please ensure a blank line between paragraphs in the “description" >> >> statements. >> >> BALAZS: OK >> >> >> >> Please add a statement to the Introduction regarding why the module >> >> Isn’t compliant with NMDA. >> >> BALAZS: Sorry, don’t understand. Why is this not compliant with NMDA ? >> >> IMHO it is NMDA compliant, or rather it has nothing to do with NDMA. > > Either way but, per https://tools.ietf.org/html/rfc8407#section-3.5, the > statement should be in the Introduction section. > > >> The tree diagram does not adhere to the syntax described in >> >> draft-ietf-netmod-yang-data-ext. >> >> BALAZS: OK I try, but what actually is the problem? Any help would be really appreciated. > > I was looking at the “+—rw”, which can’t be right because yang-data is not “configuration”... > > >> Sadly >> >> pyang -p ../ietfYams ietf-yang-instance-data\@2020-03-06.yang -f tree --tree-print-yang-data --tree-print-yang-data >> >> doesn’t print out anything, so I am handcrafting. > > `pyang` supports the old/RFC8040 “rc:yang-data” statement; it hasn’t been updated to support the new "sx:structure” statement. > > >> I just updated pyang from git. Any idea why this doesn’t work for me? >> >> It would be good if YangValidator would print out the tree. At some point it did. Not now. :-( > > First, use the s/sx:structure/container/ trick mentioned above. > > Then s/+--rw/+—/. > > Then review https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-05#section-3 and tweak accordingly until all is good. > > >> Please update the first sentence in Section 5.1 to also reference draft-ietf-netmod-yang-data-ext. >> >> BALZS: OK >> >> >> >> Please ensure that the planning-text version of the draft passes >> >> IDNITS (https://www6.ietf.org/tools/idnits) at the “verbose output” >> >> level and correct any issues found, or explain why they shouldn’t >> >> be corrected. >> >> BALAZS: OK, corrected > > Thanks! (this is almost always the cause for needing another draft update when doing the shepherd writeup) > > > > NEW: looking at the new "format-version”, please add a pattern statement to constrain the string values appropriately. Hint, it’s half a "date-and-time” type... > > > > Kent // contributor (and shepherd) > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Balázs Lengyel
- Re: [netmod] WG Last Call: draft-ietf-netmod-yang… Kent Watsen