From nobody Thu Apr 1 12:31:33 2021 Return-Path: <010001788eeb4950-2a07f143-c1fc-4b3b-826b-285751fdf609-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 E9ADA3A203D for ; Thu, 1 Apr 2021 12:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 GdD3y4tnS2-O for ; Thu, 1 Apr 2021 12:31:29 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD713A2039 for ; Thu, 1 Apr 2021 12:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617305487; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=HPS4nzwahu/Jdlfl4M4cBQiP0eOGgH9JKAZRA8xxlRQ=; b=b2q/JMO5XK9oVjEWgGuibd3OxCvsZmHIP1qheOESZvEI6J8xOSllgzWbDuTSG8In s3XG81xLqL4TXyyKAZtQgQGrgYancxgdwyEXy4bRRb8CK7015dMhbRTxoXkhOLdIlLl UzlZkVxKbcLKLOL0UKLtIbx4CvPRHWkUAwJbj8bo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Kent Watsen In-Reply-To: Date: Thu, 1 Apr 2021 19:31:27 +0000 Cc: =?utf-8?Q?Oscar_Gonz=C3=A1lez_de_Dios?= , "Aseem Choudhary (asechoud)" , Juergen Schoenwaelder , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001788eeb4950-2a07f143-c1fc-4b3b-826b-285751fdf609-000000@email.amazonses.com> References: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> <327D2A1F-A646-42C9-BEE7-0A3EA73D537E@cisco.com> <20210317155834.nz6cv4mefwxrjgmq@anna.jacobs.jacobs-university.de> <4BBA1D6B-F2CC-4099-A640-88F003327529@cisco.com> To: tom petch X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.01-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 19:31:31 -0000 > The chairs can guide you on procedure but it is the WG members, you, = me and everyone else who have to do the work and so declare their = willingness, or not, to take up the work which the chairs then use to = decide whether or not the work should happen in the WG. Thank you Tom for mentioning that, and Juergen for helping to understand = the request. Hi Oscar and Aseem, you=E2=80=99ve already received some good feedback. = The =E2=80=9Cdeclaration of willingness=E2=80=9D that Tom alludes to is = formalized by the chairs initiating an =E2=80=9Cadoption call=E2=80=9D = to the working group on an Internet Draft (I-D) document. The I-D is a = proposal for what the authors would hope to be published as an RFC, and = is typically presented to the WG in one or more of its regular meetings = occurring three times a year. Of course you may continue to solicit = feedback and interest here on the list in the interim. Cheers, Kent // a NETMOD co-chair From nobody Thu Apr 1 17:19:39 2021 Return-Path: <010001788ff302da-dcb9dc37-8e63-4ba1-9f82-5584e0e4f49a-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 E086F3A2956 for ; Thu, 1 Apr 2021 17:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Yk4OJhn3LLlw for ; Thu, 1 Apr 2021 17:19:32 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A713A2954 for ; Thu, 1 Apr 2021 17:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617322771; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=qkdOOi+fn0dK9v6Oq8kT/Bgipb8f0UAMVejUSWe5E20=; b=gKf3TIV7Am6FdkbWOne7kUB9I7AZrjc66eErrqBdxDE+ScPJLhVbbrdVnHd+dQbL nV+3zmAEmJbujhOI+4qHN+m9YW4m4nyDG9OFGNvGPkeAtAWkIwzLtNXeTSW9+2l0Fax gHP+baiUdFWAiKGwfpmEBjFjKgJjIAxAVV1Wl86g= From: Kent Watsen Message-ID: <010001788ff302da-dcb9dc37-8e63-4ba1-9f82-5584e0e4f49a-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6C395BFE-1EF2-4941-B3FB-785CC74ECBCD" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 2 Apr 2021 00:19:31 +0000 In-Reply-To: Cc: "netmod@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: <010001712ce4c5fe-04a059c3-ced3-4e6d-8389-5dd7c1257ac2-000000@email.amazonses.com> <010001712e483a1b-204d92e3-7046-46fb-b6b8-13d8ad4cb9ff-000000@email.amazonses.com> <0100017160917518-a18954f3-8e57-4286-904a-5a3e9779ff31-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 00:19:38 -0000 --Apple-Mail=_6C395BFE-1EF2-4941-B3FB-785CC74ECBCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [CC-ing NETMOD] Hi Balazs, Please see below for responses. (One question pending) I just got back from PTO. Thanks for posting -13 anyways. Kent // shepherd > On Mar 23, 2021, at 6:01 PM, Bal=C3=A1zs Lengyel = wrote: >=20 > Hello Kent, > I am resuming my work on draft-ietf-netmod-yang-instance-file-format.=20= > I removed already agreed items from this mail and provided answers as = BALAZS3 below. > Are you OK with my answers, corrections? What is the next step = forward? > =20 > I updated the draft to -13, but did not upload it yet.=20 > Regards Balazs > =20 > =20 > From: Kent Watsen >=20= > Sent: 2020. =C3=A1prilis 9., cs=C3=BCt=C3=B6rt=C3=B6k 22:11 > To: Bal=C3=A1zs Lengyel > > Cc: netmod@ietf.org > Subject: Re: [netmod] Shepherd review on = draft-ietf-netmod-yang-instance-file-format-10 > =20 > Hi Balazs, > =20 >=20 >=20 > On Apr 8, 2020, at 8:06 AM, Bal=C3=A1zs Lengyel = > = wrote: > =20 > Hello Kent, > Thanks for the review. See answers below. > I tried to address all you comments, sorry if I missed something.=20 > I updated the draft and uploaded a -11 version. Please check/advance = it. >=20 > One question I could not settle: XML2RFC does not accept > = =20 > Only > =20 > Why ? Please help. > =20 > Because it=E2=80=99s a working group document now and so uses the = =E2=80=9Cietf=E2=80=9D prefix. Try this: > =20 > =20 > =20 > BALAZS3: OK >=20 > Structural Issues: >=20 > - S5 contains an mix of important and unimportant information. I = think that the most important thing to state that the module defines an = offline format that MAY contain security sensitive information, and thus = safe handling is advised. Maybe also say something about because the = YANG module only defines a =E2=80=9Cstructure=E2=80=9D, the Security = Considerations doesn=E2=80=99t follow the template specified in = https://tools.ietf.org/html/rfc8407#section-3.7.1 = ). For instance: = s/is designed as a wrapper specifying a format and a metadata header for = YANG instance data defined by the content-schema/specifies an offline = format/ > BALAZS: Most of text was required to be put there by earlier reviewers = (Mostly Juergen and Acee Lindem) and sent to the mailing list. > I added that we do not follow the security template for YANG models. > =20 > Please add the reference to = https://tools.ietf.org/html/rfc8407#section-3.7.1 = per above. > =20 > BALAZS3: OK Thanks but, FWIW, this change must=E2=80=99ve been made before -13 since = it doesn=E2=80=99t show up in the 12-to-13 diff. > - S8.1: agreed that RFC8525 is Normative, but the only place it it = referenced is in a non-normative section=E2=80=A6please add a ref to it = from a normative section. > BALAZS: It is referenced from the YANG module which is normative. > =20 > You just added that reference, but not correctly: > 1) the =E2=80=9Creference=E2=80=9D doesn=E2=80=99t follow the = standard format > 2) the paragraph at the top of 3.2 doesn=E2=80=99t also list RFC = 8525 > =20 > BALAZS3: ??? Thanks, I see the reference to RFC 8525 in Section 3.2 now. [Also = must=E2=80=99ve been added before -13] >=20 > Editorial Issues: >=20 > - Appendix B: > - s/For instance data/Instance data/ > BALAZS: Sorry, that would make the sentence incorrect. > =20 > Do you mean it to be =E2=80=9CFor instance, data=E2=80=9D then? If = =E2=80=9Cinstance data=E2=80=9D is supposed to be read together, maybe = use a hyphen or quotes? >=20 > BALAZS3: OK, changed=20 Thanks, I see s/For/In case of/, which resolves the ambiguity. > On Mar 30, 2020, at 3:22 PM, Kent Watsen > wrote: >=20 > As part of the Shepherd writeup, I read the entire draft and found the = following issues, which I=E2=80=99d like to see resolved before = progressing the document. Most of these issues should have been caught = be the WG and/or Editors... >=20 > =20 > - In S3, P8: =E2=80=9Cthe semicolons and the decimal point, if = present, shall be replaced by underscores=E2=80=9D - why are they not = escaped? > BALAZS: This is a file name. Escaping in file names does not always = work (depending on the filesystem and tools used). This is more simple = and understandable > No, this is a special case CLR and we never do this. I see this idea = has been in the document since -03, so it must=E2=80=99ve been = discussed, can you point me to the discussion?=20 > =20 > FWIW, my OS doesn=E2=80=99t even require escaping colons. BTW, = they=E2=80=99re =E2=80=9Ccolons=E2=80=9D (not semicolons). > BALAZS2: Windows doesn=E2=80=99t allow colons in the filename. = Although it=E2=80=99s not everyone=E2=80=99s favorite OS, it is pretty = widespread.=20 > =20 > Understood, but that doesn=E2=80=99t explain why escapes can=E2=80=99t = work. Please explain. > =20 > BALAZS3: To my best knowledge, colon is never accepted in any form in = windows filenames and cannot be escaped. = https://superuser.com/questions/461320/get-a-colon-in-a-windows-filename = = > I removed the decimal point as that works on windows and Linux. >=20 > For Ubuntu Linux and a bash shell the colon is allowed, but tab = extension does not work properly. > =20 > On Bash: > $ touch a:b > $ ls a ---> replaces =E2=80=9Ca=E2=80=9D with "a\:b=E2=80=9D = > a:b > =20 > Seems regular to me=E2=80=A6what=E2=80=99s the problem? > BALAZS3: On another version of Ubuntu tab extension did not work for = me. Thank you for providing the link explaining why colons cannot be escaped = on Windows. Personal opinion: the underscore usage seems user-unfriendly. I almost = seems better if the colons were simply removed. The "silver lining=E2=80=9D= is that, presumably, the form using =E2=80=9Ctimestamps=E2=80=9D will = be rare, and even more-so when =E2=80=9Csemver=E2=80=9D names become the = norm. BTW, I assume that you wish to publish this as-is and follow-up later = with an update to adjust for the =E2=80=9Csemver=E2=80=9D work - = correct? > - It is unclear how the "inline-content-schema=E2=80=9D feature could = ever be used. I.e., there are no protocol-accessible nodes in the = module=E2=80=A6 > BALAZS: The system can declare in supported/not-supported in design = documentation. E.g. in UC2, Preloading Default Configuration the = designer preparing instance data, can decide to use or not use the = inline-content-schema based on this. > =20 > When I make statements like this, please see it as an opportunity to = improve the document. In this case, please modify the = inline-content-schema=E2=80=99s =E2=80=9Cdescription=E2=80=9D statement = to indicate that the feature is never supported by a server, and that it = is intended to be enabled via out-of-band documentation. BTW, was this = discussed by the WG? > BALAZS3: OK. Added out-of-band documentation. It was discussed and = this was the proposed solution. Some people insisted that this should = be optional. This is the best way to indicate that. Thanks, I see this: [PS: also must=E2=80=99ve been in an update before = -13] description "This feature indicates that inline content-schema option is supported. Support for this feature might be documented only via out-of-band documentation."; > - "leaf-list inline-module" is "min-elements 1=E2=80=9D and = "ordered-by user=E2=80=9D, but "leaf-list module=E2=80=9D has neither = (though it may be that ordering is irrelevant for simple-inline). > BALAZS: ordered-by removed. It doesn't really mean anything. In this = case there is no chance of the system reordering a list a = CLI/Netconf/Restconf client provided. > Min-elements is not needed for simplified-inline as the case will only = be selected if there is at least one "module" leaf-list entry. It is = needed for inline because otherwise the case could contain an " = inline-schema" anydata section and no "inline-module" entries. That = would not be usable. > =20 > That may be true, but it=E2=80=99s equally true for the other = leaf-list. It's inconsistent. =20 > BALAZS3: OK. This is not strictly needed, but it improves = readability. Added min-elements 1 to the other leaf-list.=20 Thanks. =20 > BTW, is "choice content-schema-spec=E2=80=9D meant to be =E2=80=9Cmandat= ory true=E2=80=9D? - because, currently, 'content-schema=E2=80=9D = doesn=E2=80=99t have to be specified according to the model=E2=80=A6 > BALAZS3: It is optional. Section 2.1. Specifying the Content Schema = specifies this. E.g. if you are sending diagnostics data every 10 = seconds with the same filename, it is not needed to include the content = schema every time. Okay. > - The last two sentences of the =E2=80=9Cdescription=E2=80=9D = statement on line 207 in the YANG module contradict each other. > BALAZS: Why ? I don't see the contradiction. If you know a single = datastore specify it. If not omit the leaf. If the leaf is omitted, the = situation is unknown. > =20 > I think the word =E2=80=9Cundefined=E2=80=9D is throwing me. Maybe = =E2=80=9Cunspecified=E2=80=9D would be better? > BALAZS3: OK, use unspecified Thanks. > Structural issues: > =20 > - The list under "Metadata SHOULD include:=E2=80=9D is not indented. > BALAZS: OK, added > =20 > I don=E2=80=99t see it. The way to do it is by adding a fake = =E2=80=9Clist=E2=80=9D, with missing symbols, to put the other list = inside... > =20 > BALAZS3: It is now. Please check Thanks! > - The three examples should be
of their own (e.g., 3.2.x) > BALAZS: OK > =20 > Better, but: > - the new titles don=E2=80=99t match the UC titles > - perhaps remove the =E2=80=9CUCx,=E2=80=9D prefix from the titles? = It looks weird in > the ToC and they're not needed in the title since the first = sentence > relates the example to the UC already... > - BTW, missing word =E2=80=9Cin=E2=80=9D: s/The example illustrates = UC[125] Section 1 > /The example illustrates UC[125] in Section 1/ > =20 > BALAZS3: OK Thanks. > - The =E2=80=9Cinline=E2=80=9D choice node is generally confusing. I = can=E2=80=99t tell if it=E2=80=99s missing container called =E2=80=9Cinlin= e=E2=80=9D or if the two descendant nodes are poorly named. In either = case, it would be best to try to make it more readable. > BALAZS: Yes it is complicated. Some members of Netmod (I think Rob W.) = Asked for a full, powerful, flexible way of documenting the content = schema. In some cases it is needed. > =20 > I=E2=80=99m not saying that it=E2=80=99s purpose is confusing, I=E2=80=99= m saying that its poorly named or missing a parent container. Try = looking at your examples with =E2=80=9Cfresh=E2=80=9D eyes. The node = names "inline-module=E2=80=9D and =E2=80=9Cinline-schema=E2=80=9D are = odd. It seems like =E2=80=9Cinline-module=E2=80=9D could be = =E2=80=9Canydata-schema=E2=80=9D and "inline-schema=E2=80=9D could be = =E2=80=9Cmodule-data=E2=80=9D? > BALAZS3: OK. Added container inline-content-schema Thanks - better. > Editorial issues: > =20 > - s/e.g., UC5 documenting diagnostic data/(e.g., UC5 [Section 2])/ > BALAZS: I prefer to use the short name of the use case instead of the = reference. IMHO it provides information instantly without a look-up. Is = that a problem? > =20 > I think I mentioned this above already, but the titles are wrong. =20 > =20 > Myself, I=E2=80=99d remove all the =E2=80=9CFigure=E2=80=9D = postambles; I never title my figures, just more to have to look at and = maintain. In the case, this is where the UC titles are again = incorrect... > BALAZS3: OK, Figure postambles Removed. Thanks. > - S3.1.1 P2 doesn=E2=80=99t makes sense to me (esp. the verdt ref, = which likely should be removed or better explained) > BALAZS: This was explicitly requested by 2 members of the verdt team. = I tried to amend the text to make it more understandable, however IMHO = we should not try to explain the usage of revision label here. Also this = is just an example. > =20 > OLD:=20 > (e.g., revision labels which can be used as alternative to the = revision > date[I-D.verdt-netmod-yang-module-versioning]).=20 > =20 > NEW: > (e.g., revision labels, described by = [I-D.verdt-netmod-yang-module-versioning] > as alternative to the revision date).=20 > BALAZS3: OK Thanks. > BTW, immediately following, the text says "See Section 2.2.=E2=80=9D = This doesn=E2=80=99t mean > Anything to me. Do you want to say something like =E2=80=9CAn example = of the =E2=80=9Cinline=E2=80=9D method is provided in 2.2.1=E2=80=9D? > BALAZS3: OK. Reference removed, replaced by a reference to an = example. Okay. > - s/is based on "UC1, Documenting Server Capabilities=E2=80=9D/exemplifi= es UC1 [Section 2]/ > BALAZS: Exemplifying is an uncommon word I find ugly. Is the current = text hard to understand or misleading?=20 > I changed it to " The following example illustrates ..." I hope that's = OK. > =20 > I=E2=80=99m unsure if it=E2=80=99s possible for something to be = =E2=80=9Cbased on=E2=80=9D or =E2=80=9Cillustrate=E2=80=9D a use case. = Illustrate is better though, maybe =E2=80=9Creflects=E2=80=9D or = =E2=80=9Cepitomizes"? > BALAZS3: OK, changed to reflects Thanks. > BTW, missing =E2=80=9Cin": s/illustrates UC1 Section 1/illustrates = UC1 in Section 1/ > BALAZS3: OK Thanks. > - s/- Use case 1, Documenting server capabilities/Exemplifying UC1/ > BALAZS: Exemplifying is an uncommon word I find ugly. Is the current = text hard to understand or misleading? =20 > IMHO the string stating the name of the use case is more helpful then = a reference, that needs to be looked up. > I changed it to " The following example illustrates ..." I hope that's = OK. > =20 > Same comment as above. > BALAZS3: OK, changed to reflects Thanks. > - s/is based on "UC2, Preloading Default Configuration=E2=80=9D/exemplif= ies UC2 [Section 2]/ > BALAZS: Exemplifying is an uncommon word I find ugly. Is the current = text hard to understand or misleading? =20 > I changed it to " The following example illustrates ..." I hope that's = OK. > =20 > Same comment as above. > BALAZS3: OK Thanks. > - s/- Use case 2, Preloading access control data/Exemplifying UC2/ > BALAZS: Exemplifying is an uncommon word I find ugly. Is the current = text hard to understand or misleading? =20 > IMHO the string stating the name of the use case is more helpful then = a reference, that needs to be looked up > =20 > Same comment as above. > BALAZS3: OK Thanks. =20 > > - s/is based on UC5 Storing diagnostics data/exemplifies UC5 = [Section 2]/ > BALAZS: OK. but I changed it to: exemplifies UC5, Storing diagnostics = data. IMHO the string stating the name of the use case is more helpful = then a reference, that needs to be looked up. > I changed it to " The following example illustrates "UC2, Preloading = ..." I hope that's OK. > =20 > Same comment as above. > BALAZS3: OK Thanks. =20 > - s/- UC5 Storing diagnostics data/Exemplifying UC5/ > BALAZS: Exemplifying is an uncommon word I find ugly. Is the current = text hard to understand or misleading? =20 > IMHO the string stating the name of the use case is more helpful then = a reference, that needs to be looked up.> > I changed it to " The following example illustrates ..." I hope that's = OK. > =20 > Same comment as above. > BALAZS3: OK Thanks. > - =E2=80=9Cdescription" statement on line 100: s/content schema/schema = (i.e., YANG modules)/? > BALAZS: The term "content-schema" is defined in the terminology = section. It defines =20 > =20 > Fine, but please add "(i.e., YANG modules)=E2=80=9D so people will = have better clue=20 > BALAZS3: OK Thanks. > - =E2=80=9Ctype string=E2=80=9D statement on lines 109 and 131 are = missing a =E2=80=9Cpattern" statement. > BALAZS: OK, Defined it as a typedef. > =20 > Good! But I=E2=80=99m unsure about the pattern statement (esp. = "pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*=E2=80=99;=E2=80=9D)=E2=80=A6did = you copy/paste it from somewhere? > BALAZS3: Copied from rfc6991. It is meant to ensure that an identifier = does not start with the string xml. > typedef yang-identifier { > type string { > length "1..max"; > pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; > pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; > } >=20 Okay. > - P2 in the =E2=80=9Cdescription" statements on lines 220 and 249: = s/For instance data sets/Instance data sets/ > BALAZS: The sentence will not make sense unless I change the comma at = the end of sentence to a colon. > =20 > Hmmm, that didn=E2=80=99t come out very well. This is the same issue = as before, whereby =E2=80=9CFor instance data...=E2=80=9D looks like it = should be read =E2=80=9CFor instance, data=E2=80=A6=E2=80=9D. Maybe you = can find a better way to express this? >=20 > BALAZS3: OK, changed to > In case of 'instance data sets ... Thanks! K. --Apple-Mail=_6C395BFE-1EF2-4941-B3FB-785CC74ECBCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [CC-ing NETMOD]


Hi Balazs,

Please see below for = responses.  (One question pending)

I just got back from PTO.  Thanks = for posting -13 anyways.

Kent // shepherd



On Mar 23, 2021, at 6:01 PM, = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello Kent,
I am resuming my work on = draft-ietf-netmod-yang-instance-file-format. 
I removed already agreed = items from this mail and provided answers as  BALAZS3 below.
Are you OK with my = answers, corrections? What is the next step forward?
 
I updated the draft to = -13, but did not upload it yet. 
Regards Balazs
 
 
From: Kent Watsen <kent+ietf@watsen.net> 
Sent: 2020. =C3=A1prilis 9., = cs=C3=BCt=C3=B6rt=C3=B6k 22:11
To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd = review on draft-ietf-netmod-yang-instance-file-format-10
 
Hi Balazs,
 


On Apr 8, 2020, at 8:06 AM, Bal=C3=A1zs = Lengyel <balazs.lengyel@ericsson.com> wrote:
 
Hello Kent,
Thanks for the review. = See answers below.
I tried to address all you comments, = sorry if I missed something. 
I updated = the draft and uploaded a -11 version. Please check/advance it.

One question I could not settle: XML2RFC does = not accept
     <?rfc = include=3D'reference.I-D.netmod-yang-module-versioning'?> =      
Only
     <?rfc = include=3D'reference.I-D.verdt-netmod-yang-module-versioning'?> =      
Why ? Please help.
 
Because it=E2=80=99s a working group document = now and so uses the =E2=80=9Cietf=E2=80=9D prefix.  Try this:
 
 =    <?rfc = include=3D'reference.I-D.ietf-netmod-yang-module-versioning'?> =  
 
BALAZS3: OK

Structural Issues:

- S5 contains an mix of important and = unimportant information.   I think that the most important = thing to state that the module defines an offline format that MAY = contain security sensitive information, and thus safe handling is = advised.  Maybe also say something about because the YANG module = only defines a =E2=80=9Cstructure=E2=80=9D,  the Security = Considerations doesn=E2=80=99t follow the template specified in https://tools.ietf.org/html/rfc8407#section-3.7.1). =  For instance: s/is designed as a wrapper specifying a format and a = metadata header for YANG instance data defined by the = content-schema/specifies an offline format/
BALAZS: Most = of text was required to be put there by earlier reviewers (Mostly = Juergen and Acee Lindem) and sent to the mailing list.
I = added that we do not follow the security template for YANG models.
 
Please add the reference to https://tools.ietf.org/html/rfc8407#section-3.7.1 per = above.
 
BALAZS3: = OK


Thanks but, FWIW, this change = must=E2=80=99ve been made before -13 since it doesn=E2=80=99t show up in = the 12-to-13 diff.


 - S8.1: agreed that RFC8525 is Normative, = but the only place it it referenced is in a non-normative = section=E2=80=A6please add a ref to it from a normative section.
BALAZS: It is referenced from the YANG module which is = normative.
 
You = just added that reference, but not correctly:
  1) = the =E2=80=9Creference=E2=80=9D doesn=E2=80=99t follow the standard = format
  2) the paragraph at the top of 3.2 = doesn=E2=80=99t also list RFC 8525
 
BALAZS3: = ???

Thanks, I see the reference to RFC 8525 = in Section 3.2 now.  [Also must=E2=80=99ve been added = before -13]


Editorial Issues:
 - Appendix B:
    - = s/For instance data/Instance data/
BALAZS: Sorry, that would = make the sentence incorrect.
 
Do you mean it to be = =E2=80=9CFor instance, data=E2=80=9D then?   If =E2=80=9Cinstance = data=E2=80=9D is supposed to be read together, maybe use a hyphen or = quotes?

BALAZS3: OK, changed 

Thanks, I see = s/For/In case of/, which resolves the ambiguity.



On Mar 30, 2020, at = 3:22 PM, Kent Watsen <kent+ietf@watsen.net> wrote:

As part of the Shepherd writeup, I read the entire draft and = found the following issues, which I=E2=80=99d like to see resolved = before progressing the document.  Most of these issues should have = been caught be the WG and/or Editors...

 
- In S3, P8: =E2=80=9Cthe semicolons = and the decimal point, if present, shall be replaced by underscores=E2=80=9D= - why are they not escaped?
BALAZS: This is a file name. Escaping in file = names does not always work (depending on the filesystem and tools used). = This is more simple and understandable
No, this is a special case CLR and we = never do this.  I see this idea has been in the document since -03, = so it must=E2=80=99ve been discussed, can you point me to the = discussion? 
 
FWIW, my OS doesn=E2=80=99t even require escaping colons. =  BTW, they=E2=80=99re =E2=80=9Ccolons=E2=80=9D (not = semicolons).
BALAZS2: Windows doesn=E2=80=99t allow colons in the = filename. Although it=E2=80=99s not everyone=E2=80=99s favorite OS, it = is pretty widespread. 
 
Understood, but that doesn=E2=80=99t explain why = escapes can=E2=80=99t work.  Please explain.
 
BALAZS3: To my best knowledge, colon is never = accepted in any form in windows filenames and cannot be escaped. https://superuser.com/questions/461320/get-a-colon-in-a-windows= -filename
I removed = the decimal point as that works on windows and Linux.

For = Ubuntu Linux and a bash shell the colon is allowed, but tab extension = does not work properly.
 
On Bash:
  $ touch a:b
  $ ls a<TAB> ---> replaces =E2=80=9Ca=E2=80=9D = with "a\:b=E2=80=9D <RETURN>
  a:b
 
Seems regular to = me=E2=80=A6what=E2=80=99s the problem?
BALAZS3: On another version of Ubuntu tab extension = did not work for = me.


Thank you for providing = the link explaining why colons cannot be escaped on = Windows.

Personal opinion: the = underscore usage seems user-unfriendly.  I almost seems better if = the colons were simply removed.  The "silver lining=E2=80=9D is = that, presumably, the form using =E2=80=9Ctimestamps=E2=80=9D will be = rare, and even more-so when =E2=80=9Csemver=E2=80=9D names become the = norm.

BTW, I assume that you wish to = publish this as-is and follow-up later with an update to adjust for the = =E2=80=9Csemver=E2=80=9D work - correct?


- It is unclear how = the "inline-content-schema=E2=80=9D feature could ever be used. =  I.e., there are no protocol-accessible nodes in the module=E2=80=A6<= o:p class=3D"">
BALAZS: = The system can declare in supported/not-supported in design = documentation. E.g. in UC2, Preloading Default Configuration the = designer preparing instance data, can decide to use or not use the = inline-content-schema based on this.
 
When I make statements like this, = please see it as an opportunity to improve the document.  In this = case, please modify the inline-content-schema=E2=80=99s = =E2=80=9Cdescription=E2=80=9D statement to indicate that the feature is = never supported by a server, and that it is intended to be enabled via = out-of-band documentation.  BTW, was this discussed by the WG?
BALAZS3:  OK. Added out-of-band = documentation. It was discussed and this was the proposed solution. =  Some people insisted that this should be optional. This is the = best way to indicate that.

Thanks, I see this:  [PS: also must=E2=80=99ve = been in an update before -13]

       description
         "This feature indicates = that inline content-schema
      =     option is supported. Support for this feature = might
          be = documented only via out-of-band documentation.";



- "leaf-list = inline-module" is "min-elements 1=E2=80=9D and "ordered-by user=E2=80=9D, = but "leaf-list module=E2=80=9D has neither (though it may be that = ordering is irrelevant for simple-inline).
BALAZS: = ordered-by  removed. It doesn't really mean anything. In this case = there is no chance of the system reordering a list a = CLI/Netconf/Restconf client provided.
Min-elements is not = needed for simplified-inline as the case will only be selected if there = is at least one "module" leaf-list entry. It is needed for inline = because otherwise the case could contain an " inline-schema" anydata = section and no "inline-module" entries. That would not be usable.
 
That may be true, but it=E2=80=99s = equally true for the other leaf-list.  It's inconsistent. =  
BALAZS3:  OK. This is not strictly needed, = but it improves readability. Added min-elements 1 to the other = leaf-list. 

Thanks.

 
BTW, is "choice content-schema-spec=E2=80=9D = meant to be =E2=80=9Cmandatory true=E2=80=9D?  - because, = currently, 'content-schema=E2=80=9D doesn=E2=80=99t have to be specified = according to the model=E2=80=A6
BALAZS3: It is optional. Section 2.1.  Specifying = the Content Schema specifies this. E.g. if you are sending diagnostics = data every 10 seconds with the same filename, it is not needed to = include the content schema every = time.

Okay.


- The last two = sentences of the =E2=80=9Cdescription=E2=80=9D statement on line 207 in = the YANG module contradict each other.
BALAZS: = Why ? I don't see the contradiction. If you know a single datastore = specify it. If not omit the leaf. If the leaf is omitted, the situation = is unknown.
 
I = think the word =E2=80=9Cundefined=E2=80=9D is throwing me.  Maybe = =E2=80=9Cunspecified=E2=80=9D would be better?
BALAZS3: OK, use = unspecified


Thanks.


Structural = issues:

 
- The list under = "Metadata SHOULD include:=E2=80=9D is not indented.
BALAZS: = OK, added
 
I = don=E2=80=99t see it.  The way to do it is by adding a fake = =E2=80=9Clist=E2=80=9D, with missing symbols, to put the other list = inside...
 
BALAZS3: It is now. Please check


Thanks!


- The three examples should be = <section> of their own (e.g., 3.2.x)
BALAZS: = OK
 
Better, but:
  - the new titles don=E2=80=99t = match the UC titles
  - perhaps remove the =E2=80=9CUCx,=E2=80=9D= prefix from the titles?  It looks weird in
  =   the ToC and they're not needed in the title since the first = sentence
    relates the example to the UC = already...
  - BTW, missing word =E2=80=9Cin=E2=80=9D: =  s/The example illustrates UC[125] Section 1
  =   /The example illustrates UC[125] in Section 1/
 
BALAZS3: OK

Thanks.


- The =E2=80=9Cinline=E2=80=9D choice = node is generally confusing.  I can=E2=80=99t tell if it=E2=80=99s = missing container called =E2=80=9Cinline=E2=80=9D or if the two = descendant nodes are poorly named.  In either case, it would be = best to try to make it more readable.
BALAZS: = Yes it is complicated. Some members of Netmod (I think Rob W.) Asked for = a full, powerful, flexible way of documenting the content schema. In = some cases it is needed.
 
I=E2=80=99m not saying that it=E2=80=99s = purpose is confusing, I=E2=80=99m saying that its poorly named or = missing a parent container.  Try looking at your examples with = =E2=80=9Cfresh=E2=80=9D eyes.  The node names "inline-module=E2=80=9D= and =E2=80=9Cinline-schema=E2=80=9D are odd.  It seems like = =E2=80=9Cinline-module=E2=80=9D could be =E2=80=9Canydata-schema=E2=80=9D = and "inline-schema=E2=80=9D could be =E2=80=9Cmodule-data=E2=80=9D?
BALAZS3: OK. Added container = inline-content-schema

Thanks - better.


Editorial issues:

 
- s/e.g., UC5 = documenting diagnostic data/(e.g., UC5 [Section 2])/
BALAZS: I = prefer to use the short name of the use case instead of the reference. = IMHO it provides information instantly without a look-up. Is that a = problem?
 
I = think I mentioned this above already, but the titles are wrong. =  
 
Myself, I=E2=80=99d remove all the = =E2=80=9CFigure=E2=80=9D postambles; I never title my figures, just more = to have to look at and maintain.  In the case, this is where the UC = titles are again incorrect...
BALAZS3: OK, Figure postambles Removed.

Thanks.



- S3.1.1 P2 = doesn=E2=80=99t makes sense to me (esp. the verdt ref, which likely = should be removed or better explained)
BALAZS: = This was explicitly requested by 2 members of the verdt team. I tried to = amend the text to make it more understandable, however IMHO we should = not try to explain the usage of revision label here. Also this is just = an example.
 
OLD: 
   (e.g., = revision labels which can be used as alternative to the revision
  =  date[I-D.verdt-netmod-yang-module-versioning]). 
 
NEW:
    (e.g., revision labels, = described by [I-D.verdt-netmod-yang-module-versioning]
  =   as alternative to the revision date). 
BALAZS3: = OK

Thanks.



BTW, immediately following, the text = says "See Section 2.2.=E2=80=9D   This doesn=E2=80=99t = mean
Anything to me.  Do you want to say = something like =E2=80=9CAn example of the =E2=80=9Cinline=E2=80=9D = method is provided in 2.2.1=E2=80=9D?
BALAZS3: OK. Reference removed, replaced by a = reference to an =  example.

Okay.


- = s/is based on "UC1, Documenting Server Capabilities=E2=80=9D/exemplifies = UC1 [Section 2]/
BALAZS: Exemplifying is an = uncommon word I find ugly. Is the current text hard to understand or = misleading? 
I changed it to " The = following example illustrates ..." I hope that's OK.
 
I=E2=80=99m unsure if = it=E2=80=99s possible for something to be =E2=80=9Cbased on=E2=80=9D or = =E2=80=9Cillustrate=E2=80=9D a use case.  Illustrate is better = though, maybe =E2=80=9Creflects=E2=80=9D or =E2=80=9Cepitomizes"?
BALAZS3: OK, changed to = reflects

Thanks.



BTW, missing =E2=80=9Cin": =  s/illustrates UC1 Section 1/illustrates UC1 in Section 1/
BALAZS3: = OK

Thanks.


- s/- Use case 1, Documenting server = capabilities/Exemplifying UC1/
BALAZS: = Exemplifying is an uncommon word I find ugly. Is the current text hard = to understand or misleading?  
IMHO the string = stating  the name of the use case is more helpful then a reference, = that needs to be looked up.
I changed it to " The = following example illustrates ..." I hope that's OK.
 
Same comment as above.
BALAZS3: OK, changed to = reflects

Thanks.


- s/is based on = "UC2, Preloading Default Configuration=E2=80=9D/exemplifies UC2 [Section = 2]/
BALAZS: = Exemplifying is an uncommon word I find ugly. Is the current text hard = to understand or misleading?  
I changed it to " The = following example illustrates ..." I hope that's OK.
 
Same comment as above.
BALAZS3: OK

Thanks.


- s/- Use case 2, Preloading access = control data/Exemplifying UC2/
BALAZS: = Exemplifying is an uncommon word I find ugly. Is the current text hard = to understand or misleading?  
IMHO the string = stating  the name of the use case is more helpful then a reference, = that needs to be looked up
 
Same comment as above.
BALAZS3: = OK

Thanks.

 
>  - s/is based on UC5 Storing = diagnostics data/exemplifies UC5 [Section 2]/
BALAZS: OK. = but I changed it to: exemplifies UC5, Storing diagnostics data. IMHO the = string stating  the name of the use case is more helpful then a = reference, that needs to be looked up.
I changed it to " = The following example illustrates "UC2, Preloading ..." I hope that's = OK.
 
Same comment as = above.
BALAZS3: = OK

Thanks.

 
- s/- UC5 Storing = diagnostics data/Exemplifying UC5/
BALAZS: = Exemplifying is an uncommon word I find ugly. Is the current text hard = to understand or misleading?  
IMHO the string = stating  the name of the use case is more helpful then a reference, = that needs to be looked up.>
I changed it to " The = following example illustrates ..." I hope that's OK.
 
Same comment as above.
BALAZS3: OK

Thanks.


- =E2=80=9Cdescription" statement on line 100: = s/content schema/schema (i.e., YANG modules)/?
BALAZS: The term = "content-schema" is defined in the terminology section.  It defines =  
 
Fine, but please add "(i.e., YANG = modules)=E2=80=9D so people will have better clue 
BALAZS3: = OK

Thanks.

- =E2=80=9Ctype = string=E2=80=9D statement on lines 109 and 131 are missing a =E2=80=9Cpatt= ern" statement.
BALAZS: OK, Defined it as a typedef.
 
Good!  But I=E2=80=99m unsure about the = pattern statement (esp. "pattern = '.|..|[^xX].*|.[^mM].*|..[^lL].*=E2=80=99;=E2=80=9D)=E2=80=A6did you = copy/paste it from somewhere?
BALAZS3: Copied from rfc6991. It is meant to ensure = that an identifier does not start with the string xml.
 typedef yang-identifier {
      type = string {
        length = "1..max";
        pattern = '[a-zA-Z_][a-zA-Z0-9\-_.]*';
        pattern = '.|..|[^xX].*|.[^mM].*|..[^lL].*';
      }


Okay.



- P2 in the =E2=80=9Cdescription" = statements on lines 220 and 249: s/For instance data sets/Instance data = sets/
BALAZS: = The sentence will not make sense unless I change the comma at the end of = sentence to a colon.
 
Hmmm, that didn=E2=80=99t come out very = well.  This is the same issue as before, whereby =E2=80=9CFor = instance data...=E2=80=9D looks like it should be read =E2=80=9CFor = instance, data=E2=80=A6=E2=80=9D.  Maybe you can find a better way = to express this?

BALAZS3: OK, = changed to
In case = of 'instance data sets ...

Thanks!



K.



= --Apple-Mail=_6C395BFE-1EF2-4941-B3FB-785CC74ECBCD-- From nobody Thu Apr 1 17:25:14 2021 Return-Path: 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 371B43A29DC for ; Thu, 1 Apr 2021 17:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 UQsTMKCwCICG for ; Thu, 1 Apr 2021 17:25:01 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 950B53A299E for ; Thu, 1 Apr 2021 17:24:58 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id q5so2576115pfh.10 for ; Thu, 01 Apr 2021 17:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=cX2ViAwzaIl1fOs2aYjWUQfjWis8sbd4t7yvYC8vGmQ=; b=aFnrKuuaxG5Xg96ebX2BAWqv0jFZZTBApG5fOQOSoDHm/NPhMWz/ceYOhBTFOWg2YJ Jd/yNhCU1R4uIU11zBe+jlz+mCI9Y9KR+oFnnqtQxNBhX9V/YrxMD9GlbRgbyPBud/Rb r3uqr+tTXvKQSQK4zvI3dhdmtLXOWOQqBWoOiazFIlowvSPHsvDfi6U/d1jYbzsL+HVm 8ZXF7xioAutpwB331jFanHAMPXQqqtjBTxPtyTGJV7/4LXaqIlg5YHRsR1d4UScsHWfW Wv20NzmBGCJa5pNwhJydQ5bFjWj+W9a/tEa0d1dHH+ziJv6WSnhCjmQ3DarlV5CQDwvF PLGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:content-transfer-encoding :mime-version:subject:message-id:date:to; bh=cX2ViAwzaIl1fOs2aYjWUQfjWis8sbd4t7yvYC8vGmQ=; b=QJlZ/evuqI2Xn1Cg6Bcc9bzHlpxNEVREML+/NVUhtjTrHabuXkNu+0rL1iNjb3Rg2k jtjV5BIl6sIVR/rczoTjy6Zt6ExxvFUslM0/jH1joRVVGV93JzrA0Mojeu7gzNuQLtK+ NnLUhImpRF0XSjMkyEAcKFVqvboo/ZXMrhRgJPOnLB/Jtozdl8SqwC8O+yQm3ax4Wkok 9XZLHVuz9pRwTsDKTjLmkI3WKbGX42qpGFZe42G9JI+r5R5xuySF1s8ne8MS1RsEKj2M J4BrqQ4Ls5+DHa+Lz3gKy/EBcDIFhZTwnsIr9wxDzp0+zxRyenW2bWQt4ghY6F5C/azA dTng== X-Gm-Message-State: AOAM533g50XAjoRMjtQoQzk+A0qZUeXDwSz/4REJLo3aoy4DVmG6ufgj NN+ljJT1tax4Nl7Pt3ZAZcus03xlQAapTg== X-Google-Smtp-Source: ABdhPJyQOP6aBYxicxKQ4N1KYKixrk794GoY+3F2JNOONWyx57FIOWE4YbOIM1mYDrYeWrrKk5FnhQ== X-Received: by 2002:a63:7f18:: with SMTP id a24mr9722921pgd.137.1617323097212; Thu, 01 Apr 2021 17:24:57 -0700 (PDT) Received: from [192.168.4.41] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id f2sm6044645pfe.177.2021.04.01.17.24.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Apr 2021 17:24:56 -0700 (PDT) Sender: Tony Li From: Tony Li Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: Date: Thu, 1 Apr 2021 17:24:55 -0700 To: netmod@ietf.org X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: [netmod] YANG questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 00:25:11 -0000 Hi, I have some basic questions about YANG. I=E2=80=99m pretty certain this = is NOT the right place to ask them, so please feel free to redirect me. 1) Is there a way to define the width of an enumeration? Suppose I had = an enumeration that was in a 16 bit field, how do I describe that? 2) How do I model a non-octet sized multi-bit field? For example, if = there is a 5 bit numeric value as part of some =E2=80=98bits=E2=80=99? = Position only takes a single value, I can=E2=80=99t really say = =E2=80=98position 3-7=E2=80=99. Thanks, Tony= From nobody Fri Apr 2 01:28:07 2021 Return-Path: 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 F1C453A387D for ; Fri, 2 Apr 2021 01:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 oJANQYle3bLP for ; Fri, 2 Apr 2021 01:28:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD7E3A387B for ; Fri, 2 Apr 2021 01:28:00 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 2A2D4140A8A; Fri, 2 Apr 2021 10:27:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1617352078; bh=3V1st91r6Vm863SNE4WA9K+UhiIBD/2grV/i5SCHKH8=; h=From:To:Date; b=BJ6+4mnYma38UfhS6kShBsIpZrN3q3oWbn923LrFvQdg3V+ET+bTX5GJzJ4ddq9gV M8HOtbuyHIeKYI/+Mh/7PHffShO6m5ujOyP1f1Ma5rb3m5qp2Ho93IJgoOagH1vbDa dY0eZ6rkJ+ab/zyi8KyqMQ+JYf8Q/oh//5mPSwoI= From: Ladislav Lhotka To: Tony Li , netmod@ietf.org In-Reply-To: References: Mail-Followup-To: Tony Li , netmod@ietf.org Date: Fri, 02 Apr 2021 10:27:57 +0200 Message-ID: <877dllt7jm.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] YANG questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 08:28:06 -0000 Tony Li writes: > Hi, > > I have some basic questions about YANG. I=E2=80=99m pretty certain this i= s NOT the right place to ask them, so please feel free to redirect me. > > > 1) Is there a way to define the width of an enumeration? Suppose I had a= n enumeration that was in a 16 bit field, how do I describe that? In the description, if necessary. However, this should be an implementation= detail, as long as the underlying numeric type can accommodate all enums. You could perhaps also define and enum for the highest possible value and m= ake in reserved. > > 2) How do I model a non-octet sized multi-bit field? For example, if the= re is a 5 bit numeric value as part of some =E2=80=98bits=E2=80=99? Positi= on only takes a single value, I can=E2=80=99t really say =E2=80=98position = 3-7=E2=80=99. In this case, I would question whether the 'bits' type is really appropriat= e. It might be useful to split the value into multiple items in YANG. Lada > > Thanks, > Tony > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 2 09:14:19 2021 Return-Path: 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 16AA43A1BC4 for ; Fri, 2 Apr 2021 09:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ERJQ4f9LHFHJ for ; Fri, 2 Apr 2021 09:14:12 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 D4B4B3A1BC3 for ; Fri, 2 Apr 2021 09:14:12 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id k23-20020a17090a5917b02901043e35ad4aso4802908pji.3 for ; Fri, 02 Apr 2021 09:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b3YkQX6KYMW6wpk136rPk6huE4EHKV/EDHFlRwPxVKM=; b=MBcImJ7rdx9xWB/COzpwAKlX6moyHFwForSqE5tJujNqtclGpZP8meNV0IfviBEoim eU+jNIfO1/hIcR3Ys9qfFSMagepXr6nbUnPdNHgsMAt4zMZbNV3IgA2MfuqB1hmNCMIO /pu48rKqpBQIolCzNVDFyc5z43ihUKju0mBuPuIFlfdmaC0XR37B/keJiuhNO21AYCzl 5lx+0GrxIx0FHEsS2yo3FH/nZPXEJQ615P/yt8DVyAbezAlU/udDTfLaMIT8dRXeieMf rXVib3weo/C+ejkzaFib2dxsJgtdsy2CF11T6vYT4d3C2oPi4LeMHRoXhDR0LOdLJgCS wchw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=b3YkQX6KYMW6wpk136rPk6huE4EHKV/EDHFlRwPxVKM=; b=p9vVhPJwJVzAlubBsevZ1zLWS7E+LdNrUnG+kJssSJhNAnizjPxauwmHMmhpSyYhkO /FuGRWJzagFLCsW9mOIkySdpRgGxhOfj1p5B6XQOJAw6Dx3jEej6IVcTwW8m0DpCFASt BcoLwGPsSy+0s2YVLH03oF97nWyVBm0Ij8dGHYoeS9UoBwu+vkQ4ryMuPvZANMFei7XM Lx/g8hmNqcvWef2tZS2Y+0ZWeC2C7aO067+9A22cidEh6KwTFMF1Rwo7wCxjT1k2Kr5O CVvzQLfACXY6NWRBPruKFojkwd722WA4yK6wClJNp7CrH2NsQQzzou0zorPfc19KKSc9 P4PQ== X-Gm-Message-State: AOAM532AoNUmt0H1/+/GoY1wGf1dLUwE1GgtU35iotQsjFiFX5jF5ALQ BjteuWv2+4TPmiE4b39pm1ZU+e1MZcnTPQ== X-Google-Smtp-Source: ABdhPJxu79O1uXWHUOFyd9uRMXSzLLu22eS91Fse2I6bof7MkHJng2rOn/EhlvjVgUj9gte6Y1SGdg== X-Received: by 2002:a17:90a:6343:: with SMTP id v3mr14314307pjs.153.1617380051302; Fri, 02 Apr 2021 09:14:11 -0700 (PDT) Received: from [10.201.201.131] (173-164-197-225-SFBA.hfc.comcastbusiness.net. [173.164.197.225]) by smtp.gmail.com with ESMTPSA id w15sm8281231pfn.84.2021.04.02.09.14.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Apr 2021 09:14:10 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Tony Li In-Reply-To: <877dllt7jm.fsf@nic.cz> Date: Fri, 2 Apr 2021 09:14:10 -0700 Cc: netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <00A512EB-3F4F-4D6C-893D-5E5769EB888E@tony.li> References: <877dllt7jm.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [netmod] YANG questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 16:14:17 -0000 Hi Lada, Thanks for your reply. At heart, I guess I=E2=80=99m asking a more = fundamental question: is YANG intended as a data modelling language or = as a data structure modelling language? Your reply suggests the former: structure is irrelevant to YANG. If = that=E2=80=99s true, then what=E2=80=99s the point in =E2=80=98position=E2= =80=99? And why do you need =E2=80=98bits=E2=80=99 when you have = =E2=80=98binary=E2=80=99? Confused, Tony > On Apr 2, 2021, at 1:27 AM, Ladislav Lhotka = wrote: >=20 > Tony Li writes: >=20 >> Hi, >>=20 >> I have some basic questions about YANG. I=E2=80=99m pretty certain = this is NOT the right place to ask them, so please feel free to redirect = me. >>=20 >>=20 >> 1) Is there a way to define the width of an enumeration? Suppose I = had an enumeration that was in a 16 bit field, how do I describe that? >=20 > In the description, if necessary. However, this should be an = implementation detail, as long as the underlying numeric type can = accommodate all enums. >=20 > You could perhaps also define and enum for the highest possible value = and make in reserved. >=20 >>=20 >> 2) How do I model a non-octet sized multi-bit field? For example, if = there is a 5 bit numeric value as part of some =E2=80=98bits=E2=80=99? = Position only takes a single value, I can=E2=80=99t really say = =E2=80=98position 3-7=E2=80=99. >=20 > In this case, I would question whether the 'bits' type is really = appropriate. It might be useful to split the value into multiple items = in YANG. >=20 > Lada >=20 >>=20 >> Thanks, >> Tony >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 2 10:23:32 2021 Return-Path: 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 514563A1DE6 for ; Fri, 2 Apr 2021 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ItgGWcst; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TQS2SSW7 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 jH9InfPP_5CT for ; Fri, 2 Apr 2021 10:23:26 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FB13A1DE9 for ; Fri, 2 Apr 2021 10:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3450; q=dns/txt; s=iport; t=1617384206; x=1618593806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a+u9gjofxB+7R6gjAtfCfaPLCzxyOWb30eU0B8KgJIc=; b=ItgGWcstPBtCQr7fatoouiTch15giMiARp9gUxwlRGX9Zv1fUS1w1bXe ggqDMmLlEWTzNIjXIcXi2uU9HULH9lNeO1eOxDzAHno/3339V49hpxiIm 4VQTZRV6dH7JA9N9LKomzBGpo0I0s25BzXkyo4hwXD2JoYiw4N/DvbP0U E=; X-IPAS-Result: =?us-ascii?q?A0A4AABDUmdgmJNdJa1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UAFAQELAYFSUX5aNjEKhDiDSAOFOYhKA5k3gS6BJQNUCwEBAQ0BAR0LCgIEA?= =?us-ascii?q?QGEDEQCF4FlAiU2Bw4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFoh?= =?us-ascii?q?VANhkQBAQEDAQEBIREMAQEsCwEPAgEIGAICJgICAiULFRACBAENBYJxAYJVA?= =?us-ascii?q?w4hAQ6hAgKKH3eBMoEBggQBAQaCTIJIGIITAwaBDyoBgnWECYJZg3ImHIILg?= =?us-ascii?q?Tkcglk+gU6BEgEBgTUpgxY1giuCRIEQGRhPDCBiASMDlHWlKoEUCoMKnHQDF?= =?us-ascii?q?gmDTIp4limVEqMhAgQCBAUCDgEBBoFbBC2BW3AVOyoBgj5QFwIOjh8Zg1eDR?= =?us-ascii?q?oFOhUVzOAIGAQkBAQMJfIs2gTYBgQ4BAQ?= IronPort-PHdr: A9a23:qQlPwh3RrTK75SYzsmDPR1BlVkAck7zpIg4Y7IYmgLtSc6Oluo7vJ 1Hb+e4FpEPOW5Sd7/MXw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3B oJOAVli+XzoLU9TCYD6Zg6arni79zVHHBL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5L Q69qkPascxF6bY= IronPort-HdrOrdr: A9a23:VQlMPq4RfbskaV6powPXwdmFI+orLtY04lQ7vn1ZYSd+NuSFis Gjm+ka3xfoiDAXHEotg8yEJbPoexLh3LZPy800Ma25VAfr/FGpIoZr8Jf4z1TbdRHW3tV2kZ 1te60WMrLNJHBxh8ri/U2cG9Ev3NGI/MmT9Jjj5l1GJDsaDJ1IxQF/FwqdDwlXaWB9dNoEPb Cb4ddKoCflXHwRYNiyCHVtZZm8m/TgkpX6bRkaQyM94A6Vgj+yrJL8GR6U3hAROgk/gosK22 7DjgD/++Gfo+i2oyWsllP7wrZ3vJ/aytVFDNGRkcR9EFXRoyuheYgJYcz4gBkbu+eqgWxa9e XkgxBlBMhr7mOUQ2fdm2qQ5yDF8BIDr0Dv0kWZh3yLm726eBsfB9BajYxUNjv1gnBQxu1U66 5A02KHu5c/N3qp906Ri6mqJnNXv3G5rnY4nekYg2Y3a/piVJZqsYcd8ElJea1weh7S1YE9HO FiSOHa6fpGGGnqF0zxg2h1zNSgGkk0BxeNK3Jyw/C97j4+pgEc82IogOgk2lsQ/pM0TJdJo8 7eNL5zqb1IRsgKKYpgGeYoW6KMeynwaCOJFFjXDUXsFakBNX6IgYXw+q8J6Oajf4FN5Icuma 7GTEhTuQcJCgbTIPzL+KcO3gHGQW27Uzio4NpZ/YJFtrr1Q6euFiGfVlY0kY+Fr+8ECsPWH9 a/UagmRMPLHC/LI8Jkzgf+U55dJT01S8sOoOs2XFqIv4bFMYvvuuvHcOvCJbbkHDo+M1mPW0 crbXzWHoFt/0qrUnj3jFz6QHX2YHHy+pp2Dezb8oEoudAwH7wJljJQpUWy58mNJzEHmLcxZl FCLLTulb7+oWG3+G3P/nh4IxY1NDcP3JzQF1dx4SMaOUL9drgO//+Ff3pJ4XeBLhhjC8XMEA BeoFxz8bmtL4OZwD0jD97PCBPds1Ij4FaxC7sMkKyK4snoPrkiCIw9ZaB3HQLXUwBulR1ys2 dFYg8cTkrZHjfj4J/V1qA8NaX6TZ1RkQ2rKclbpTbjrk2av9goXWZedSWpS9SrjQEnQCd0il V9/7QEuqeJnS+iJAIE8bkFGWwJTF7SIbpdSCyZeY1fm9nQCXBNZFbPoQbftjYeVS7B8V4Iim noMCuOEMu7cmZ1izR/yabl8FR9a2OHWVl/A0oK7bFVJCDhpmt51/ONa+6V1WacA2FynN01AX XifSYYJB9oypSM8COt3ByGFXkg2/wVT7PgJbw+brDe3W6sIoWUlacAW+RZ5ophKcqGiJ54bc uCYQOPaDv3B+Q1sjbl1UoNKW16rmIpnujv3wCg5G+k3GQnCf6XO1h+QaoHSuvso1TMVrKN0J 9ji8gysvb1OmLtasSewaW/VU8IFjrD5Wq3Rfovs5ZaoOY7s6ZyBYDSVX/N2Gtc1BszaMfym0 V2etU33JnRfotuddcVYSRX4x4gk8mONlIitkjuGfAlFGtdxkPzLpeM+f7FuLAvCkqOqE/5Pk Se6TRU+7PAUzGY3bAXBqosKQ1tGQcBwWUn+PnHe5zbCQ2see0G5la8P3OneLJWSaSOG9wr31 1HysDNm/XSezvz2QjWszc+P7lH9Hy/R9iuRA2LAuxF/rWBSBqxq7rv5NT2ijj5STG2MRtFwY JEcFEddcRFhH0pipYt3i27V6zwpQYknjJlkEZav0+o3pLj5mHRWVxCO0nehJ5dWDFIKHiGjc jf64GjpTzAySkA3YOGDVtae9FFBsMZQYf2JTp/MMR4hs/dw4M/xiBYJAo0B2EyiDrhz/pr0L ew1vLVQfDjAx7TSCQ80C8AAJV1kCwtoXxBdMb77YvVWHRjKtI1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,300,1610409600"; d="scan'208";a="688441364" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2021 17:23:25 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 132HNPf3001001 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 2 Apr 2021 17:23:25 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 2 Apr 2021 12:23:24 -0500 Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 2 Apr 2021 12:23:24 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 2 Apr 2021 12:23:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RCM7FWu401G98s+JqQjavGX/lfOgotAY3N5bTRaeP98i5yM27f/IQjvPO16uvhFPfLG3eivWzO8PNOsoAYg9+4M5r4td97BYTC/my1xPdoGG9tLj/tVuXy7loTUkBhtd3/ugJmq380Af/tkfnyb2qPmYi3Grf3FjvmJtpmThsOW6AbobiRkMULzhVGLL8EAgcVYglQ0Y8qbNzGoLsHUhhpArG5RNWaMkKvqJb07u6h1LWg7WS7XZomxS9Pgk6ulMIKkUKXY9WrGiLZsuKf65ubLEgG/CLEg7yc6L72TE5fft5wd40W3/+KNTGpWQEd0KCTuXOL5Zu/Ac/N7Ym+hslQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a+u9gjofxB+7R6gjAtfCfaPLCzxyOWb30eU0B8KgJIc=; b=j05ZHaRgiZlwL7Lj133hjdLnnrQLvCWXn/1n1/j1IdlXPE3Mo3Q4AAzvV2f5BDorILANV5OW98xMX3dLYep1J+baNw0/zJ4RYv0uj6Id1NXvywwRHPmpQXdqen+B3p0nQ7Bntp9/YA3O8kFsKajtmIF0GoXVFBvEVlvF/4GGBwuoYXEjXiVR+wiHNQDZjZmu9YotVi6oWioRBjwBn+nBNCpbHC0l4ZGOtshl95S/VzJUjuuhpse9zUdamzKxPTCIEF+aaF34gql/5ib6JwBjIgwFPLcsujG6NHkAFpepkGf+yvUe8JXvlMT6uFcPTNuuzw75nP+bVRYY6Nn8v+AUuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a+u9gjofxB+7R6gjAtfCfaPLCzxyOWb30eU0B8KgJIc=; b=TQS2SSW7wH4W2H14Z8rSbV38Wx2yK0HmYv+0Hk72zD416KuOEkd3dYRSWZb9A37kCYLhX9wAXXVbHeY1h+jx+YYFPKwc/DLKSFEkIPN57XwR6pu+ICm9eM7ZXji02xoRNK4vJ2+zKIxvjAV5m6zRsCEGiaoB9YqVkOVAPVYXcWk= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB4973.namprd11.prod.outlook.com (2603:10b6:a03:2de::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.29; Fri, 2 Apr 2021 17:23:23 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::f82f:ff98:d282:d5e5]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::f82f:ff98:d282:d5e5%5]) with mapi id 15.20.3977.033; Fri, 2 Apr 2021 17:23:23 +0000 From: "Acee Lindem (acee)" To: Tony Li , Ladislav Lhotka CC: "netmod@ietf.org" Thread-Topic: [netmod] YANG questions Thread-Index: AQHXJ1a8CeQX0hjXBEOwf+wTAf8cDqqg5X2AgACCQgD//9BEgA== Date: Fri, 2 Apr 2021 17:23:22 +0000 Message-ID: References: <877dllt7jm.fsf@nic.cz> <00A512EB-3F4F-4D6C-893D-5E5769EB888E@tony.li> In-Reply-To: <00A512EB-3F4F-4D6C-893D-5E5769EB888E@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a92763e1-569a-40f7-a38c-08d8f5fc04ac x-ms-traffictypediagnostic: SJ0PR11MB4973: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W3sLPYMGkKj19CzPGqxWlCp0QYW44wnBObo+z27M5xL8El5udXHhNd2YPYVnpeX0AccNCIsw5S9nHGhUNpQzXuMWMRiDW0uX9Ki3lf9idF9iBZzxh8Ep92fvw4LDeKswXuVlCNiDfzVViCK4oipjZfQilHlHVCGFshAgqTUhOMHisYORBxQlKbKOtY9IKcfzjuzM10byHK6kGw1FGWFJIHLTWrfwpl92HW74xa/Ojw6Dbgbu8uZAp5nBjsfhtJRAe1tvrPOawohUssbAMjLQxpGA4swhu8O5KAId2q2LTmqGxRP7sVOFB3CyOAhwj31GXFlHnpChujnKQSLqjawXP1+3b4mTcibZLeYdpO4LRlVootWTfN09+fVFt/8aXqmsC+ojwtaVqQr1J2Z4fibqKJUlTn/1BCq43VsVYfSCf9OD9hSoAWwEODxd8mn0ymWaA7jhL/y76RvgFCBgiyNkjIH7BmjgR39cFHwwt24R4KvGlPP8Yi0pHD48IW3kjAyDuBw2E5t4GgD7lMKp0Yx1Z7hgm3RUbUr6JqI8+/MJu3cOpGjdxKDTnvmQAuAy02Ryq/HmLtVQyqDECPLBe7iT94r0azGQAnhs4MJfF4fZ/sZcRmkCeKvXgcNpU+HpLIEXf21/t4J3+vrlcY0TXsh6ZbfO3mlWGRH9n4pGooMzFuoBYyCM8O86MhITeWQUWzRaTl+ipMeQbl1RlaVc5FVhs2QSrLwNNu9kNVV23NJwHt0O7XmoZguFRl55b59DW4AyzK+hES4rLh30I9aymOyFEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(39860400002)(376002)(366004)(26005)(6512007)(71200400001)(110136005)(83380400001)(316002)(186003)(33656002)(6486002)(53546011)(4326008)(66946007)(2616005)(76116006)(5660300002)(66556008)(38100700001)(66476007)(2906002)(478600001)(8936002)(966005)(86362001)(8676002)(66446008)(64756008)(6506007)(36756003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?N0c3amN0a2V2eGdEcXVsR2FTSUtTWS9zNGRIZFByam9lTjYweTRZa2hBLzh4?= =?utf-8?B?Uk5oeDFuTUFSM3VHSlhKdndzRlpOdGc1YVd1ZFZyRkIxa2VBaTJTbXNSZ1VK?= =?utf-8?B?MURiVHpiaGEzdVpBR1Q2aGN0czQyRlZUeDZrMVdQTWdBcGJJQUJKdjVWL2pO?= =?utf-8?B?bGloaTFaakp3WUtHdmJFUzlOTUtZeHpRNXZaRmt4Wi9OOFZiaDRWbU16dEYx?= =?utf-8?B?ZFlMU3ZLTkVUTHFhUFAwRVVRdnZmY2xwVE1mVDBzbDRRK0pIRU9Va3BiNm1O?= =?utf-8?B?NTNRQXpuUWFVVVBQRjZTZTdJV3hZeFpyMlBhTk1YRE1hOWdxVklXb1ducUpI?= =?utf-8?B?VmJYcjlBVU8xajY1dm1CM21QOW9BMjhJWTNTWU4wQ0VEenpKMHZJbXUxenhv?= =?utf-8?B?T2RFUjliVTRkYUF0U2FZY05DUE1IVFZFQ1ZKWDB6WkJYd0craTFHTDUwdjBW?= =?utf-8?B?bEJVeDdSc2Z4ZlpXOXU4ZmQwcmFWdXMzOHNjNndtNGovdTMzZkMwaXNKbHI3?= =?utf-8?B?cmJsbDU4bmZLZC90dElldnN0SjludGFBT0ZwSVNkeUFXWUtqWGEyUEUvT3B1?= =?utf-8?B?MU1MZGxRR1lneXd6RGdKSzEvTENjdUhhR1ZrdFcvMmYwNURCVlNPQThzRkNj?= =?utf-8?B?OFBzU1RmZTFNN2FTV3FETnI4REpHSUJRbXZlZHpCSGNGR3lKK08zNjY4N016?= =?utf-8?B?b0ZTOXJZcmtYT2hWR3c0bDdNSnY2cXprUFg2K3ZFNnRhTTdDcWxxWDU5R0M1?= =?utf-8?B?dFFMcnp3bWk3R0xqalBCL0pvdUZKUENKTjRCUHNmZlJSMVBBU3FzODg1LzM4?= =?utf-8?B?NFc4cU1sdUl0eHdvZWFld2tCN2o5REFrOE42NnN1Vk1Cc1NUSkpKL1RvUkFJ?= =?utf-8?B?Sm9tdW1QS1lITTFtU2xIYW9rcEVON1BjWDZLYkNwbTdURFMyMktVV05PdzI4?= =?utf-8?B?OHVBL1FPYk9vOVlGVG5VVzhsc1BNbCtidlgxcG1zcDE0UFkzaWZDMXdwNnR3?= =?utf-8?B?ODY0eUs5dGUwMWVJcEREWFcyRTJ3cmdyc1ZwRDRpV3pPalc2OU13Y01Jakoy?= =?utf-8?B?QzJMQTlIdTIrVVhNRjAydkdsaWdDaTlybVZKT3UwcG9KVTh4UzNsL0dNMmsw?= =?utf-8?B?WmNzNGdnWldHVnBHalhOSlZob3ZpV0prb3VVc2pRdTN3OURUWTdQWHY1Ym5M?= =?utf-8?B?N1MxTFNPUXYwcFNBRW5LQ3p1Z2NKem1jckxJK3VMaHA0YmRaN28yTER5bnJG?= =?utf-8?B?TzNpd1pES0szakJEQzNpbnNMb0FyK25UUmYwSXBpZ1Y4SW5FdEVlQVlJV3BF?= =?utf-8?B?cGZteDM3Y2wyb0o4RHlUOWtIMlIyYXVURGpLUmtHZEkxa3VRV3VRMVdwSGc2?= =?utf-8?B?TUpuaXRQK1RPdk9KajNCREFYaUwzMStOSXN5SnhZb0ZpS1pCMXM1cVBLUFVu?= =?utf-8?B?a1QvRWozOUpOajBQVG41dndUNVMxVE00VEFweXJveDBuRnZ5dVY4WE5BQmZj?= =?utf-8?B?K0ZvbUxFTG1pNDZxWkxwWVZldE1CVjFBQ3lIa0pqSTZkR3dCdUdaSjBGdnA2?= =?utf-8?B?bTBNYlVYa0oyd2VZNGdaOWJDZmJITWVDUGQvS2NibUdMY2c5c0dzSlRtOFNa?= =?utf-8?B?UUZhM1dqOGl2NEh1cGU2eXRoUnFPQUR4aUZnV3d3WGpjVWN1QnNGU1BVcmhD?= =?utf-8?B?UDcyNUpQT1hWWmpxYnhFMmRXd3FUR1JtUSt0V3NZQ3RRQ0hHbFQ3RUErQXNY?= =?utf-8?B?aDdlUjZJcGdYSnp0dDkreUd5YnR1VW1nWWhHMUxMMHhxSlJjVmtTczVwVks5?= =?utf-8?B?TDNHOFVRMFFYVFowK3g0dz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8F2D9AF50A5E074DB0D00433192255E6@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a92763e1-569a-40f7-a38c-08d8f5fc04ac X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2021 17:23:23.0122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: S6pX/vLLyVoTg7tc8sDlkevikBUomJOyP0j8WR1I9RbEmlWXuW1gTlgj/ox3FTAH X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4973 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [netmod] YANG questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 17:23:30 -0000 SGkgVG9ueSwNCg0KSSB3b3VsZCBhcmd1ZSB0aGF0IFlBTkcgaXMgYSBkYXRhIG1vZGVsaW5nIGxh bmd1YWdlLiBBbm90aGVyIGRpc2FkdmFudGFnZSBvZiB0aGUgYml0cyB0eXBlIHRoYXQgaXQgaXNu J3QgYXVnbWVudGFibGUgd2l0aCBuZXcgYml0cy4gSGVuY2UsIHVzYWdlIG9mIHVudXNlZCBiaXRz IHJlcXVpcmVzIGEgbmV3IHZlcnNpb24gb2YgdGhlIG1vZHVsZSBhcyBvcHBvc2VkIHRvIGFuIGF1 Z21lbnRhdGlvbi4gRm9yIHRoYXQgcmVhc29uLCB3ZSBncmVhdGx5IGxpbWl0ZWQgdGhlaXIgdXNh Z2UgaW4gcm91dGluZyBtb2R1bGVzIGFuZCB1c2VkIGlkZW50aXRpZXMgaW5zdGVhZC4gDQoNClRo YW5rcywNCkFjZWUNCg0K77u/T24gNC8yLzIxLCAxMjoxNCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgVG9ueSBMaSIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0b255Lmxp QHRvbnkubGk+IHdyb3RlOg0KDQoNCiAgICBIaSBMYWRhLA0KDQogICAgVGhhbmtzIGZvciB5b3Vy IHJlcGx5LiAgQXQgaGVhcnQsIEkgZ3Vlc3MgSeKAmW0gYXNraW5nIGEgbW9yZSBmdW5kYW1lbnRh bCBxdWVzdGlvbjogaXMgWUFORyBpbnRlbmRlZCBhcyBhIGRhdGEgbW9kZWxsaW5nIGxhbmd1YWdl IG9yIGFzIGEgZGF0YSBzdHJ1Y3R1cmUgbW9kZWxsaW5nIGxhbmd1YWdlPw0KDQogICAgWW91ciBy ZXBseSBzdWdnZXN0cyB0aGUgZm9ybWVyOiBzdHJ1Y3R1cmUgaXMgaXJyZWxldmFudCB0byBZQU5H LiAgSWYgdGhhdOKAmXMgdHJ1ZSwgdGhlbiB3aGF04oCZcyB0aGUgcG9pbnQgaW4g4oCYcG9zaXRp b27igJk/ICBBbmQgd2h5IGRvIHlvdSBuZWVkIOKAmGJpdHPigJkgd2hlbiB5b3UgaGF2ZSDigJhi aW5hcnnigJk/DQoNCiAgICBDb25mdXNlZCwNCiAgICBUb255DQoNCg0KICAgID4gT24gQXByIDIs IDIwMjEsIGF0IDE6MjcgQU0sIExhZGlzbGF2IExob3RrYSA8bGFkaXNsYXYubGhvdGthQG5pYy5j ej4gd3JvdGU6DQogICAgPiANCiAgICA+IFRvbnkgTGkgPHRvbnkubGlAdG9ueS5saT4gd3JpdGVz Og0KICAgID4gDQogICAgPj4gSGksDQogICAgPj4gDQogICAgPj4gSSBoYXZlIHNvbWUgYmFzaWMg cXVlc3Rpb25zIGFib3V0IFlBTkcuIEnigJltIHByZXR0eSBjZXJ0YWluIHRoaXMgaXMgTk9UIHRo ZSByaWdodCBwbGFjZSB0byBhc2sgdGhlbSwgc28gcGxlYXNlIGZlZWwgZnJlZSB0byByZWRpcmVj dCBtZS4NCiAgICA+PiANCiAgICA+PiANCiAgICA+PiAxKSBJcyB0aGVyZSBhIHdheSB0byBkZWZp bmUgdGhlIHdpZHRoIG9mIGFuIGVudW1lcmF0aW9uPyAgU3VwcG9zZSBJIGhhZCBhbiBlbnVtZXJh dGlvbiB0aGF0IHdhcyBpbiBhIDE2IGJpdCBmaWVsZCwgaG93IGRvIEkgZGVzY3JpYmUgdGhhdD8N CiAgICA+IA0KICAgID4gSW4gdGhlIGRlc2NyaXB0aW9uLCBpZiBuZWNlc3NhcnkuIEhvd2V2ZXIs IHRoaXMgc2hvdWxkIGJlIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCwgYXMgbG9uZyBhcyB0aGUg dW5kZXJseWluZyBudW1lcmljIHR5cGUgY2FuIGFjY29tbW9kYXRlIGFsbCBlbnVtcy4NCiAgICA+ IA0KICAgID4gWW91IGNvdWxkIHBlcmhhcHMgYWxzbyBkZWZpbmUgYW5kIGVudW0gZm9yIHRoZSBo aWdoZXN0IHBvc3NpYmxlIHZhbHVlIGFuZCBtYWtlIGluIHJlc2VydmVkLg0KICAgID4gDQogICAg Pj4gDQogICAgPj4gMikgSG93IGRvIEkgbW9kZWwgYSBub24tb2N0ZXQgc2l6ZWQgbXVsdGktYml0 IGZpZWxkPyAgRm9yIGV4YW1wbGUsIGlmIHRoZXJlIGlzIGEgNSBiaXQgbnVtZXJpYyB2YWx1ZSBh cyBwYXJ0IG9mIHNvbWUg4oCYYml0c+KAmT8gIFBvc2l0aW9uIG9ubHkgdGFrZXMgYSBzaW5nbGUg dmFsdWUsIEkgY2Fu4oCZdCByZWFsbHkgc2F5IOKAmHBvc2l0aW9uIDMtN+KAmS4NCiAgICA+IA0K ICAgID4gSW4gdGhpcyBjYXNlLCBJIHdvdWxkIHF1ZXN0aW9uIHdoZXRoZXIgdGhlICdiaXRzJyB0 eXBlIGlzIHJlYWxseSBhcHByb3ByaWF0ZS4gSXQgbWlnaHQgYmUgdXNlZnVsIHRvIHNwbGl0IHRo ZSB2YWx1ZSBpbnRvIG11bHRpcGxlIGl0ZW1zIGluIFlBTkcuDQogICAgPiANCiAgICA+IExhZGEN CiAgICA+IA0KICAgID4+IA0KICAgID4+IFRoYW5rcywNCiAgICA+PiBUb255DQogICAgPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+PiBuZXRt b2QgbWFpbGluZyBsaXN0DQogICAgPj4gbmV0bW9kQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+IA0KICAgID4gLS0gDQog ICAgPiBMYWRpc2xhdiBMaG90a2ENCiAgICA+IEhlYWQsIENaLk5JQyBMYWJzDQogICAgPiBQR1Ag S2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5l dG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kDQoNCg== From nobody Fri Apr 2 11:13:46 2021 Return-Path: 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 3A0F63A1F91 for ; Fri, 2 Apr 2021 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 jbmDNxi6SF1p for ; Fri, 2 Apr 2021 11:13:39 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 234153A1F8E for ; Fri, 2 Apr 2021 11:13:38 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id o16so6376647ljp.3 for ; Fri, 02 Apr 2021 11:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G7YcSgcIBFxNDYfdNUQcC/skhFEiwyiw/JkKwTp594c=; b=R4uU41taOceiAOwtD6A9vjO+i0Tui2FDiEn2JGUjZ8IV1LPfQSJO3QHmAQylV2NVZg wRq9hlVhjwIZjDj2PK+jyZ9ajGq1R90eohGwdL8IGacjJafXxce/+mVHuuLcAlCl6L4W s8NBdMin3jaSJa7YTDCDnmvm9ojgD9EG+v/ff9TNwNEMex4ZMYVL4a3Hjj2fNyoccAqf MS+LVNw1QRBLPRLnvluruAXy/IhE4iMMpBud9QgKGEhTdmiDZIzT2ffzFN3OSJcpPuIM WOiQdskTUXHOttsfmbzomiHnARsLZvIoRtUuvJGnHwRez/OurlaWr3MD+Dt6hm+SPmVV s7ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G7YcSgcIBFxNDYfdNUQcC/skhFEiwyiw/JkKwTp594c=; b=tZmB4kKeOS4NIql2Fioxw4ekpQu2gxsiPXTFoESgQq/MbcCNtdmrMchBvc4CLNc4ag GJh+HzOM4ZXJPVRYPDSaNGdo2ep5g3bUrUTbscZ1bU3FQTYZsDV4+PN1JbovBw6pPHIH 0nmTTBZ5pZArvINo5HCbgoLHgBzFuyRhYkRD8scmYI3wk813RUqCAdtwsspynfp6QSvo br132HFPfQnAuyJ7A/j+S8ToSLG4RQ01hkdhxdi9tDz9olU6DqT6x3QTVZOc4L6KKBPs g55uL1tXxhsyDIrl6qNDssyRviVF5ZjC8EeBWgDYC7ccxIvxE7JfFio6BzKk1krzgZwe M1jQ== X-Gm-Message-State: AOAM533fDHzMphAsZuDCKCy0Vje1nON9xva2tQlDSB2WI3Zc6e6QymRg xGIWCAeJ1Pho/zhbBUKGLMOJDsOb/mjDivHY13rUIInfzxE= X-Google-Smtp-Source: ABdhPJzcnu4lQE7g7zHhrowMt/ckbT7ZAU0qoESUYLdof/ku73/n+jV35IjQiVVwipl6jO1BJXkrWXO97ia3e0BERP4= X-Received: by 2002:a2e:6a17:: with SMTP id f23mr9368281ljc.91.1617387215827; Fri, 02 Apr 2021 11:13:35 -0700 (PDT) MIME-Version: 1.0 References: <877dllt7jm.fsf@nic.cz> <00A512EB-3F4F-4D6C-893D-5E5769EB888E@tony.li> In-Reply-To: From: Andy Bierman Date: Fri, 2 Apr 2021 11:13:24 -0700 Message-ID: To: "Acee Lindem (acee)" Cc: Tony Li , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000076c76705bf014ec6" Archived-At: Subject: Re: [netmod] YANG questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 18:13:44 -0000 --00000000000076c76705bf014ec6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 2, 2021 at 10:23 AM Acee Lindem (acee) wrote: > Hi Tony, > > I would argue that YANG is a data modeling language. Another disadvantage > of the bits type that it isn't augmentable with new bits. Hence, usage of > unused bits requires a new version of the module as opposed to an > augmentation. For that reason, we greatly limited their usage in routing > modules and used identities instead. > > The line between data model and implementation is blurry with YANG + extensions. Most of us want YANG data to be independent of the encoding format. > Thanks, > Acee > Andy > > =EF=BB=BFOn 4/2/21, 12:14 PM, "netmod on behalf of Tony Li" < > netmod-bounces@ietf.org on behalf of tony.li@tony.li> wrote: > > > Hi Lada, > > Thanks for your reply. At heart, I guess I=E2=80=99m asking a more > fundamental question: is YANG intended as a data modelling language or as= a > data structure modelling language? > > Your reply suggests the former: structure is irrelevant to YANG. If > that=E2=80=99s true, then what=E2=80=99s the point in =E2=80=98position= =E2=80=99? And why do you need > =E2=80=98bits=E2=80=99 when you have =E2=80=98binary=E2=80=99? > > Confused, > Tony > > > > On Apr 2, 2021, at 1:27 AM, Ladislav Lhotka > wrote: > > > > Tony Li writes: > > > >> Hi, > >> > >> I have some basic questions about YANG. I=E2=80=99m pretty certain= this is > NOT the right place to ask them, so please feel free to redirect me. > >> > >> > >> 1) Is there a way to define the width of an enumeration? Suppose = I > had an enumeration that was in a 16 bit field, how do I describe that? > > > > In the description, if necessary. However, this should be an > implementation detail, as long as the underlying numeric type can > accommodate all enums. > > > > You could perhaps also define and enum for the highest possible > value and make in reserved. > > > >> > >> 2) How do I model a non-octet sized multi-bit field? For example, > if there is a 5 bit numeric value as part of some =E2=80=98bits=E2=80=99?= Position only > takes a single value, I can=E2=80=99t really say =E2=80=98position 3-7=E2= =80=99. > > > > In this case, I would question whether the 'bits' type is really > appropriate. It might be useful to split the value into multiple items in > YANG. > > > > Lada > > > >> > >> Thanks, > >> Tony > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > 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 > --00000000000076c76705bf014ec6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 2, 2021 at 10:23 AM Acee = Lindem (acee) <acee=3D40ci= sco.com@dmarc.ietf.org> wrote:
Hi Tony,

I would argue that YANG is a data modeling language. Another disadvantage o= f the bits type that it isn't augmentable with new bits. Hence, usage o= f unused bits requires a new version of the module as opposed to an augment= ation. For that reason, we greatly limited their usage in routing modules a= nd used identities instead.


The line between data model and implem= entation is blurry with YANG=C2=A0+ extensions.
Most of us want Y= ANG data to be independent of the encoding format.

=C2=A0
Thanks,
Acee

Andy
=C2=A0

=EF=BB=BFOn 4/2/21, 12:14 PM, "netmod on behalf of Tony Li" <<= a href=3D"mailto:netmod-bounces@ietf.org" target=3D"_blank">netmod-bounces@= ietf.org on behalf of tony.li@tony.li> wrote:


=C2=A0 =C2=A0 Hi Lada,

=C2=A0 =C2=A0 Thanks for your reply.=C2=A0 At heart, I guess I=E2=80=99m as= king a more fundamental question: is YANG intended as a data modelling lang= uage or as a data structure modelling language?

=C2=A0 =C2=A0 Your reply suggests the former: structure is irrelevant to YA= NG.=C2=A0 If that=E2=80=99s true, then what=E2=80=99s the point in =E2=80= =98position=E2=80=99?=C2=A0 And why do you need =E2=80=98bits=E2=80=99 when= you have =E2=80=98binary=E2=80=99?

=C2=A0 =C2=A0 Confused,
=C2=A0 =C2=A0 Tony


=C2=A0 =C2=A0 > On Apr 2, 2021, at 1:27 AM, Ladislav Lhotka <ladislav.lhotka@nic.cz= > wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Tony Li <tony.li@tony.li> writes:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> Hi,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I have some basic questions about YANG. I=E2=80=99m = pretty certain this is NOT the right place to ask them, so please feel free= to redirect me.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> 1) Is there a way to define the width of an enumerat= ion?=C2=A0 Suppose I had an enumeration that was in a 16 bit field, how do = I describe that?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In the description, if necessary. However, this should b= e an implementation detail, as long as the underlying numeric type can acco= mmodate all enums.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > You could perhaps also define and enum for the highest p= ossible value and make in reserved.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> 2) How do I model a non-octet sized multi-bit field?= =C2=A0 For example, if there is a 5 bit numeric value as part of some =E2= =80=98bits=E2=80=99?=C2=A0 Position only takes a single value, I can=E2=80= =99t really say =E2=80=98position 3-7=E2=80=99.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In this case, I would question whether the 'bits'= ; type is really appropriate. It might be useful to split the value into mu= ltiple items in YANG.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lada
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Thanks,
=C2=A0 =C2=A0 >> Tony
=C2=A0 =C2=A0 >> _______________________________________________
=C2=A0 =C2=A0 >> netmod mailing list
=C2=A0 =C2=A0 >> netmod@ietf.org
=C2=A0 =C2=A0 >> https://www.ietf.org/mailman/list= info/netmod
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 > Ladislav Lhotka
=C2=A0 =C2=A0 > Head, CZ.NIC Labs
=C2=A0 =C2=A0 > PGP Key ID: 0xB8F92B08A9F76C67

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 netmod mailing list
=C2=A0 =C2=A0 netmod@i= etf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/net= mod

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000076c76705bf014ec6-- From nobody Fri Apr 2 12:11:29 2021 Return-Path: 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 155673A2009 for ; Fri, 2 Apr 2021 12:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Tjafm-p57n60 for ; Fri, 2 Apr 2021 12:11:23 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC4A3A2006 for ; Fri, 2 Apr 2021 12:11:23 -0700 (PDT) Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FBqQv6RTdzyY7; Fri, 2 Apr 2021 21:11:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <00A512EB-3F4F-4D6C-893D-5E5769EB888E@tony.li> Date: Fri, 2 Apr 2021 21:11:19 +0200 Cc: Ladislav Lhotka , netmod@ietf.org X-Mao-Original-Outgoing-Id: 639083479.352264-9104446864c8034aedd87194233409b9 Content-Transfer-Encoding: quoted-printable Message-Id: <2DC51A9A-B7CD-454B-9551-AA933ED89098@tzi.org> References: <877dllt7jm.fsf@nic.cz> <00A512EB-3F4F-4D6C-893D-5E5769EB888E@tony.li> To: Tony Li X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netmod] YANG questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 19:11:28 -0000 On 2021-04-02, at 18:14, Tony Li wrote: >=20 > Thanks for your reply. At heart, I guess I=E2=80=99m asking a more = fundamental question: is YANG intended as a data modelling language or = as a data structure modelling language? I can=E2=80=99t answer that, but I can point out that YANG is easily = extended by representation-level attributes: https://datatracker.ietf.org/doc/html/draft-petrov-t2trg-youpi-01 Of course, there is also CDDL = (https://www.rfc-editor.org/rfc/rfc8610.html). Over in ASDF, we are also discussing =E2=80=9Cmapping files=E2=80=9D for = SDF as a way to bind the abstract data model into something more = concrete. Finally, there is a non-WG mailing list for formal description = techniques, fdt@ietf.org. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 2 12:49:40 2021 Return-Path: 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 395C53A2141; Fri, 2 Apr 2021 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=cesnet.cz 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 qrf9f33TK5Gg; Fri, 2 Apr 2021 12:49:30 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0750A3A213C; Fri, 2 Apr 2021 12:49:29 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 18C2A60088; Fri, 2 Apr 2021 21:49:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617392965; bh=9oemDNenWsWvOamzYnrH4Sl9xT/sqxZ5MLVCZhKvIow=; h=From:In-Reply-To:Date:Cc:To:Subject; b=03UPHwVBvU4VoXQlWgTAUsGfukckahcotd4/gwARcFbCfVeAf2g02djViYHN/HAxj KS8xIMmF9yJ0wx5FgQslZPl7RnZH6QFsHN7Xq/RhuaseHR2rYFFRezpnqwuarZZofY XBuqy2DyVJONvXSO32zlPiNMZRh9GWRXHAfoGCxs= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Fri, 02 Apr 2021 21:49:25 +0200 Cc: "netconf" , "netmod" To: "Eric Voit (evoit)" MIME-Version: 1.0 Message-ID: <5830-60677580-9-1569b540@260964559> User-Agent: SOGoMail 5.0.1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?=5Bnetconf=5D_YANG_Push_module_errors?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 19:49:35 -0000 Hi Eric, thanks for the answer. On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" wrote: > Hi Michal, > > This sounds like a tooling issue to me. I would expect that any augm= ents > would inherit the conditional nature of anything augmented. Perhaps, but there is nothing in the specification to hint this. On the= contrary, leafrefs, for example, explicitly require to be conditional = on the same set of if-features than their targets. But you are right, t= here is no such requirements for augments. Still, if the feature is dis= abled and the augment should be applied, since its target does not tech= nically exist in the schema, it cannot be found. That is the error our = tools currently produce. > If you disagree, perhaps a thread to the netmod alias would get you a= n > 'official' answer on the proper behavior. I have sent the email to "netconf" because that is WG that published it= but no harm in adding a copy for "netmod". > Eric > > > -----Original Message----- > > From: netconf On Behalf Of Michal Va=C5=A1= ko > > Sent: Thursday, April 1, 2021 11:14 AM > > To: netconf > > Subject: [netconf] YANG Push module errors > > > > Hi, > > > > we are led to believe there is an error in the ietf-yang-push modul= e > published in > > RFC 8641 but I wanted to discuss it here before submitting an errat= a. > There are 2 > > augments [1] on a notification that is conditional on "configured" = feature > but > > these 2 augments are not conditional. Having this feature disabled,= we > were not > > able to load this module into our tools. Does anyone disagree with = this or > with > > submitting an errata? > > > > Regards, > > Michal > > > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Apr 2 13:18:32 2021 Return-Path: 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 C08AF3A2219 for ; Fri, 2 Apr 2021 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 T1RxSJeUoiWi for ; Fri, 2 Apr 2021 13:18:26 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 C416A3A221A for ; Fri, 2 Apr 2021 13:18:25 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id r20so6647101ljk.4 for ; Fri, 02 Apr 2021 13:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4IyyCK1jmtrdzgxZMKl/8liXdCyy51e7g2XijYTc3bY=; b=JkKNQ+/kaOXv4ofn1M9huFIEFKjfkTjkaJRxHxtQ5MDh5BhJNzeu9PC1sAEzhBZs6e h1lhT41AUlW/qvJwnt3LxvYMmoBbmXtm5PDQpyXzWyxdhFDaOT8RHk+Qt8kDzmurMg75 PgwilXwonnnGVTHtgpCpyK4WBmD+a7PT1sox8ei2PB7+GaZQFDOzIuk8uzmLyjff21A8 l8n+xMVuon1OTM3mYb4OABtLMB9IVxH5uNoA0npyl6HF7EF3Uu3DkGiLzkUdG3SGhDhH vHULGkOz0cUeVwVmv+qspJusYir4XWR5QC2y8y96b7RyBDi0paoMvfROCoS1XOWZBMcb XGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4IyyCK1jmtrdzgxZMKl/8liXdCyy51e7g2XijYTc3bY=; b=CvsW/PtTaf6YYFwuF9HQC50mRZwb9JS7Kifbj4KmKkruBCaEpJMQkrrnE1K4Y2YiXr AE+hToKpzaxMVt9YJJsAbQyP+15lLFff5fxLsBv8vyM2WZd03UbfB3Vabe5HCAgNTXi9 vfFcjqiutECyLc81ldJyTYhPjQiEXTCp0+4+xpPlWcbZ9+lq1LQ/NUM98Lzn7JoGDL/I JKLdoaZdiGPlf49bY6drw0Wjqbz5IKliVBDhuBHI6432pP5tVJfFCjMYJoNGu3+xI64s vKTZ7kRTe44AQ1igM9uslvZzMoJLuUAJjp4ISEWYyl5NOTM51JqiG20rveXiyTyn7c1u N8Ow== X-Gm-Message-State: AOAM533flcmwTUfPEaztO8mozb6wUZdDBWjeoVe40vNSnAJvpmRyeUsz 3QuE9OKHs0V+7y0Y1emr6PFlwAuBP6enRNz7pIw8yA== X-Google-Smtp-Source: ABdhPJzD88TtHqHGalaeA7DjyDXCbv9TpKIwIkHVq/CdIv2rDniTpoERkPWYoS9nrsgx00fjgCfoSAQHWHbRvpmJ2C8= X-Received: by 2002:a2e:2c0d:: with SMTP id s13mr9073566ljs.105.1617394701988; Fri, 02 Apr 2021 13:18:21 -0700 (PDT) MIME-Version: 1.0 References: <5830-60677580-9-1569b540@260964559> In-Reply-To: <5830-60677580-9-1569b540@260964559> From: Andy Bierman Date: Fri, 2 Apr 2021 13:18:11 -0700 Message-ID: To: =?UTF-8?Q?Michal_Va=C5=A1ko?= Cc: "Eric Voit (evoit)" , netconf , netmod Content-Type: multipart/alternative; boundary="000000000000ac893d05bf030ce5" Archived-At: Subject: Re: [netmod] [netconf] YANG Push module errors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 20:18:31 -0000 --000000000000ac893d05bf030ce5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko wrote: > Hi Eric, > > thanks for the answer. > > On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" > wrote: > > > Hi Michal, > > > > This sounds like a tooling issue to me. I would expect that any augmen= ts > > would inherit the conditional nature of anything augmented. > > Perhaps, but there is nothing in the specification to hint this. On the > contrary, leafrefs, for example, explicitly require to be conditional on > the same set of if-features than their targets. But you are right, there = is > no such requirements for augments. Still, if the feature is disabled and > the augment should be applied, since its target does not technically exis= t > in the schema, it cannot be found. That is the error our tools currently > produce. > > Maybe this is not clear enough in RFC 7950. This seems valid: container foo { if-feature X; leaf bar { type string; } } augment /foo { container Y; } The YANG syntax validation should be done as if all features are enabled. It is a tooling issue if this is rejected. This is clear because the augment-stmt argument specifies a schema node. Another related issue: container zed { leaf baz { type leafref { path /foo/bar; } } } This example is not clear because the path-stmt argument specifies a data node. Is it also valid YANG to have a leafref in an unconditional leaf point at an if-feature conditional leaf? Does leaf baz need "if-feature X" added? Is this a syntax error? A run-time error? Neither? Is it invalid or does leaf /zed/baz simply have an empty value set? Is it OK for a leafref node to have an empty value set? This corner case keeps coming up in real YANG modules so it would be great if the standard clarified this behavior. Andy > > If you disagree, perhaps a thread to the netmod alias would get you an > > 'official' answer on the proper behavior. > > I have sent the email to "netconf" because that is WG that published it > but no harm in adding a copy for "netmod". > > > Eric > > > > > -----Original Message----- > > > From: netconf On Behalf Of Michal Va=C5=A1= ko > > > Sent: Thursday, April 1, 2021 11:14 AM > > > To: netconf > > > Subject: [netconf] YANG Push module errors > > > > > > Hi, > > > > > > we are led to believe there is an error in the ietf-yang-push module > > published in > > > RFC 8641 but I wanted to discuss it here before submitting an errata. > > There are 2 > > > augments [1] on a notification that is conditional on "configured" > feature > > but > > > these 2 augments are not conditional. Having this feature disabled, w= e > > were not > > > able to load this module into our tools. Does anyone disagree with > this or > > with > > > submitting an errata? > > > > > > Regards, > > > Michal > > > > > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000ac893d05bf030ce5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 2, 2021 at 12:49 PM Micha= l Va=C5=A1ko <mvasko@cesnet.cz&g= t; wrote:
Hi Eri= c,

thanks for the answer.

On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" <evoit@cisco.com> w= rote:

> Hi Michal,
>
> This sounds like a tooling issue to me.=C2=A0 I would expect that any = augments
> would inherit the conditional nature of anything augmented.=C2=A0

Perhaps, but there is nothing in the specification to hint this. On the con= trary, leafrefs, for example, explicitly require to be conditional on the s= ame set of if-features than their targets. But you are right, there is no s= uch requirements for augments. Still, if the feature is disabled and the au= gment should be applied, since its target does not technically exist in the= schema, it cannot be found. That is the error our tools currently produce.=


Maybe this is not clear enough in RFC = 7950.

This seems valid:

= =C2=A0 =C2=A0 container foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-featu= re X;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf bar { type string; }
=
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 augment /foo {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 container Y;
=C2=A0 =C2=A0 = }

The YANG syntax validation should be done as if = all features are enabled.
It is a tooling issue if=C2=A0this is r= ejected. This is clear because the augment-stmt
argument specifie= s a schema node.

Another related issue:
=
=C2=A0 =C2=A0container zed {
=C2=A0 =C2=A0 =C2=A0 = leaf baz {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref = {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path /foo/bar;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2= =A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 }


<= /div>
This example is not clear because the=C2=A0path-stmt argument spe= cifies a data node.

Is it also valid YANG to have = a leafref in an unconditional leaf point at an if-feature conditional=C2=A0= leaf?
Does leaf baz need "if-feature X" added?
Is this a syntax error? A run-time error?=C2=A0 Neither?
Is it = invalid or does leaf /zed/baz simply have an empty value set?
Is = it OK for a leafref node to have an empty value set?

This corner case=C2=A0keeps coming up in real YANG modules so it would b= e great
if the standard clarified this behavior.


Andy

=C2=A0
> If you disagree, perhaps a thread to the netmod alias would get you an=
> 'official' answer on the proper behavior.

I have sent the email to "netconf" because that is WG that publis= hed it but no harm in adding a copy for "netmod".

> Eric
>
> > -----Original Message-----
> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Michal Va=C5= =A1ko
> > Sent: Thursday, April 1, 2021 11:14 AM
> > To: netconf <netconf@ietf.org>
> > Subject: [netconf] YANG Push module errors
> >
> > Hi,
> >
> > we are led to believe there is an error in the ietf-yang-push mod= ule
> published in
> > RFC 8641 but I wanted to discuss it here before submitting an err= ata.
> There are 2
> > augments [1] on a notification that is conditional on "confi= gured" feature
> but
> > these 2 augments are not conditional. Having this feature disable= d, we
> were not
> > able to load this module into our tools. Does anyone disagree wit= h this or
> with
> > submitting an errata?
> >
> > Regards,
> > Michal
> >
> > [1] https://tools.ietf.org/html/rfc8641#page-= 48 and the next page
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000ac893d05bf030ce5-- From nobody Sat Apr 3 06:08:09 2021 Return-Path: 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 93D073A0B8A; Sat, 3 Apr 2021 06:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 uYfByeKEnVaw; Sat, 3 Apr 2021 06:07:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D403A0B6C; Sat, 3 Apr 2021 06:07:57 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id CA9B0140072; Sat, 3 Apr 2021 15:07:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1617455269; bh=SplQ8u1KnCCg20lfrULrKwd+0xhNCoGxypzeIztTBNI=; h=From:To:Date; b=tePl5TO/sA02dcSt6oYG5doA1p/7473vWZbY8HCgFlXtvVbioZ02UsZmbLWQNO24E cnuu4v0uWyHV/cc2BQXSVow3JHb/inTwRiLjDnJwFkL6QFgkGJeOC1HwBpZ24PY/Wj rlEuFnztt8yh+UnqTr2cUxHWnjNhBqib+7sVGXic= From: Ladislav Lhotka To: Andy Bierman , Michal =?utf-8?Q?Va=C5=A1ko?= Cc: "Eric Voit (evoit)" , netconf , netmod In-Reply-To: References: <5830-60677580-9-1569b540@260964559> Mail-Followup-To: Andy Bierman , Michal =?utf-8?Q?Va?= =?utf-8?Q?=C5=A1ko?= , "Eric Voit (evoit)" , netconf , netmod Date: Sat, 03 Apr 2021 15:07:48 +0200 Message-ID: <878s5ztt23.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] [netconf] YANG Push module errors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2021 13:08:04 -0000 Andy Bierman writes: > On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko wrot= e: > >> Hi Eric, >> >> thanks for the answer. >> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" >> wrote: >> >> > Hi Michal, >> > >> > This sounds like a tooling issue to me. I would expect that any augme= nts >> > would inherit the conditional nature of anything augmented. >> >> Perhaps, but there is nothing in the specification to hint this. On the >> contrary, leafrefs, for example, explicitly require to be conditional on >> the same set of if-features than their targets. But you are right, there= is >> no such requirements for augments. Still, if the feature is disabled and >> the augment should be applied, since its target does not technically exi= st >> in the schema, it cannot be found. That is the error our tools currently >> produce. >> >> > Maybe this is not clear enough in RFC 7950. > > This seems valid: > > container foo { > if-feature X; > leaf bar { type string; } > } > > augment /foo { > container Y; > } > > The YANG syntax validation should be done as if all features are enabled. > It is a tooling issue if this is rejected. This is clear because the > augment-stmt argument specifies a schema node. Agreed. > > Another related issue: > > container zed { > leaf baz { > type leafref { > path /foo/bar; > } > } > } This is not permitted, see section 9.9 in RFC 7950: If the leaf that the leafref refers to is conditional based on one or more features (see Section 7.20.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features. Lada > > > This example is not clear because the path-stmt argument specifies a data > node. > > Is it also valid YANG to have a leafref in an unconditional leaf point at > an if-feature conditional leaf? > Does leaf baz need "if-feature X" added? > Is this a syntax error? A run-time error? Neither? > Is it invalid or does leaf /zed/baz simply have an empty value set? > Is it OK for a leafref node to have an empty value set? > > This corner case keeps coming up in real YANG modules so it would be great > if the standard clarified this behavior. > > > Andy > > > >> > If you disagree, perhaps a thread to the netmod alias would get you an >> > 'official' answer on the proper behavior. >> >> I have sent the email to "netconf" because that is WG that published it >> but no harm in adding a copy for "netmod". >> >> > Eric >> > >> > > -----Original Message----- >> > > From: netconf On Behalf Of Michal Va=C5= =A1ko >> > > Sent: Thursday, April 1, 2021 11:14 AM >> > > To: netconf >> > > Subject: [netconf] YANG Push module errors >> > > >> > > Hi, >> > > >> > > we are led to believe there is an error in the ietf-yang-push module >> > published in >> > > RFC 8641 but I wanted to discuss it here before submitting an errata. >> > There are 2 >> > > augments [1] on a notification that is conditional on "configured" >> feature >> > but >> > > these 2 augments are not conditional. Having this feature disabled, = we >> > were not >> > > able to load this module into our tools. Does anyone disagree with >> this or >> > with >> > > submitting an errata? >> > > >> > > Regards, >> > > Michal >> > > >> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page >> > > >> > > _______________________________________________ >> > > netconf mailing list >> > > netconf@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 5 07:23:48 2021 Return-Path: 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 784343A1AC0; Mon, 5 Apr 2021 07:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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=cesnet.cz 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 02lnaB9DT4b8; Mon, 5 Apr 2021 07:23:37 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B713A1ABF; Mon, 5 Apr 2021 07:23:36 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 5A37060086; Mon, 5 Apr 2021 16:23:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617632614; bh=sqRIyi3TaHbmA29HI9qsROUlY3383gNY8XFCPcUrGYs=; h=From:In-Reply-To:Date:Cc:To:Subject; b=W6XVCGT163NM2ScvZI0jgf8Mq6G0KbnjBgcMYFs1rNQ4n3XWtRAe3k8wbjcU1rUc/ mdf6o8Klec/PZ6HioV2ebaulONqK2YQgHaCuI4uekw5xsZdD4+U+x3cIFx4NwQMZV5 3raMw6/ZPgtNDsPXIDSaw8UMjTWF/yJX+qfgG0dg= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <878s5ztt23.fsf@nic.cz> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Mon, 05 Apr 2021 16:23:34 +0200 Cc: "Andy Bierman" , "Eric Voit (evoit)" , "netconf" , "netmod" To: "Ladislav Lhotka" MIME-Version: 1.0 Message-ID: <52f2-606b1d80-d-7afd9d00@152658395> User-Agent: SOGoMail 5.0.1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?q?=5Bnetconf=5D_YANG_Push_module_errors?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 14:23:43 -0000 On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko wrote: > > > >> Hi Eric, > >> > >> thanks for the answer. > >> > >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" > >> wrote: > >> > >> > Hi Michal, > >> > > >> > This sounds like a tooling issue to me. I would expect that any= augments > >> > would inherit the conditional nature of anything augmented. > >> > >> Perhaps, but there is nothing in the specification to hint this. O= n the > >> contrary, leafrefs, for example, explicitly require to be conditio= nal on > >> the same set of if-features than their targets. But you are right,= there is > >> no such requirements for augments. Still, if the feature is disabl= ed and > >> the augment should be applied, since its target does not technical= ly exist > >> in the schema, it cannot be found. That is the error our tools cur= rently > >> produce. > >> > >> > > Maybe this is not clear enough in RFC 7950. > > > > This seems valid: > > > > container foo { > > if-feature X; > > leaf bar { type string; } > > } > > > > augment /foo { > > container Y; > > } > > > > The YANG syntax validation should be done as if all features are en= abled. > > It is a tooling issue if this is rejected. This is clear because th= e > > augment-stmt argument specifies a schema node. > > Agreed. I see. Okay, thanks for the clarification and yes, if this was explicit= ly mentioned in the RFC it would be great. Although, the validity of yo= ur example was not in question. Rather something like: container foo { if-feature X; container bar; } augment /foo/bar { container Y; } I am just going to assume this is what you meant and simply that the re= quirement is that any schema path must point to an existing schema node= , ignoring any "if-feature" statements. Regards, Michal > > > > Another related issue: > > > > container zed { > > leaf baz { > > type leafref { > > path /foo/bar; > > } > > } > > } > > This is not permitted, see section 9.9 in RFC 7950: > > If the leaf that the leafref refers to is conditional based on one= or > more features (see Section 7.20.2), then the leaf with the leafref= > type MUST also be conditional based on at least the same set of > features. > > Lada > > > > > > > This example is not clear because the path-stmt argument specifies = a data > > node. > > > > Is it also valid YANG to have a leafref in an unconditional leaf po= int at > > an if-feature conditional leaf? > > Does leaf baz need "if-feature X" added? > > Is this a syntax error? A run-time error? Neither? > > Is it invalid or does leaf /zed/baz simply have an empty value set?= > > Is it OK for a leafref node to have an empty value set? > > > > This corner case keeps coming up in real YANG modules so it would b= e great > > if the standard clarified this behavior. > > > > > > Andy > > > > > > > >> > If you disagree, perhaps a thread to the netmod alias would get = you an > >> > 'official' answer on the proper behavior. > >> > >> I have sent the email to "netconf" because that is WG that publish= ed it > >> but no harm in adding a copy for "netmod". > >> > >> > Eric > >> > > >> > > -----Original Message----- > >> > > From: netconf On Behalf Of Michal V= a=C5=A1ko > >> > > Sent: Thursday, April 1, 2021 11:14 AM > >> > > To: netconf > >> > > Subject: [netconf] YANG Push module errors > >> > > > >> > > Hi, > >> > > > >> > > we are led to believe there is an error in the ietf-yang-push = module > >> > published in > >> > > RFC 8641 but I wanted to discuss it here before submitting an = errata. > >> > There are 2 > >> > > augments [1] on a notification that is conditional on "configu= red" > >> feature > >> > but > >> > > these 2 augments are not conditional. Having this feature disa= bled, we > >> > were not > >> > > able to load this module into our tools. Does anyone disagree = with > >> this or > >> > with > >> > > submitting an errata? > >> > > > >> > > Regards, > >> > > Michal > >> > > > >> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next p= age > >> > > > >> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F > >> > > netconf mailing list > >> > > netconf@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/netconf > >> > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > >> netconf mailing list > >> netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 6 00:05:12 2021 Return-Path: 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 623603A11ED; Tue, 6 Apr 2021 00:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 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_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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=nic.cz 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 cG8sGS-LMx8y; Tue, 6 Apr 2021 00:05:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282DB3A11EB; Tue, 6 Apr 2021 00:05:02 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 98932140881; Tue, 6 Apr 2021 09:04:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1617692693; bh=ZIUE2K+GMNXuALNM53mDy2SrzcZsI47o5/7KPl7AcSs=; h=From:To:Date; b=UXGsNBRv7ZgiBZ9FYUfW/vJ4kGWrtsIN+iDP3vAg7VJ5SEJFaXoRFHbpKjGXi7BxS 6SHg4nbLvTgXCHwyDtEceG+aF1D5RjpkCWKjJqIbYy60cCoLjMvSc6SVMTf8mdQGCz ht66KmQ1sD5s3izDtOTXIi6w5yfvS83gfcvgzWuo= From: Ladislav Lhotka To: Michal =?utf-8?Q?Va=C5=A1ko?= Cc: Andy Bierman , "Eric Voit (evoit)" , netconf , netmod In-Reply-To: <52f2-606b1d80-d-7afd9d00@152658395> References: <52f2-606b1d80-d-7afd9d00@152658395> Mail-Followup-To: Michal =?utf-8?Q?Va=C5=A1ko?= , Andy Bierman , "Eric Voit (evoit)" , netconf , netmod Date: Tue, 06 Apr 2021 09:04:53 +0200 Message-ID: <87wntf3nca.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] [netconf] YANG Push module errors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 07:05:09 -0000 Michal Va=C5=A1ko writes: > On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka wrote:=20 >=20=20 >> Andy Bierman writes: >>=20 >> > On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko w= rote: >> > >> >> Hi Eric, >> >> >> >> thanks for the answer. >> >> >> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" >> >> wrote: >> >> >> >> > Hi Michal, >> >> > >> >> > This sounds like a tooling issue to me. I would expect that any au= gments >> >> > would inherit the conditional nature of anything augmented. >> >> >> >> Perhaps, but there is nothing in the specification to hint this. On t= he >> >> contrary, leafrefs, for example, explicitly require to be conditional= on >> >> the same set of if-features than their targets. But you are right, th= ere is >> >> no such requirements for augments. Still, if the feature is disabled = and >> >> the augment should be applied, since its target does not technically = exist >> >> in the schema, it cannot be found. That is the error our tools curren= tly >> >> produce. >> >> >> >> >> > Maybe this is not clear enough in RFC 7950. >> > >> > This seems valid: >> > >> > container foo { >> > if-feature X; >> > leaf bar { type string; } >> > } >> > >> > augment /foo { >> > container Y; >> > } >> > >> > The YANG syntax validation should be done as if all features are enabl= ed. >> > It is a tooling issue if this is rejected. This is clear because the >> > augment-stmt argument specifies a schema node. >>=20 >> Agreed. > > I see. Okay, thanks for the clarification and yes, if this was explicitly= mentioned in the RFC it would be great. Although, the validity of your exa= mple was not in question. Rather something like: > > container foo { > if-feature X; > container bar; > } > > augment /foo/bar { > container Y; > } > > I am just going to assume this is what you meant and simply that the requ= irement is that any schema path must point to an existing schema node, igno= ring any "if-feature" statements. I think it also depends on whether features are set before or after process= ing the modules. In the former case, an augment statement with an effective= ly missing target node can IMO be silently ignored, without even parsing it= s contents. Lada > > Regards, > Michal > >> > >> > Another related issue: >> > >> > container zed { >> > leaf baz { >> > type leafref { >> > path /foo/bar; >> > } >> > } >> > } >>=20 >> This is not permitted, see section 9.9 in RFC 7950: >>=20 >> If the leaf that the leafref refers to is conditional based on one or >> more features (see Section 7.20.2), then the leaf with the leafref >> type MUST also be conditional based on at least the same set of >> features. >>=20 >> Lada >>=20 >> > >> > >> > This example is not clear because the path-stmt argument specifies a d= ata >> > node. >> > >> > Is it also valid YANG to have a leafref in an unconditional leaf point= at >> > an if-feature conditional leaf? >> > Does leaf baz need "if-feature X" added? >> > Is this a syntax error? A run-time error? Neither? >> > Is it invalid or does leaf /zed/baz simply have an empty value set? >> > Is it OK for a leafref node to have an empty value set? >> > >> > This corner case keeps coming up in real YANG modules so it would be g= reat >> > if the standard clarified this behavior. >> > >> > >> > Andy >> > >> > >> > >> >> > If you disagree, perhaps a thread to the netmod alias would get you= an >> >> > 'official' answer on the proper behavior. >> >> >> >> I have sent the email to "netconf" because that is WG that published = it >> >> but no harm in adding a copy for "netmod". >> >> >> >> > Eric >> >> > >> >> > > -----Original Message----- >> >> > > From: netconf On Behalf Of Michal Va= =C5=A1ko >> >> > > Sent: Thursday, April 1, 2021 11:14 AM >> >> > > To: netconf >> >> > > Subject: [netconf] YANG Push module errors >> >> > > >> >> > > Hi, >> >> > > >> >> > > we are led to believe there is an error in the ietf-yang-push mod= ule >> >> > published in >> >> > > RFC 8641 but I wanted to discuss it here before submitting an err= ata. >> >> > There are 2 >> >> > > augments [1] on a notification that is conditional on "configured" >> >> feature >> >> > but >> >> > > these 2 augments are not conditional. Having this feature disable= d, we >> >> > were not >> >> > > able to load this module into our tools. Does anyone disagree with >> >> this or >> >> > with >> >> > > submitting an errata? >> >> > > >> >> > > Regards, >> >> > > Michal >> >> > > >> >> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page >> >> > > >> >> > > _______________________________________________ >> >> > > netconf mailing list >> >> > > netconf@ietf.org >> >> > > https://www.ietf.org/mailman/listinfo/netconf >> >> >> >> _______________________________________________ >> >> netconf mailing list >> >> netconf@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 6 07:10:20 2021 Return-Path: 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 1A68A3A2282 for ; Tue, 6 Apr 2021 07:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 VKAUSXmNm48N for ; Tue, 6 Apr 2021 07:10:14 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2099.outbound.protection.outlook.com [40.107.93.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781313A22A3 for ; Tue, 6 Apr 2021 07:10:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mgsnzeKN6l4HrXo0OnoiLUF+NmEigJfP6m9H6N7zKDaFNHwUN6ZOtIICB1+Yc16jb1unq6Syb2Xcvzx+DfmUvlEyXZGIjqACunn4mVdDrl5QfRN2eTT+KfNCVoFDr3bGyEeID366n5sZArDhRuqnityiNhb25kjVTTck+2hpjydICAMAYFugeZ26YxtfsV3/Jixn6QNfHJqa9U5VBWK52YzIKhj9Q0bH/U2icgFQExTw5RGtL4uBrBAn7o5YWhPjqiqec9rw4nQt+95fkbICaBF5tDJfJZYgCKWyKA0mMgrsh7+5749/FNxMNvvVZ83vK5THkegNCjNM7Nv9vZoK4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j/AU/kEN7OMLqwHabb6ezhwUXh4DGZ7N/cQwgWlbKZc=; b=mlIiO6CoVOHmqyTxQDFA3Ikw2pnbARZWPLbuoRtlslouap9xiJ8dtsV3/0PvCv5lq/PgCTVR0UL35RWJqmK9Vm8aKjxQQJ1Xa9Hgp/XkEgpj2eDsqCIB4HbGXInwRZ/ID9OUbBmJvebyY1tFrzsYv1GUvw0JQabWMysIs9LRkCh+8jz1MYztkeN49F0xCGAe/wksNEC9GWoNhmsRp18TP9VqaFvA7coue3f2lAla6OQbFvU4/vO5LrMxSrzNp0ff7WN0Jk7XuLujRJqjna3XE+2OXgEuAl+biZU7CYWYHBCBpPrXS6oJeiWlG+FXxO0iu2xatkh+C1oZ+LtRkGR7Dg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j/AU/kEN7OMLqwHabb6ezhwUXh4DGZ7N/cQwgWlbKZc=; b=Ke+UU/opVU821mwPS+PzitanyLf2cElKMEnvevnmkN+relUbocWRmrrALFoIOebUcWfOWfpfkDQxE+bfCepH4W3weJ45r1+ehDDFG1jDQhvakpLJrRUVjnpE8huBF0wQ2jURk662g5VzNKwARTTBBYK7q4T9QP3Y24t2VhtXrqI= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6265.namprd08.prod.outlook.com (2603:10b6:5:1e9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.28; Tue, 6 Apr 2021 14:10:09 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3999.032; Tue, 6 Apr 2021 14:10:09 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-04-06 Thread-Index: Adcq7mSeZZlldAiUQ6GtRUaZNtbWWQ== Date: Tue, 6 Apr 2021 14:10:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:f2c0:e4ae:97:7924:db2d:af39:e5d3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c52fd79c-1367-4691-94c4-08d8f905b012 x-ms-traffictypediagnostic: DM6PR08MB6265: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Be9NlL4+pAFZ0nVAN4dwiJzk4MxUBVphlaGrKZ8xkRnlnjrjy0lLUMf/ClQ9fY8nrVyy0qkqV974M5teBj3Rf3c3XKl34+PqHngLAiA/VSc/rJWbCEFb3oB2Ck5cFrooXIbOhpP8oIDHlbyZHqfCc7M9paE6ZVbsnAf5fP0oENTT/QQTfqWGyXV6bERk9mTh07BykzQJa8E+H196qI+xkHaGWCgL170DuFf5P3wGb0uY/jY0uuGrKF0ZE4xGnu7PihgK/z03z/Lp67rhrpIuH4yu2KIpX1cJLMqI0NSIk3xrTOw2BeGXeKyBV4u5f44vbBOcfmcIV9SgZCNCvFNhAXL4eqFDA949N4fkGdtilrPs/OPHM9we2d2sLvU/OTeGbUCnNTmRQq/V+GJ9udGxrzKf4xfIX35yjOexK4Tgp9RppHkMQSySaAGCQiJMqCXYa/646Sk79ABC+T18mDid9obPzEqOQCN/o1L8HnGkpVet0V1GHfM/Jb7I6TsO8DkZDqOw+OQ5H6x9gyqugqI2bXwSB2MbeLXUAeQYks74bmIx5j/VywcgSZdQTJVhE/RQdPbZxXoHNsPlgSHVP1R/SXpO/c7hs6GEj3FX+F4Rglg0tMXroXCTpv+XowB7XSjTvKDpb69C/QzDW2ZcxqZ2UMQBjqQDDDBmdgBQ9EUeguDBeuw40E/bq/aqbEzuOhijNW9E4XzD9FjOizg9Lxvdzgw8GW1AiLNpI+n0hN7P9iE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(376002)(39850400004)(396003)(366004)(966005)(7696005)(478600001)(186003)(2906002)(6506007)(5660300002)(64756008)(52536014)(66556008)(83380400001)(66946007)(66476007)(38100700001)(6916009)(76116006)(71200400001)(8676002)(8936002)(9686003)(66446008)(316002)(16799955002)(55016002)(86362001)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?j13jNhk/+Xsj0Pd+AQa62sv8MU4jbYk9cSZnac46HE42slJnUGx469h4xr0y?= =?us-ascii?Q?+r6HcTgZ8uAxShxQsqBuYyZ+Vfqyf3+T0Y+qWjB8ZUwvv+nzIZnDAdmL6nKp?= =?us-ascii?Q?G5u39m/SuL5OJnaFI4XjphDOh0JIsq66g2lup5qWaU7le+UeuDjXBaYw16Cv?= =?us-ascii?Q?aitQ2ZzxatmCAli6U94ABDLlh3mlAqhBdbPc2VCMr9C+UampMyaOCTyNWGs4?= =?us-ascii?Q?EBs80zTVJlpSok1RV0MvYO1LukB+yzMT/2jLlzdWK8Zh1bjyfwAfSxO90jPW?= =?us-ascii?Q?ZI+z2u5PRDPc/kJ0UKUBmRrOeLnQR39RgGw47sBxj/QesRVsirfkmtIUmSGY?= =?us-ascii?Q?eQJhsr+HgqE2wiPmHFYqeAlmCNUjhMC6zMQFg3rTXhzMEhY2wsW9ODs0ANyK?= =?us-ascii?Q?uG/FL9Mp6C5C3UQq6TFGiFOFOXUDheA2p93PS0C16b7Mk1pYPbl6WDWYAR6C?= =?us-ascii?Q?lifTeWbN7ok499NzyiPq6TSJAy95RwUmJO8f9xTPr/E+664SPVA/FFcW+cXn?= =?us-ascii?Q?gA1RLmaOELqC63V+VZMlKa5j0F5XjoPpS55qi3afifz4gOq9kCSkNKI4DJPG?= =?us-ascii?Q?+iFH2Fz8g5piejDLEcdUgPNsi1mJrbqz28TGt4C0E4ZRpy8QNiUF0yKIE95x?= =?us-ascii?Q?W+CcKeear8AzxA6xSUc1EuPTqdHVYgUVs24NutN823cODPCGi1YML8j4x6AN?= =?us-ascii?Q?pGlZ2fg/T4Pmif1CnJZBuvkuXdfhSGe8RzO7sac7O1WU0tgeGdnC7bbdO494?= =?us-ascii?Q?YzWV/WXggOuYKy09Y5i22BC+FXwr6hpfeLEAXVYtCygOPlBGq5ar4ip3fqIz?= =?us-ascii?Q?XKtpR4ZZSNtoDaVLr4g5kbLgu2illzLpoJCRjTVKOeENIWp/Jby5HGFLepm+?= =?us-ascii?Q?kYWahE3Z8PSnbVJcTEbztS+9vUNNuuBdxVYqdh0kIbCasF/8wAws6UPZp8KC?= =?us-ascii?Q?cOQI/ilClrcGadQKS42+fcJDTW2mk9jzef9x439UYRUvZdq2skpCQPRoteOC?= =?us-ascii?Q?+t0lVcLcVoGKbtVAvs2OL/2H+XaDKcaMTjTI4ghvzv8O/Zcr+MRXG0UMmZkk?= =?us-ascii?Q?qA1OjY4hsK/1QTt/bZFqy0rdcUMKOL+/4LehsruXliIA/bLoJ6qVyNNCDW+r?= =?us-ascii?Q?DgzJ+T8za7xiV3j8NHqgbd+VlxTlOCbHnlUOpYZrFL7GuNuyy4Kjy+BcbCRV?= =?us-ascii?Q?U9ix5JZjQ8SjsAk7YYrtv6RtqJE5ylAJ03iKiz5fHhiFW8L5v86tfqDFt0QB?= =?us-ascii?Q?b6Oc13NnLWXo1/73LpUDTrzQcKbz7tWynN3piJM9c3i65QbcYaWqkyd8gX/w?= =?us-ascii?Q?hjg84YgJihREYe8kKntObMgxTB1M4qkvEJXXTDuuuzxFcAMH0r/QxlIdmn2b?= =?us-ascii?Q?4O2a1DnJmgUyqNwvd0bObJPQOVru?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB508484D6D957DC8ABAF903959B769DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c52fd79c-1367-4691-94c4-08d8f905b012 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2021 14:10:09.5276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CSH0xKb/rtf/OpCp91jUHPIArQilMmBSSCOlWJU/ddFn4k5GQezb0qywQIjtbBMnH93DWDK8keiexXNeDliBOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6265 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 14:10:19 -0000 --_000_DM6PR08MB508484D6D957DC8ABAF903959B769DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-04-06 Focus for this meeting was going through Jason's review comments for sectio= n "3.1.2 Backwards-compatibility rules for config false and output data" of= https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02. (A) Valuespace: - value space (with a space between the words): use 7950 meaning/definition= (remove the definition in our draft) - make "must" its own bullet - don't particularly address "description" - Balazs propose updated text (B) replace this: "an additional state leaf can easily be discarded" with this: "the presence of an unexpected state leaf is not typically a problem and ma= y be ignored by the client" (C) replace "config=3Dfalse data" in the 1st paragraph with the following (and = keep the quotes - that is how RFC8342 presents it): "config false" data (D) Lots of debate about the "client" bullets in 3.1.2. Didn't conclude. Perh= aps just summarize and say clients need to sanitize data (give examples of = data they might get, values outside range) ACTION: focus on reviewing section 3.1.2 ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB508484D6D957DC8ABAF903959B769DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-04-06

 

Focus for this meeting was going through Jason's rev= iew comments for section "3.1.2 Backwards-compatibility rules for conf= ig false and output data" of https://tools.ietf.org/html/draft-ietf-ne= tmod-yang-module-versioning-02. 

 

(A)

Valuespace:

- value space (with a space between the words): use = 7950 meaning/definition (remove the definition in our draft)

- make "must" its own bullet

- don't particularly address "description"=

- Balazs propose updated text

 

(B)

replace this:

 

"an additional state leaf can easily be discard= ed"

 

with this:

 

"the presence of an unexpected state leaf is no= t typically a problem and may be ignored by the client"

 

(C)

replace "config=3Dfalse data" in the 1st p= aragraph with the following (and keep the quotes - that is how RFC8342 pres= ents it):

         &nb= sp;      "config false" data

 

(D)

Lots of debate about the "client" bullets = in 3.1.2.  Didn't conclude.  Perhaps just summarize and say clien= ts need to sanitize data (give examples of data they might get, values outs= ide range)

 

ACTION: focus on reviewing section 3.1.2<= /p>

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

--_000_DM6PR08MB508484D6D957DC8ABAF903959B769DM6PR08MB5084namp_-- From nobody Wed Apr 7 02:19:31 2021 Return-Path: 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 003A83A1355 for ; Wed, 7 Apr 2021 02:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=i+SKbqNP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MwCcYyZU 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 lza-z6ubXUOA for ; Wed, 7 Apr 2021 02:19:24 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326543A1354 for ; Wed, 7 Apr 2021 02:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21838; q=dns/txt; s=iport; t=1617787164; x=1618996764; h=from:to:subject:date:message-id:mime-version; bh=wztHj+khi8nIwhMg+PnaOTM8vWE2RHCsGMmOjpPw5/8=; b=i+SKbqNP7V8pxZYGzEgXhy9S8TD4NEolUk1XFBdCQMW6w9ak1nz2iXzw Aww9f5SG6frMDzlwdC8OI3OnZHCHVSykTIg+bgDnyQRpBD+YVXSM2T2bo jnFpcG50CXjJZDMNAvk3VBRKFt1H43c4LtbNHwRXIy06j6FhkbdfLVvSE U=; X-IPAS-Result: =?us-ascii?q?A0AYAADPeG1gmJRdJa0+GQMcAQEBAQEBBwEBEgEBBAQBA?= =?us-ascii?q?UCBPgcBAQsBgSIwUX5aNjEKiAADhFlgiFCPKooUgS6BHAMGA1QLAQEBDQEBK?= =?us-ascii?q?ggCBAEBhFACgXcCJTQJDgIDAQEBAwIDAQEBAQEFAQEBAgEGBBQBAQEBAQEBA?= =?us-ascii?q?WiFUA2GRAEBMhMBASQUEQEZBAEBFQQIBDwdBwIBBAESCIJpAYF+VwMvAQMLQ?= =?us-ascii?q?KEAAoofdYE0gQGCBAEBBkZxAoNrGIITAwaBOQGCdYN4D4Jcg3QnHIFJQoETQ?= =?us-ascii?q?4MdgQSBXAEBAgEXgS4HEx8MGgiCHWCCEBuBTwkBgVkDET0CFz8QCxQ/OBY5k?= =?us-ascii?q?GsOBIsejHiRYQqDCwSJX5M8pHGDAoYJhiWFZYtqki4wC4RWAgQCBAUCDgEBB?= =?us-ascii?q?oFUOIFbcBU7gmlQFwIOjh8MDQkVgRmCIIUUhUVzAjYCBgoBAQMJfIlSJAmBB?= =?us-ascii?q?wGBDgEB?= IronPort-PHdr: A9a23:F+THGR8L/jxqff9uWNHoyV9lXQAupqn0MwgJ65Eul7NJdOG58o//O FDEjd1ri1zIVMPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3B oJOAVli+XzoN09WGc+4bFrX8TW+6DcIEUD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3e R63tg7W8MIRhNgKFw== IronPort-HdrOrdr: A9a23:tqUuo6njA4I0q7oVrg90IjFe/4LpDfOVj2dD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1aiui/vXwXsFd3ARV4hL6QBlBgGHVmh/QwdbDZQ0fa Dsm/ZvjTymZHgRc4CHFmAINtKz6uHjubDHRVo9BxAh4BSTlj/A0t7HOjWRwxt2aUI2/Z4M6m 7A+jaJg5mLl9Ge5lvi23TI75JQ8eGRhudrIMCXkMAaJnHNp2+TFf9ccoaPtjw0v+2jgWxC+L KnzntQXLUQ11rqYmq3rRHxsjOQtwoG1n74xVeUxVvlrMDpLQhKcvZpuINDfhPVr3cnpdF3uZ g7uV6xipw/N2KloA3No/zzEz16nEu9pnQv1cQJiWZEbIcYYLhN6aQC4UJ8Cv47bW3HwbFiNN MrINDX5f5Qf1/fRWvepHNTzNulWWl2NguaQ3IFptee31Ft7T5E5npd4PZasmYL9Zo7RZUBzf /DKL5UmLZHSdJTSq5hGuEbQ4+SBnbWSRzBdEKeSG6XVZ0vCjbokdra8b817OaldNgj150pgq nMV1teqCo8YETrBcqS3IBa8xzETWmnNA6dif121txcgPnRVbDrOSqMRBQFiM27ucgSBcXdRr KyNfttcr3eBFqrPbwM8xz1WpFUJ3VbetYSoMwHV1WHpd+OLoXrs+fcYevCPbaFK0dgZkrPRl 84GBTjLsRJ6U6mHlXihgLKZn/rckvjuZRqEKbb+OAXwJMXNpJFtxUUjVjR3LDKFRRy9ogNOG duKrLula224UOs+3zT0mlvMh1BSlpO7K74SHNMrw8SO0byebIO0u/vPVx67T+iHFtSXsnWGA lQqxBL4qqxNYWX3j1nIcmgKHimg3wao2+qQ58QlraY39rsfoo1A/8dKetMPDSOMyYwuA5x7E 9fdQcPRybkZ0/ToJTgqKZROcbyWJ1XhhyxLctdtHTF3H/s2v0Hdz88RD6hUcmenAA0YSFb72 cBtZM3sf6nhSulL3c5jaAeNlBBAV7nWI5uPUCieJhenKztdUVLaVqywRaeix01ZwPRhhwvr2 T8MCyZfuzKCFJBunZelr3n6k9wa3/1RTMPVllq9YJ6DmjIoXB1zKuCYbeyyXKYbh8YzvgaKy ytW0pbHip+g9S23gWSgjCMCDEvwYgvJPXUCN0YAsfu82LoLI2DjqcdGfBIuJ5jKdD1q+cOFe aSYRWcIj+9C+Qn3WWu1z8YETgxrHkvivXz3hL5qGC+wX4kGPLXZE18WKtzGaDo00H0A/KTlJ lph9M8uuW9dm33d96d0KnSKzpOMAnar2K6R/whwKok9p4apf92Bd3WQDHI3HZI0FElIMD4mF gXTa577LrCU7UfCPA6amZc5B4khd6PJEwkvkjqGec4Z0gqlGKeMNWT4bbEwIBfSHGptU/1Ix 2Y/CJc9fueAHfG2r4eFq4qIWNZLEI7829v+eued4vWTAWmHtszj2aSIzu4avtaTqPABLAb6h B96NuMl/WMdyX51BvL1AELVp5m4iKiW4eqHAmIGeRU6NS0NlSHn7uy7KeI/UfKYCr+b15dmJ ZMekMRZNlSkzUujIU41S6pV6z8y3hV4Wd28HVgjV7i2o+v/WfdEwVHKGTi8+RrYQU= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,203,1613433600"; d="scan'208,217";a="690703507" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Apr 2021 09:19:17 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 1379JHmg014462 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 7 Apr 2021 09:19:17 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 7 Apr 2021 04:19:17 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 7 Apr 2021 04:19:16 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 7 Apr 2021 04:19:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QxBj67Yu/Vb/3fY6wv2C7JS359oz+Ibf9eKl6IeildeJs1Brlz6eXFJaV20VabBdbMKLQ8bCIHL0EZOEbg1iMEqlqx4rfEmQI7iN7/Hk7mkP2nTfiToWPCytb8SKjMRoCsJQyI7cYLow7NNfxJ8Ng00VNxSV9vWU7ZghFeirnSdrz/GQP6BetUIMpc0EzQwS8lcP33Mz+DfxV0trZT+Z77mKwRYFJcMs0Re6Xm674GpB64XZkgLgN9mgcIRpgonnbid8n8S+1lKzi6h/g2F8fob1xCL2x5KnmiP3iF7NnmGzJdxX7sH8SWo0UocTnIfR0DJEIgOOlTd6Dhk17CJXYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FGs97D0e8k+PlLctBpgXVJ7kK9IbmivSJZMpfj65+cY=; b=e/hB5cLhYbmm5uvNUm3jzcrIi+MFBzfkPYGUQmYspCOvseNl5llFlnEjOE9dmcG3kLgPCs1JLFTmEiS3G4F5Fn7TZhSWriblBp7d/5TUqlX5Ud0ZknZ9wJDfOzFBcwGJD8orWlfWfbVBWVMPabggmG9mcKZC4fw+BRHbUQUhDaKDmxAfcWVbLt0VyEpS3hnh4olcV6JSQi7VhJwyIYAvpXPNX4p6AopNBgMEqbGtcdgS0AIz//Yx9SBU3RlB2EBK8/q/qbyHDWFmVWCkIAbCBnru5CZZGdgUzQjab5eyuEbt7p4Jb4gOqLQ/8BfOEy9UYPcxHiQRTGXsze3EUybD1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FGs97D0e8k+PlLctBpgXVJ7kK9IbmivSJZMpfj65+cY=; b=MwCcYyZU1s/8M92uQLCU1MOyZ++kTc0chZ8m5fw7veR9+YlbJMTimDtffQLQKVN1kDOE5wjnIx0ydKYQ9rmHSKUrddJNJwYppJ53DJe/RzbO5En47qlDh+CkiSxsx+mjiLYTcvMpO8V5ud+sD5bs1E9zCVuSv1hsMOYE9osOftQ= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3169.namprd11.prod.outlook.com (2603:10b6:208:69::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.32; Wed, 7 Apr 2021 09:19:15 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3999.032; Wed, 7 Apr 2021 09:19:15 +0000 From: "Rob Wilton (rwilton)" To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Thread-Topic: Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] Thread-Index: Adcrjvs0u1Y2kX7cTWaMCLlk2EmADg== Date: Wed, 7 Apr 2021 09:19:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fcdccdf6-d46d-4e6e-0abe-08d8f9a636e5 x-ms-traffictypediagnostic: BL0PR11MB3169: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q6Cgpaypsj4YKEINf2FsYeOI049kXO+Xf9cd6qUPDGSBkviUUO+gpZRbevSJSkEJDSotuoLbLpFIAIf73zVxW9gRxwDpryG972muoVcKxSDBxIEHzyciOopiM7Yo0a0cZvEM393Zq1jR8CyaDW3s3L2yOFIr3KWq1xoFer12/vRBp6BjJTF19Xev9OHlXka/DVHDLEQFVfmmELHvI//ZwxId2JnRBTRscATNhSFUYl2wZB7WEYWlvUl7RqQLAq6YiLQsKq35MyBSKPJClGVZVNsNjEk+pcdppB+vpPVlfS3m7KbREeuNPrqtPHTQZeHDbrVZWEk3LdXK1WlHWwyZIdH3fywIin4KPoVRlQpLHUxTdrfMw36jaSH4AIaCat1AteYB4uGJtElJhMzU98HDkr0/O0nyCancKOzUQ5XCpwLZHPmbfQ9qyON4aAOBM4o9aN4a5x+1PNP0+3KjObbb/mlH1Zgzn98nWvPJDUycwGlJZ08n+9e9TEi+aiL0zAkp2VVrwUaOpTEnG8bjZKk6o7peuby3K3GeCWpnLsbf0iFBAU/PkbRouv44oOORiVwbEcjC07wAfLJdgIvtfxjBJUywsUcd48+YUSSI5h9EnSoMHSLTsrhoLiKpEAIb9RpPdxN8o/dgSMn04SaWpuOwkEusKMyiaTp/wRB5JjPz5a1lNlQF1es4jM/EfoIphVuSMwYH1rVC6ogRh5bPbDqrMToBIh0MBwSn8Q/Wty5cU88= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(136003)(346002)(376002)(366004)(66446008)(66556008)(64756008)(66946007)(2906002)(296002)(66476007)(53546011)(86362001)(6506007)(966005)(8936002)(55016002)(9686003)(52536014)(316002)(8676002)(83380400001)(26005)(478600001)(16799955002)(186003)(38100700001)(110136005)(7696005)(5660300002)(71200400001)(33656002)(166002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?RHP01BloBUfbCNDMuDh6NljPVRcod/f7ELyb2m7InkOIrNnMcU++S8hoMAYh?= =?us-ascii?Q?R8Zls9s+Umsr06+F5D9ua06tznPN5RldAVlYdLK+RcGEBaFLvVMmLdN3k3NR?= =?us-ascii?Q?Y/Uf4OBhdVuHNYcs/o/JqF8YXRfhyPY2te+nco20g55cDrdm1NqhmyeCo2Lz?= =?us-ascii?Q?iT74bZa0bC6/rX7MNsZVIlBFmJF8A4gmFu+JQy7kv0/EuqrwO+h48zORPj7W?= =?us-ascii?Q?Kv1K1/YJ6s0KTeLEUTXpb8ClZ7v+ogqlknlsWDaNHQFznVPecQRw2WahZYiC?= =?us-ascii?Q?eSeudTTaoFB2N/+CDUyCHiTp5GNmGV/RUFUWP6glXvjJ7+zt8i5bQCCPMy2O?= =?us-ascii?Q?01lmJvV9CnlncFXUyBSlqO+87sRJtVIU4N+tx6TvszN0WI8yf4/g3XuTGpTW?= =?us-ascii?Q?+NQvBCQR2EXCfI5JQ/fz1Gs2RTXmgin6mqTm4NFlcdja7UByLxMeoXjYvzgi?= =?us-ascii?Q?ktIj4CQ8zhUn6vuJqxGZPSnoa6qTKPxJ/+qHr8TgOGkChWiz6cLUhR8nskR8?= =?us-ascii?Q?711ileebfeHdS7I+KaMxSK/zafxl5dmGlG5yKRXh6MaAy6t/LBF4KErYCvu9?= =?us-ascii?Q?a+z8lzHH68uA17NAAahyOOHY92vecUllJ4mQys3I+57Ggn0u8PcPb0OzrEMA?= =?us-ascii?Q?FLaJJLRJatHq60Kxu29oSrtqrI5DS9tLXSd8RqkQbohVW3D61wqft/fxGp5Q?= =?us-ascii?Q?KKdMOIJFZv/pZ05c2qymAMrx+X3P90cOIuLGytQRixvQxuKrrQ5etWKwmdj+?= =?us-ascii?Q?2Q5bQnFlV1r5oYneXMzfT/W/1x4jClDw4Y8sFMhR15Qvcv+E7TF8+en93eXD?= =?us-ascii?Q?aNEYbv3B6yWk2MIgwbO6cXVYp5pnXTSTwfvNkFf37FriQ+YrRfIjtxAdKx7d?= =?us-ascii?Q?vWApB/81qtUf5mXEHmozWxExag4k494mx7ZVLaDRSJOjSAaUZR1e13KUUjt6?= =?us-ascii?Q?XDIAeMtdjONp2igCHJvAtXL8lmdEQiWW/yPqh7DdwD01rGlrEGMVh4vMaCrD?= =?us-ascii?Q?aAL5h7k3KRysqyKd6SkpyRVmao30NR7mhKk2G/0r7eljLIBDtrqyUy0mi4Ug?= =?us-ascii?Q?otU69mVEvq8vflbciHTgeb/CT0kIeLqSgQ84vLNSB7WHlxqCtl7Ais0jXljd?= =?us-ascii?Q?BBH3RQoFVIWepwfxaTaxZ2xpiHrrqQOGo4mcpTtj/jOqNFPlJzY2U1Nivybz?= =?us-ascii?Q?CVSTloQETCRTC6rjNpHh5dAEfwqc6W23lfJsTzGCKEUafgsbJBNTbJBaJcRQ?= =?us-ascii?Q?Y4CoBIhpcC5oIVcG5JDDMjRMvDho5c4cs7PpCSwi+ULEMm0oyuLegjrlGc/l?= =?us-ascii?Q?Qv0IhWzRn58/ZhQt7MJxRJwP?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366255A77C76D9004360169B5759MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fcdccdf6-d46d-4e6e-0abe-08d8f9a636e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2021 09:19:15.1793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y+LFluhiCyqd04IZN7jdprcYVdoteVSs6UxbTb/ZmX3bSoLvoNJBtFCqVfDWA71RULbVOIX5pX07WFXXmJitOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3169 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 09:19:29 -0000 --_000_MN2PR11MB4366255A77C76D9004360169B5759MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable // As a contributor Hi Jason, all, In yesterday's meeting there was a discussion on this text, and Joe pointed= out that any sensible client must validate its input. While incoming configuration data is checked according to YANG constraints, constraints on state data sent by the server MAY or MAY NOT be enforced. The following guidelines are provided for client application designers to allow a smooth interworking with servers. o A client MUST tolerate any data received (or not received) without crashing. o A client MUST be able to discard any data that is not part of the model but is sent by the server additionally (e.g. XML elements or attributes, JSON properties). o A client SHOULD be able to handle valid parts of a received data set even if it discards other parts as invalid. o A client SHOULD be able to handle data that is outside the valuespace defined, as long as it is of the same basic type. o A client SHOULD be prepared to handle more items for a list or leaf-list than what is defined by the model. Based on Joe's comments, I suggest that this text could potentially be writ= ten as something like: Client applications are expected to perform sanity checking of data received from a server and to handle unexpected or missing data gracefully, e.g., this could include ignoring unexpected data, or logging unexpected values for further analysis. Clients SHOULD NOT discard an entire response from a server because some data contained within the response is not expected. Examples of well-encoded but unexpected data received from a server may include: o Values that are outside the value space of a data node defined in the YANG schema, but that are within the value space of the underlying base type, e.g., if the value represents an unexpected error condition on the server. o Additional data nodes, e.g., if the server implements a different, but compatible, version of a YANG module. o A greater or lesser number of list or leaf-list items than the permitted range defined in the YANG module. o Non mandatory data nodes that are sometimes missing from the response. Noting that the server is expected to deviate any data nodes for which it will never return values for. o Values that do not conform to the semantic constraints of the schema. o Additional YANG meta data in the encoding (e.g., XML elements or attributes, JSON properties). NMDA [RFC 8342], section 5.3, provides additional constraints on the data that a server can return from the operational state datastore. Thanks, Rob From: netmod On Behalf Of Sterne, Jason (Nokia - = CA/Ottawa) Sent: 06 April 2021 15:10 To: netmod@ietf.org Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06 YANG Versioning Weekly Call Minutes - 2021-04-06 Focus for this meeting was going through Jason's review comments for sectio= n "3.1.2 Backwards-compatibility rules for config false and output data" of= https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02. (A) Valuespace: - value space (with a space between the words): use 7950 meaning/definition= (remove the definition in our draft) - make "must" its own bullet - don't particularly address "description" - Balazs propose updated text (B) replace this: "an additional state leaf can easily be discarded" with this: "the presence of an unexpected state leaf is not typically a problem and ma= y be ignored by the client" (C) replace "config=3Dfalse data" in the 1st paragraph with the following (and = keep the quotes - that is how RFC8342 presents it): "config false" data (D) Lots of debate about the "client" bullets in 3.1.2. Didn't conclude. Perh= aps just summarize and say clients need to sanitize data (give examples of = data they might get, values outside range) ACTION: focus on reviewing section 3.1.2 ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_MN2PR11MB4366255A77C76D9004360169B5759MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

// As a contributor

 

Hi Jason, all,

 

In yesterday’s meeting there was a discussion = on this text, and Joe pointed out that any sensible client must validate it= s input.

 

   While = incoming configuration data is checked according to YANG<= /p>

   constr= aints, constraints on state data sent by the server MAY or MAY

   NOT be= enforced.  The following guidelines are provided for client

   applic= ation designers to allow a smooth interworking with servers.

 

   o = ; A client MUST tolerate any data received (or not received) without

   &= nbsp;  crashing.

 

   o = ; A client MUST be able to discard any data that is not part of the

   &= nbsp;  model but is sent by the server additionally (e.g.  XML el= ements

   &= nbsp;  or attributes, JSON properties).

 

   o = ; A client SHOULD be able to handle valid parts of a received data

   &= nbsp;  set even if it discards other parts as invalid.

 

   o = ; A client SHOULD be able to handle data that is outside the

   &= nbsp;  valuespace defined, as long as it is of the same basic type.

 

   o = ; A client SHOULD be prepared to handle more items for a list or=

   &= nbsp;  leaf-list than what is defined by the model.<= /p>

 

Based on Joe’s comments, I suggest that this t= ext could potentially be written as something like:

 

     

      

   Client applications are =
expected to perform sanity checking of data
   received from a server and to=
 handle unexpected or missing data
   gracefully, e.g., this could =
include ignoring unexpected data, or
   logging unexpected values for=
 further analysis.  Clients SHOULD NOT
   discard an entire response fr=
om a server because some data contained
   within the response is not ex=
pected.  Examples of well-encoded but
   unexpected data received from=
 a server may include:
 
   o  Values that are outsi=
de the value space of a data node defined
      in the YANG=
 schema, but that are within the value space of the
      underlying =
base type, e.g., if the value represents an unexpected

      error condi=
tion on the server.


   


   o  Additional data =
nodes, e.g., if the server implements a


      different, =
but compatible, version of a YANG module.


 


   o  A greater or lesser n=
umber of list or leaf-list items than the


      permitted r=
ange defined in the YANG module.


 


   o  Non mandatory data no=
des that are sometimes missing from the


      response.&n=
bsp; Noting that the server is expected to deviate any data


      nodes for w=
hich it will never return values for.


 


   o  Values that do not co=
nform to the semantic constraints of the schema.


 


   o  Additional YANG meta =
data in the encoding (e.g., XML elements or


      attributes,=
 JSON properties).


 


   NMDA [RFC 8342], section 5.3,=
 provides additional constraints on the


   data that a server can return=
 from the operational state datastore. 


 


Thanks,


Rob


 


 


 








From: netmod <netmod-bounces@ietf.org>
On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)

Sent: 06 April 2021 15:10

To: netmod@ietf.org

Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06






 


YANG Versioning Weekly Call Min=
utes - 2021-04-06


 


Focus for this meeting was goin=
g through Jason's review comments for section "3.1.2 Backwards-compati=
bility rules for config false and output data" of

https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02=
.  



 


(A)


Valuespace:

- value space (with a space bet=
ween the words): use 7950 meaning/definition (remove the definition in our =
draft)


- make "must" its own=
 bullet


- don't particularly address &q=
uot;description"


- Balazs propose updated text


 


(B)


replace this:=



 


"an additional state leaf =
can easily be discarded"



 


with this:

 


"the presence of an unexpe=
cted state leaf is not typically a problem and may be ignored by the client=
"


 


(C) 


replace "config=3Dfalse da=
ta" in the 1st paragraph with the following (and keep the quotes - tha=
t is how RFC8342 presents it):


      =
          "config fa=
lse" data


 


(D)


Lots of debate about the "=
client" bullets in 3.1.2.  Didn't conclude.  Perhaps just su=
mmarize and say clients need to sanitize data (give examples of data they m=
ight get, values outside range)


 


ACTION: focus on reviewing sect=
ion 3.1.2


 


-------------------------------=
---------------


Weekly webex call details:=



Meeting number (access code): 1=
71 069 0374



Meeting password: semver?<=
/o:p>


Occurs every Tuesday effective =
Tuesday, September 1, 2020 until Tuesday, August 24, 2021 from 9:00 AM to 1=
0:00 AM, (UTC-04:00) Eastern Time (US & Canada)



9:00 am  |  (UTC-04:0=
0) Eastern Time (US & Canada)  |  1 hr



https://ietf.webex.=
com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70


Tap to join from a mobile devic=
e (attendees only)


+1-650-479-3208,,1710690374## C=
all-in toll number (US/Canada)
--_000_MN2PR11MB4366255A77C76D9004360169B5759MN2PR11MB4366namp_-- From nobody Wed Apr 7 06:56:43 2021 Return-Path: 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 7B2913A1979 for ; Wed, 7 Apr 2021 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=ericsson.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 ICA_TTtfFlLb for ; Wed, 7 Apr 2021 06:56:37 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2088.outbound.protection.outlook.com [40.107.20.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388523A1974 for ; Wed, 7 Apr 2021 06:56:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fOSkPbu5sbI2XIFnjBjJUCqhlVuXqnExWctgVdA2DbO1xK6oj8lJpwndrhBWuQUzHwEuzFMvSJ3OSgpLAF0ZudL4K5t7O0hMpI3DNOoRKJCZV5FJKmTdO/CxZ2jmptmD+7FO4ItH9b7gzwoBtiLS22qi/bJME60FFuOJKh5ZK4tA/bwZiHWcXesFjvctF96pv4rWjbS4Bb+JRAdrfqk7Xr9HK59tKKQp6Gdyt9IWixv8Tz4OnDV7WINQSgVF/m743Oc+qS606iS5Sq02IDNRctb3kGCbqKPrvTzmUFHQUaSf3e5ZinnJAQqQRaBqVdQFfpYct21y4mJduhJ5R/K9hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sTVI0zGdRbIbB25DcyZvAwx02/BlSXR++QLtP/8AQ+0=; b=a9E+wkyh7Bgjp8Jv57O+YtPRtCKDwqnMuTUU3GLZj7jCxUVZ62chwrZi84nny/Cr02PMmxvk4tCNfRG3OWqfjowLWBM9ameD46fGFDyxf1NhN90922ZYrK3QlDlf6eyj1rk45QfNQ3j+QIEMjUga/Bj/WDXgJOxAB4reS8/XlXiLp6xIRnA5NrIoQa3lbVZRWb/qTuAWDP+bhwQxMaHODmGof+pXZuyco7ZicRuJltKbsnwY26TiElcbcAzlktX4kJR+1mZ6TKe0UZ0KeM8VFSVCBqMmqGPuh067vKSsQUcRfSnlSow7/8A5gKX3S8RktgDtFVTReiKmZBiFqroc+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sTVI0zGdRbIbB25DcyZvAwx02/BlSXR++QLtP/8AQ+0=; b=k6GYydvymlNAOnQ3W6Wws2QtrxKjrsrzBs2AusnVt25toUfYTz6RyQGqS1GxDbHU8MnxzdLpS7hNjuNel12xLZIou7mM4tEvfMJTxGjPjm/MjR+b49iEBT8QdfQsRRp/43EPHlj4Bfr3UWzdNKV5tiqg+OEDKn0OTXQW1YUu05U= Received: from AM6PR0702MB3557.eurprd07.prod.outlook.com (2603:10a6:209:d::21) by AS8PR07MB7655.eurprd07.prod.outlook.com (2603:10a6:20b:2aa::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.10; Wed, 7 Apr 2021 13:56:31 +0000 Received: from AM6PR0702MB3557.eurprd07.prod.outlook.com ([fe80::dfd:a279:c1a9:fc5b]) by AM6PR0702MB3557.eurprd07.prod.outlook.com ([fe80::dfd:a279:c1a9:fc5b%6]) with mapi id 15.20.4020.017; Wed, 7 Apr 2021 13:56:31 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Kent Watsen CC: "netmod@ietf.org" Thread-Topic: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10 Thread-Index: AQHWBsiHw0i2pb8NhUW3/SG15kFU86hh7+OAgAPCO/CAC5ZegIIiilqwgA7LTICACLXNMA== Date: Wed, 7 Apr 2021 13:56:31 +0000 Message-ID: References: <010001712ce4c5fe-04a059c3-ced3-4e6d-8389-5dd7c1257ac2-000000@email.amazonses.com> <010001712e483a1b-204d92e3-7046-46fb-b6b8-13d8ad4cb9ff-000000@email.amazonses.com> <0100017160917518-a18954f3-8e57-4286-904a-5a3e9779ff31-000000@email.amazonses.com> <010001788ff302da-dcb9dc37-8e63-4ba1-9f82-5584e0e4f49a-000000@email.amazonses.com> In-Reply-To: <010001788ff302da-dcb9dc37-8e63-4ba1-9f82-5584e0e4f49a-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.248.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54baaa39-9e08-49a7-3348-08d8f9ccf2f9 x-ms-traffictypediagnostic: AS8PR07MB7655: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X9JQ2FlF5x3k/iPFHsDa8I31MluHIzaoouZfd3xWppNDFxFecmBpsVMyq2ufo59jebSFo8JbLlezvmzuOnuOGkD02KQ+93EjgGzAdLur/LSiAwDqIOi0z6LAcOfgrULg7p+m8S7P64tZIqFV5kAZMk18hCgXIlj4ew4GPds06MEon49vEhSreLoVE3oJobcv/sCmTZleN8FZfMiQXbjS2wQJQDSLzt39de3kdlec8iLg1bvDe0t7NedOks3sB7obMHaWJE1rTpustNu+ILaebXUlk0arQSPJqzwPf8pCSZRrv/IUh11FMPYjnLQqC5U7DGenTxPDfPI280tQ6Tkn9f8gMhmwnJfxG9+0QF7AXBaApn/NhbBIBdHIz1vv0AMuKiu2r8uWiiB14UsoE2cl4HUS8HDa+ZONj8w+89LuImfUFEfzfrgzrpEBcgVfccjtov20mqfSZukAa50nujKHpbg5JsE69QNVQJG79JNKPkrz7M5h0XzjkEDrPpIDzw71FTLlqxCR5J9tdyfgAd51+KkmI5jcSQTzKGf9Zd4TR1dvpRbVHxBe7mehhDy0/nITgjng/YAxIRwHy3SnU71rFVog6aJpwUl3tLJxoSpfQbV3qjj6+/WtKVnejMN9R6zlAFokgT+ci/INY5ICUxQTe0HHGVKiu15Qa7CD8TVXyEE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR0702MB3557.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(39860400002)(136003)(346002)(55016002)(9686003)(85202003)(38100700001)(7696005)(4326008)(2906002)(5660300002)(33656002)(71200400001)(6506007)(86362001)(53546011)(186003)(99936003)(26005)(64756008)(52536014)(478600001)(8936002)(85182001)(316002)(9326002)(8676002)(66556008)(83380400001)(66616009)(66574015)(66946007)(66446008)(76116006)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?R2hZZHNmMG52V2ZqbzFhQUM2V1Brck9pajVvL3FucG15bXEyRTBtcGFxaXNm?= =?utf-8?B?YWJjTkFTMnhwVjN1aUZ3aURaY3d2Ry9RQkFDK3VhYXpNSk5Zb0lnaGh3V1Y0?= =?utf-8?B?Mkloem85dVo2QXdSMnFDY1VGSmNrdmtHM2N2bjBkMWE2L25tY1JramJZUGhG?= =?utf-8?B?ODBJUzFKcm5DRHN0VEU0bW1Cc2J0R3VrckZqQnBTVFd5Yis1NDRzRXhxenBJ?= =?utf-8?B?bTkzK2dUdWJqb1piZTZPZm1IblgzSDVMaStDWFZOTFlDV2E5Mks0eWNlNW9j?= =?utf-8?B?VVNLdU1wOER1Sk9QMXBRMWR2b3JZLzBjTVJBMnJSSlQ5amswUzFnUy9zbm12?= =?utf-8?B?V0w5T0FZZGNuYjdSdlNtdnc5ejI4eWc2N0xLWTh4bTBuMkJLN281Q1liUjZa?= =?utf-8?B?eXNsRFpydTU2UzFHd0xsVXZjb3hyOFpTdE1UT3I3SUtqQjk4dVJqWnowNk1J?= =?utf-8?B?MkJBMU1sWnFyWHR4Y0laTVFZUzhJSjBNVWR5K0E4Ymdtb05hQ1oxK2h1dXhw?= =?utf-8?B?d1RkdU1rL05vMlZKSHRKc1g4R0twYkc5cWZXUGJGMldFUlcxdXpISWJ2NDZK?= =?utf-8?B?dWltSUhzWnduWlpOeFFCeUgvR3Mxa2xKa21YajBhZ2Fwb09RN1dWaUlCMWR6?= =?utf-8?B?QlRXUnE4YkhVaVBBMkhONTZqR3QzS2N4OHpreVFsVmZNMlpVeWxndno1dEQy?= =?utf-8?B?ZU5TR21lcFE2UExjWHphQWlBaXUwbFVFc2ZuejZobVFSVjlSdlNtUjBka3hQ?= =?utf-8?B?T1lkNU5EaXJmcmY5Z2IzRWNlc2g3VHJrbzhUYjRzbFc3bmlHUnpBNllBeXMz?= =?utf-8?B?THNneHNtR2pGMFh5dWlxVEV2YjdPVVJOSmxROWovWHB3UnErcjRtM1UzMy9L?= =?utf-8?B?MFVYQlI1ZVQ4T0hTUU9VeUhHMmpYM0NVT2lQblJkMWpyVXM3RENIeDV1OU42?= =?utf-8?B?Nys4QWVGL1l0cHErc1lMMkNmMTk4dWtDYTZMVTJ0N1FlSHpEZlMyZTRKTWY0?= =?utf-8?B?QzREanNyU0tuaktSbGRORjVCYmxPb3JJMzZPc05CbmN1R3V2bW1NUDFaTktH?= =?utf-8?B?cmQ2L3g0eEVKd0dQSndRd2diN0FYVUQ0TS9lSGRvWXZSRU9ZeVdCTEpFMHRn?= =?utf-8?B?cFdBMVRUcktYTkk4eUZjVWtibUdOVVBNMTlnVFkxQkZIOUNydHBSZEpjQ1di?= =?utf-8?B?MnRUbHY4ckZnaG9vYVhPRjNPa2V2eHJpa3NJcWJwanJOZEhvUllKNStFZml1?= =?utf-8?B?TTVNUFB2WVlubUkveTZtS0NIdjJJMXVkOHdlV1BvVjdIT1J5b0taZlh4cXd3?= =?utf-8?B?Q21jUXdpWTVPRjgxcnNJWlFQdnlsM0ovdHdMd1IydjB3VmRLQTc3RGFDQmR5?= =?utf-8?B?bW5zMTdUekxkZlNRNHhDZjBwYUdvNXBhK0xCZWRLQkFYSlB4dUlHNEFCS3JI?= =?utf-8?B?cUs3QVd4RDFKQVFHVXBtaGt1SWoxMTdtTXZRRWkxT2tleldTVFNoM3diL25T?= =?utf-8?B?YTlKaFA5bGkyazh1ZnlkV0pUNVZ0a0ZSbDhURndTL1UzWHhQYm1HZlRvYlBO?= =?utf-8?B?OXBUek5WYk16akMyZGsyM0VPNkFpOWVrZlFRczJxOFdWS0pYeThwa2tXR3RU?= =?utf-8?B?YUoyV1J4anczeDkxUk9ONDAvdG9LYUQyb2tPVFB3Snk5OXNBMWtzd2FQNFd3?= =?utf-8?B?VU82eU1IVXM3SHhNSTZtbWxMNXRLY1laMHYxWU9LM3hkUGhDYzY4cHI5OXho?= =?utf-8?Q?e3XO5BbdeFBPBw785+GQ4SPoTTsCYqzY8uRU7+Q?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CA_01D72BC6.92E2B910" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR0702MB3557.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54baaa39-9e08-49a7-3348-08d8f9ccf2f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2021 13:56:31.7607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KfKLUc8e7MagXS9c0RbeqIfOehhn9eDmDy5ixzqAxRdiBYO93W1Bpo5IhapHEVekLXEy7eK0HmxPTFxQmqcB457BE4ysA09pWbixBYBLZ6c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB7655 Archived-At: Subject: Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 13:56:42 -0000 ------=_NextPart_000_00CA_01D72BC6.92E2B910 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CB_01D72BC6.92E2B910" ------=_NextPart_001_00CB_01D72BC6.92E2B910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Kent, Thanks for the thorough review and sorry for my absence and hence the = earlier slow response. See answer below as BALAZS4. Removed already agreed parts. What is the next step? Regards Balazs =20 From: Kent Watsen =20 Sent: 2021. =C3=A1prilis 2., p=C3=A9ntek 2:20 To: Bal=C3=A1zs Lengyel Cc: netmod@ietf.org Subject: Re: [netmod] Shepherd review on = draft-ietf-netmod-yang-instance-file-format-10 =20 Please see below for responses. (One question pending) =20 Kent // shepherd On Mar 23, 2021, at 6:01 PM, Bal=C3=A1zs Lengyel = > = wrote: =20 Hello Kent, I am resuming my work on draft-ietf-netmod-yang-instance-file-format.=20 Regards Balazs =20 =20 From: Kent Watsen >=20 Sent: 2020. =C3=A1prilis 9., cs=C3=BCt=C3=B6rt=C3=B6k 22:11 To: Bal=C3=A1zs Lengyel > Cc: netmod@ietf.org =20 Subject: Re: [netmod] Shepherd review on = draft-ietf-netmod-yang-instance-file-format-10 =20 Hi Balazs, =20 BTW, I assume that you wish to publish this as-is and follow-up later = with an update to adjust for the =E2=80=9Csemver=E2=80=9D work - = correct? K. =20 BALAZS4: Yes, correct.=20 Semver will take time and may undergo changes, so it would be too early = to adapt this draft/RFC to it. However, two items already deal with = Semver: 1. The instance data files themselves will not have a Semver revision as = the concept of compatibility is not defined for instance data. 2. The YANG module ietf-yang-instance-data already includes: =E2=80=9C... If = other methods (e.g., revision-label) are defined to identify individual module revisions those MAY be used instead of using a revision date.=E2=80=9D =20 =20 =20 ------=_NextPart_001_00CB_01D72BC6.92E2B910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Kent,

Thanks for the thorough review and sorry for my = absence and hence the earlier slow response.

See answer below as BALAZS4. Removed already agreed = parts.

What is the next = step?

Regards Balazs

 

From: Kent Watsen = <kent+ietf@watsen.net>
Sent: 2021. =C3=A1prilis 2., = p=C3=A9ntek 2:20
To: Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>
Cc: = netmod@ietf.org
Subject: Re: [netmod] Shepherd review on = draft-ietf-netmod-yang-instance-file-format-10

=

 

Please see below for responses.  (One question = pending)

 

Kent // = shepherd

On Mar 23, 2021, at 6:01 PM, Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com> wrote:

 

From: Kent Watsen <kent+ietf@watsen.net> 
Sent: 2020. =C3=A1prilis 9., = cs=C3=BCt=C3=B6rt=C3=B6k 22:11
To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd = review on = draft-ietf-netmod-yang-instance-file-format-10

=

 

Hi = Balazs,

 

BTW, I assume that you wish to publish this as-is and = follow-up later with an update to adjust for the = =E2=80=9Csemver=E2=80=9D work - = correct?

K.

 

BALAZS4: =C2=A0Yes, correct. =

Semver will take time and may = undergo changes, so it would be too early to adapt this draft/RFC to it. = However, two items already deal with Semver:

  1. The instance data = files themselves will not have a Semver revision as the concept of = compatibility is not defined for instance data.
  2. The YANG module ietf-yang-instance-data already = includes:
 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=E2=80=9C... If other =
methods

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g., revision-label) are = defined to identify

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 individual module = revisions those MAY be used

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 instead of using a = revision date.=E2=80=9D

 

 

 

------=_NextPart_001_00CB_01D72BC6.92E2B910-- ------=_NextPart_000_00CA_01D72BC6.92E2B910 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQwNzEzNTYyOVowIwYJKoZIhvcNAQkEMRYEFN98DrvS4iI6 70GpUpKLJawLzCKWMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEHv OPNXiojtOMigusC4xdym3GMpIn4mRjKUkbKxVg0wuVcIcVq978RIpGRhfXL3OONgW8u6F+GEpgek 8drMhiXxxSMlJQ+2GjFSOLkj7OnQPbW9ejnGsvUZvpl6lBG98CvA00FTIfcXmMnN22el9BbHjiIi 4ptoD+4O1ds8yn3FCT29BD2BurCsgNNJxHWOrlwDzFYoPXzxkEqoyUE1kY0tifiivZ9AIuMHnmxd +7yi9gY/91Z45J127ShVFsKJAA09RoMFbgARg4sgChzeVuGVLeYFM6p9GJJHZTVC8KYjWQMlAy5l lQqotkrdYceCdqK5VaTN83pjKZ9efDF2JLkAAAAAAAA= ------=_NextPart_000_00CA_01D72BC6.92E2B910-- From nobody Thu Apr 8 10:59:07 2021 Return-Path: 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 15DDA3A14B6 for ; Thu, 8 Apr 2021 10:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 rOdbooaxJFao for ; Thu, 8 Apr 2021 10:59:00 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2130.outbound.protection.outlook.com [40.107.93.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6934B3A14BB for ; Thu, 8 Apr 2021 10:59:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RdSWlh1mT5+Yr95vD0rxBU37AVTT90vwysKELxdyfvZ07fQvP7MQ7EErAB7hPOP0W5GVT7TkiJXPfFNvNXNOAP5FLM+qcRpolIQ/4WKUnIB86RxvDfXh5rVK/rTyIHaHow98xg5mZywrrdbSjGbkUqTBCw5zWG7NMthw+dGq2saz08fOxayXTAldlK4lGOfhM+rahc1Dla1mZl6WLYhLd8LI7sI24GOCXwynyvKjJhcUC6FAMZFA+23GvGkaaJhZ5pC6u2R5nytP6TEN4MJ9fQYNEW7V46yO5KAaipW2KT9A/WGbaTZOKamLsWKslzrr2kRwwpBxgCqU3iPc0k+mWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4x3suUSj9TP/rDrgUVVZ+wBuwq/4XyOacj0ziS1SR6g=; b=lkRh16PCfCXnkIK2hArHIj8CseNnOC4du24o/0W/PJ34IYU1ZlZj2HpS9S1toChNLWuYeX4z4e+paiNoOIuzqbpw7mFiFDxauQZb6xxoaSLKBZDqFDW9QCLVTifhU/YsrYmEKWXbGja2CBYFkung7s3A7mIXzhBXm/6bbOHCogZGGkQxJtvbcrl58acPeip4ziy9DFj1nLxvdMWNmnUbNJOi+RItHf1xoER/YwbOLhz6XlNl7t4Bl6GkIqQFTmIw7y2A6OywE4poGE1i9MZlDcSiO4fhqOqGVqRHQmUaxfV7w6HixvysIZ4uBKbqL2US4XGfyA2iLT+a6LALuUEMsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4x3suUSj9TP/rDrgUVVZ+wBuwq/4XyOacj0ziS1SR6g=; b=IFmLx4KfK5dcLQg9SkPzGV+B+/p2Th1Pz//mpk1F+zNEZK3zfkoCerqU3WOEqw/R/5IO+/qx6wPLyhLs68XdTxBDqc+6aYf6mXUdIdRKwoKx0wM4LC3Vw+0FHG2qPvAkw1ACpY6cd8hWS58EkaA3tHE9xCwlnI8jQTwuXZBfLWk= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5803.namprd08.prod.outlook.com (2603:10b6:5:17e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.28; Thu, 8 Apr 2021 17:58:58 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3999.032; Thu, 8 Apr 2021 17:58:58 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "Rob Wilton (rwilton)" , "netmod@ietf.org" Thread-Topic: Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] Thread-Index: Adcrjvs0u1Y2kX7cTWaMCLlk2EmADgBEca5w Date: Thu, 8 Apr 2021 17:58:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49a4272f-61ab-4e96-93c4-08d8fab7fbda x-ms-traffictypediagnostic: DM6PR08MB5803: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DbQRIx+2855Kpsfzy08wMrYcbd9KTbY1VyV61vssfDZhlpMlweEafcskWqTow4FdKNYamfCoBlABklETiTK1gAPM+jMXqf/l8T/SkEQVWvdxcfSowhl4esiaLxJxGY6t1qeD8DPnhbLYPVO2rP7UBpZuUP9nwe4iaBIDhPKBGITkZUNWe4frsv8oeF1UVkw/n/JOO+/DJgkzkpLxPj8fAO+EFS7UkzwZBSfaMt5xtNjLEIQYsv1exmxwysoTRX3jKdMHWtFFqlQBIQoyQGl0xzomGeD0FiBHol/xG1KXVwr3+dqRar9pz4IlRBRySnzzhT3o5IXcF42CVxzmEtE/APJhDbtkeIaqRIQVVHXI2CPLhKrr6vHfT/5Nf21BjpONlZTMe5DH+FwnoLopB8UHg9je+7GFSQXDqao+oJ7EdzJEnPDSwh/IuDoO9Wq0/nqqntzEctS2Tua/JFwF3NqecsrYhbIM8uJ/S1Md3D3VOnRfXPmw/dUj1im0PLL1K45XjyayYD2burNqUfYyfG/kN/Af2MQoDb6h1GzUmtxQIiwezM2XLpy72eLYBGVylHfQ/EVb25bE0DXB1tbU7k/b7Ldqdigr442oTeoW3ZhY/8vE2reCdVZVgd7DxHbV9Mp6aiZgS/1eTPlc0SjHfygDHbinqzaxrAGwgaBCIdYx53u1uzwjAbDFq83oQ7NPuIuyzzKE+thhE3A4VxA6dDWkGdTRNrlkV62rESPp+5M88fo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(9686003)(16799955002)(9326002)(86362001)(52536014)(64756008)(38100700001)(8936002)(8676002)(2906002)(55016002)(83380400001)(66446008)(71200400001)(186003)(166002)(66556008)(316002)(66946007)(5660300002)(478600001)(7696005)(966005)(76116006)(110136005)(53546011)(26005)(6506007)(33656002)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?emfpQqNfj6GbimBSacH+6LGIph2W6bU1/VFkvx8EyxNVbivcznXidb9TAJVp?= =?us-ascii?Q?C1oZEgpfmRb1ahszM5JXjEflSgHdb3+tRP072o3x342WecCa3WoF2Mk+b8iW?= =?us-ascii?Q?889SG7NMHiR6EtSkI3kNJEIUmlMTJTNuwjsYQqXj7iCoa4vSJhZLoj5QlFVb?= =?us-ascii?Q?lKBZepfZGi7iGR/JKy25NiVKmOouCr3g3fvrqRJhAfqzTdSBSG84GtnIG9wZ?= =?us-ascii?Q?2jjAkUUwN8knxYaqB1+p7di364VHRi02KwMHVJKf5oimZAkJp/ktsFIqL12k?= =?us-ascii?Q?XuoVal6vTWzgmUn0RQcuc9diZ70peXHFpaEO1fnPAzReixhY5gJ0R/OgNGIN?= =?us-ascii?Q?N/QeU7jAdJ07e4+XKC7BJsGDPBIDeiNBXtoeE6jOTFpSn+hsmsBoAkvJ+3YX?= =?us-ascii?Q?/WN4oMpFnl//veZTvCTvJnWZmLj80LLwhd0YWspnf7t/4fzG3ymuqrjNXB8x?= =?us-ascii?Q?DEl9FMCahZ0/T29DdsLV4u9Hk8BJblWB1U3q8h9/SX2r9X/9oy5lZPlZAROC?= =?us-ascii?Q?2AdemrOV0y6AXF5kDTCmBR6rb7LWTOHDuC1MqhYo7LYNro5Ox6iSfI7zt7af?= =?us-ascii?Q?yE36rEVjk9rX5PqpGLY2SA9+dfNRe9RqFqwacWdYdXytEMjwzyxgFoT5bUSP?= =?us-ascii?Q?SCo4o1xgKyHkrOqMg3eGjtGPvdSFpVNJ7VOfmBvOUCX5/Jq92uUNaeHkEHRA?= =?us-ascii?Q?II/1DEJlM7S3rHr8VWN7q8/UfDlgHfSSpwnRWUDAOSTtlE84Henjopk/2K5X?= =?us-ascii?Q?K5wwh/krDtvO0b1V95w2SQQE5V96C3JqyfY2EAZWO5BmKS1Q+ziC4LbpxuWH?= =?us-ascii?Q?OGuAkIyuvCpFhTt3Yf7cAhNCxkF/xnQ3SDRWq3cSJACq+ERcXilgEXn7QAhF?= =?us-ascii?Q?rlbYPwOvnz1xFXRBsYP7g0iOGPIXx6g1j2TUUlT8J+LImhPxEL5PAYVaS6OX?= =?us-ascii?Q?GLTRzAwfjcv7T8LK5Qvtb2MTRYAqlSP/u2d6nQmBoN9Amqda3bCW2U8Z6BAK?= =?us-ascii?Q?eyFbnVAsNgXtPQMnvID3VagcdhAM+eEjMrCoEadNFUnIJXwcLTGdib96DlRv?= =?us-ascii?Q?yq7FNfhb9KXDctbjGMv/cOu9+WGAYxHk+fdZMn5/j9OMcIol3KN40lHspb2O?= =?us-ascii?Q?n1MJMz/FRGqU2Y2XA7D+NpgcSTIR0xy7HDDtwebQODsPokXnMuk2Ev2Jhb7+?= =?us-ascii?Q?NlRZDoXZYjEpQ6quxIkCS+X+H3tG73DxYAZuQkb/5f9/EiisNwAT7gMCsF1z?= =?us-ascii?Q?jOm2XZqvidq/eNlQx9jZWNcMMUY2xS3ZFnyy4v2uzpLHXk0iIVAWsKGgnEe0?= =?us-ascii?Q?L754vZc4OMTUCkbaCQ8VtTl8?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084935EDB6AB7718B695BAA9B749DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49a4272f-61ab-4e96-93c4-08d8fab7fbda X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 17:58:58.2801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /qcODRAtEiVrm2dJL9C9AbMCqqX/WRQ3en3R/0YomNOn6pquWBAz0ni4Vw73JDR+BdYxQ0vAXShDQQeov9LwSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5803 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 17:59:06 -0000 --_000_DM6PR08MB5084935EDB6AB7718B695BAA9B749DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob, I like the reformulation of this. Jason From: Rob Wilton (rwilton) Sent: Wednesday, April 7, 2021 5:19 AM To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf= .org Subject: Client validation text [was RE: YANG Versioning Weekly Call Minute= s - 2021-04-06] // As a contributor Hi Jason, all, In yesterday's meeting there was a discussion on this text, and Joe pointed= out that any sensible client must validate its input. While incoming configuration data is checked according to YANG constraints, constraints on state data sent by the server MAY or MAY NOT be enforced. The following guidelines are provided for client application designers to allow a smooth interworking with servers. o A client MUST tolerate any data received (or not received) without crashing. o A client MUST be able to discard any data that is not part of the model but is sent by the server additionally (e.g. XML elements or attributes, JSON properties). o A client SHOULD be able to handle valid parts of a received data set even if it discards other parts as invalid. o A client SHOULD be able to handle data that is outside the valuespace defined, as long as it is of the same basic type. o A client SHOULD be prepared to handle more items for a list or leaf-list than what is defined by the model. Based on Joe's comments, I suggest that this text could potentially be writ= ten as something like: Client applications are expected to perform sanity checking of data received from a server and to handle unexpected or missing data gracefully, e.g., this could include ignoring unexpected data, or logging unexpected values for further analysis. Clients SHOULD NOT discard an entire response from a server because some data contained within the response is not expected. Examples of well-encoded but unexpected data received from a server may include: o Values that are outside the value space of a data node defined in the YANG schema, but that are within the value space of the underlying base type, e.g., if the value represents an unexpected error condition on the server. o Additional data nodes, e.g., if the server implements a different, but compatible, version of a YANG module. o A greater or lesser number of list or leaf-list items than the permitted range defined in the YANG module. o Non mandatory data nodes that are sometimes missing from the response. Noting that the server is expected to deviate any data nodes for which it will never return values for. o Values that do not conform to the semantic constraints of the schema. o Additional YANG meta data in the encoding (e.g., XML elements or attributes, JSON properties). NMDA [RFC 8342], section 5.3, provides additional constraints on the data that a server can return from the operational state datastore. Thanks, Rob From: netmod > On B= ehalf Of Sterne, Jason (Nokia - CA/Ottawa) Sent: 06 April 2021 15:10 To: netmod@ietf.org Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06 YANG Versioning Weekly Call Minutes - 2021-04-06 Focus for this meeting was going through Jason's review comments for sectio= n "3.1.2 Backwards-compatibility rules for config false and output data" of= https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02. (A) Valuespace: - value space (with a space between the words): use 7950 meaning/definition= (remove the definition in our draft) - make "must" its own bullet - don't particularly address "description" - Balazs propose updated text (B) replace this: "an additional state leaf can easily be discarded" with this: "the presence of an unexpected state leaf is not typically a problem and ma= y be ignored by the client" (C) replace "config=3Dfalse data" in the 1st paragraph with the following (and = keep the quotes - that is how RFC8342 presents it): "config false" data (D) Lots of debate about the "client" bullets in 3.1.2. Didn't conclude. Perh= aps just summarize and say clients need to sanitize data (give examples of = data they might get, values outside range) ACTION: focus on reviewing section 3.1.2 ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB5084935EDB6AB7718B695BAA9B749DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob,

I like the reformulation of this.

Jason

 

From: Rob Wilton (rwilton) <rwilton@cisco.com>
Sent: Wednesday, April 7, 2021 5:19 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>= ; netmod@ietf.org
Subject: Client validation text [was RE: YANG Versioning Weekly Call= Minutes - 2021-04-06]

 

// As a contributor<= /span>

 

Hi Jason, all,

 

In yesterday’s meeting th= ere was a discussion on this text, and Joe pointed out that any sensible cl= ient must validate its input.

 

&nbs= p;  While incoming configuration data is checked according to YANG

&nbs= p;  constraints, constraints on state data sent by the server MAY or M= AY

&nbs= p;  NOT be enforced.  The following guidelines are provided for c= lient

&nbs= p;  application designers to allow a smooth interworking with servers.=

 

&nbs= p;  o  A client MUST tolerate any data received (or not received)= without

&nbs= p;     crashing.

 

&nbs= p;  o  A client MUST be able to discard any data that is not part= of the

&nbs= p;     model but is sent by the server additionally (e.= g.  XML elements

&nbs= p;     or attributes, JSON properties).

 

&nbs= p;  o  A client SHOULD be able to handle valid parts of a receive= d data

&nbs= p;     set even if it discards other parts as invalid.<= o:p>

 

&nbs= p;  o  A client SHOULD be able to handle data that is outside the=

&nbs= p;     valuespace defined, as long as it is of the same= basic type.

 

&nbs= p;  o  A client SHOULD be prepared to handle more items for a lis= t or

&nbs= p;     leaf-list than what is defined by the model.

 

Based on Joe’s comments, = I suggest that this text could potentially be written as something like:

 

      =

     &= nbsp;

   Client ap=
plications are expected to perform sanity checking of data
   received from =
a server and to handle unexpected or missing data
   gracefully, e.=
g., this could include ignoring unexpected data, or
   logging unexpe=
cted values for further analysis.  Clients SHOULD NOT
   discard an ent=
ire response from a server because some data contained

   within the res=
ponse is not expected.  Examples of well-encoded but=



   unexpected dat=
a received from a server may include:


 

   o  Values=
 that are outside the value space of a data node defined<=
/pre>

    &nb=
sp; in the YANG schema, but that are within the value space of the


    &nb=
sp; underlying base type, e.g., if the value represents an unexpected<=
/o:p>


    &nb=
sp; error condition on the server.


   


   o  A=
dditional data nodes, e.g., if the server implements a

    &nb=
sp; different, but compatible, version of a YANG module.<=
/pre>

 

   o  A grea=
ter or lesser number of list or leaf-list items than the<=
/pre>

    &nb=
sp; permitted range defined in the YANG module.


 

   o  Non ma=
ndatory data nodes that are sometimes missing from the

    &nb=
sp; response.  Noting that the server is expected to deviate any data<=
o:p>


    &nb=
sp; nodes for which it will never return values for.

 

   o  Values=
 that do not conform to the semantic constraints of the schema.<=
/span>


 

   o  Additi=
onal YANG meta data in the encoding (e.g., XML elements or


    &nb=
sp; attributes, JSON properties).


 

   NMDA [RFC 8342=
], section 5.3, provides additional constraints on the

   data that a se=
rver can return from the operational state datastore. 

 

Thanks,


Rob


 


 


 








From: netmod <netmod-bounc=
es@ietf.org>
On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)

Sent: 06 April 2021 15:10

To: netmod@ietf.org

Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06






 


YANG Versioning Weekly Call Minutes - 2021-04-06


 


Focus for this meeting was going through Jason's rev=
iew comments for section "3.1.2 Backwards-compatibility rules for conf=
ig false and output data" of

https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02=
.  



 


(A)


Valuespace:


- value space (with a space between the words): use =
7950 meaning/definition (remove the definition in our draft)


- make "must" its own bullet

- don't particularly address "description"=



- Balazs propose updated text


 


(B)


replace this:


 


"an additional state leaf can easily be discard=
ed" 


 


with this:


 


"the presence of an unexpected state leaf is no=
t typically a problem and may be ignored by the client"


 


(C) 


replace "config=3Dfalse data" in the 1st p=
aragraph with the following (and keep the quotes - that is how RFC8342 pres=
ents it):


         &nb=
sp;      "config false" data


 


(D)


Lots of debate about the "client" bullets =
in 3.1.2.  Didn't conclude.  Perhaps just summarize and say clien=
ts need to sanitize data (give examples of data they might get, values outs=
ide range)


 


ACTION: focus on reviewing section 3.1.2<=
/p>

 


----------------------------------------------<=
/o:p>


Weekly webex call details:


Meeting number (access code): 171 069 0374 


Meeting password: semver?


Occurs every Tuesday effective Tuesday, September 1,=
 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) =
Eastern Time (US & Canada)



9:00 am  |  (UTC-04:00) Eastern Time (US &=
amp; Canada)  |  1 hr 



https://ietf.webex.com/ietf/j.php?MTID=
=3Dma7627a2ae7b770537cff5f5b89293c70


Tap to join from a mobile device (attendees only)


+1-650-479-3208,,1710690374## Call-in toll number (U=
S/Canada)
--_000_DM6PR08MB5084935EDB6AB7718B695BAA9B749DM6PR08MB5084namp_-- From nobody Thu Apr 8 11:51:39 2021 Return-Path: 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 874D03A172E for ; Thu, 8 Apr 2021 11:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=jacobsuniversity.onmicrosoft.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 yQSfzmoNqZ6f for ; Thu, 8 Apr 2021 11:51:32 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2059.outbound.protection.outlook.com [40.107.21.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590BF3A172B for ; Thu, 8 Apr 2021 11:51:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ONkCLr1GSTW9jnuVX4yN/lfhka8B2Zru38r8UJyV0Qt9h9HO3OCRc8eX6PUYjfHKU7zkVujLp6tMRt6KfFUsfqxUU7p4/ZMz9D0RUxJ6Aa4n2w0H9+DFs7crt/6HXXsBXpxxFTcv5KoWVY4LUYF6xpb7vhaur8F1oXuxSdoaCDgFjMwokI+28lCcwqJVz5T/FJieAPBVIV7Ti7k6hVwrsPTU/cz7XcUkiKhnkB61gL160u+mP7cmCPbi5DGG191n353S7UOyso3fNlWSdcowsF/uy1o7Tlmr7ZOwm2D119RLkJfup0tjZiw/fXerLMHns5c3z10t2Nl3kPI31NyGlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7eqhc4gtRN5taavIuz97U/9h89RznhkQroYdxH6LQNY=; b=HG0q7IAWnaoWND2fszjhLiyFVFKc5MsHCQSLpl7QDU6nnvWIlWqX/sh/mV8AV5brN421pu2uSF3UAV7GrFVzY6RYwTq7OFpjvZTQzF468gmfSUB6Ip5pjbE/P9h610nHcdfJAgXAc+cijjrtsCRyjWAsUzUDcNhO+KsnMa8tE924BQeDrgCXDdmb+J+fZTBIcBV4Mi6XUb0sbEJdXoHbJ31g5JgOjUBJTnYYRTagjlv0VC1nAFM4RvwIBLCc8/kRY50k2cOuCWl0RDDNoOfYCxjlaUhp2EkRC17aVtvyYbFt2Zg7hOn6dXUiBCn8ADSNteKSkPJk8gLmiprc6ZauQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7eqhc4gtRN5taavIuz97U/9h89RznhkQroYdxH6LQNY=; b=OGXm6gJ8WzxVy+XiDG2GrbqLc/sWLBR/KE4dYCKOKGijBplGUGTb8IoM/edfKS95qpw/f0zVLaY/TLTUWyoHjcrMSzSlTzNEo7dYYeqMo7EWYX4U/w+AeUGF8v6Ffhr5HwbyizAOw3i36Sp/ht/VJHg0YCuD35S6z6ALeit8K34= Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0611.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.20; Thu, 8 Apr 2021 18:51:28 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.4020.018; Thu, 8 Apr 2021 18:51:28 +0000 Date: Thu, 8 Apr 2021 20:51:27 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "Rob Wilton (rwilton)" , "netmod@ietf.org" Message-ID: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "Rob Wilton (rwilton)" , "netmod@ietf.org" References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR02CA0218.eurprd02.prod.outlook.com (2603:10a6:20b:28f::25) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR02CA0218.eurprd02.prod.outlook.com (2603:10a6:20b:28f::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17 via Frontend Transport; Thu, 8 Apr 2021 18:51:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e51cd95d-801e-4814-766b-08d8fabf517e X-MS-TrafficTypeDiagnostic: AM0P190MB0611: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IAahPyKI/2NBpO2GUC/hkbge3g02kul0e5WTT2aKtAOygFIjQPv9ZY/5UnuPlAGfq2LRZ6Ve3+Blz+7pX16nvVQ1zZmNY1IFNs1NkIHIkpqi5kBivfzZv/lh0HKj+3QMgrTSdDQrQhQm4SwRQQyST27J1V5xNGJJBUsIqgqrBN2WudujjeDZ6Uh2piL5+t6Y4AE0LZ1BWKv/pVxn9b88tEAcb8dsAxugVM8H8lIkLOBZbGCxiaqzxXZS9tcl1Fl2uC5TZUTzD7ppf7uKSzpUAtUhmut4Xkyp5w1OnPwY+Y+p47ZINHjITK6QeNSC1bbyqZQ//qQdAYkATQzACGYimocmPVPWkDaapCU3x78n4d1h8lGQmz+Ky9Az6/82CZKQNmkKy82S1cOV7f4UNzwreZydEbOExShVfFBIW5k65tNrKIt0rzBSLZsLvUG5KzITrYnlfHyhI+85+uV5VX1fshuoX38oUALKrq8H04SHuheSARzLwiiGSddm0x2c1Kkxz8hCmrwc369Reb06KbyoSR8L4atDzOGjPXQnkDPbU+gv1EADrGSeMgN/FwoxqozdV0d7hXmB4aSmqCWC7o7mfH/D95WS5uequ5YSsdIqAVY4WpcCzHUVaP0Z1J9uMRDULWlSIOwPo0cGQqx/TP6ZL+41e/bAhYl48zpNA1g/pqV3Ap8F5WLxIEBBKTUYXEMgDDsgubbbQgqOWUS1VTVeGyjjHQWq7j3kMGW6dhZ23SqAe35APjMLA3pzWM5g0zxX X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(396003)(136003)(39850400004)(366004)(346002)(6916009)(54906003)(786003)(316002)(8936002)(6496006)(296002)(8676002)(53546011)(6486002)(52116002)(956004)(4326008)(66946007)(66476007)(1076003)(5660300002)(66556008)(38100700001)(38350700001)(83380400001)(16799955002)(478600001)(966005)(186003)(16526019)(26005)(2906002)(86362001)(3450700001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?YOSXjZd/mhq862STKAJyPtWxg0oOvMvIdRRbvMn7Dz0ymyvLTXU09JR/eJYN?= =?us-ascii?Q?9wVVYMj9EOb70SNj8OnI0rtf7HH+3OJHfss9zjjy6pyX/Yx9PIqEhBWVrtio?= =?us-ascii?Q?kK36ZskqfoCY12+PkGZEZhmFczwz+15D0VEC7dotq0MX7o3DuphJbshGhMt8?= =?us-ascii?Q?OYumpwuUD40ZCeWuRwKbhUaio9bhMHtsXu2GTqgT5BIPvg9dyh7azCXKhCgA?= =?us-ascii?Q?W9N45XtMv1FvGACoyWDYnCjx6aqWHCjcHXZxDh8aqKi4/5fykHP1EFyQVcAu?= =?us-ascii?Q?zhEPZGsZDiR1/gAq/TgcbMr+xc2DvkmMuhacopP3bbPqRXJ9i0YFehPHzf1t?= =?us-ascii?Q?viWO+VSbRxgxvZ6hIbTYNc/QNwAmDdFUY0EFSQ1XbqjBllLFcDCY2oaP+sp+?= =?us-ascii?Q?H6dGkBfLfpTSUG98ke9uvRre2PVk+cHhQrfMX8hZsnto5PZjTPWx3yl/cVM6?= =?us-ascii?Q?/GfqPADNePE0T+977AuyyoPqnuiflStG/f8HRzr+T3CSOxJbEYELPKJUbB8i?= =?us-ascii?Q?nqarx84nY53FlKoaH22CjPSmwFtboRKWho42XgIgjqax48WGgTc9TI7nNkhr?= =?us-ascii?Q?tBcwA24PuWC+8CwheFxZ4sqJCUCKLkHfW7SRGhBM9bDEtPI1ig+2ciIC+5tc?= =?us-ascii?Q?ThpCijxsIay3jjlSwXVKCHR+FtpIVC3uNNNTjPqinRGa12K/Blf1k1UstQl9?= =?us-ascii?Q?yrMhgBEAVTIILyoaLzylKJqeQuIVL8/M3c12vxVDLVsZiDEyS1i54BWWbPvY?= =?us-ascii?Q?+AaEGjfH3HnkINvJrTURnK5UdXV53bgOScCqnepANFTG7O/VsfZXVUVbP0CE?= =?us-ascii?Q?t5+thj8XZ+xtpiJmZq/inSjORRAlHzLxxkf86oVTdTiZrxwjRq/LhjSommX0?= =?us-ascii?Q?HrFzhdveBO52zpIQoBi1lZV6ixE3JY8drE+ea583CzdhGuQ9gVWzpDKhFX96?= =?us-ascii?Q?qvV7mMgNWh5IvWc4TMMM3SWQ9A9zHNM3uiUYXccWWoETbpxh3K/9XpOhXeuX?= =?us-ascii?Q?JK+geLt+r1rey2elDk36CooLOw3BhDb5KEylfwjq0JW8C8x4aUuZORs31Y3M?= =?us-ascii?Q?AKwPHbjtEMzyv3ccWyzcKGRxXIiHC/D4iXim6dYtNJCFNrSaQIQjQZUy0lxE?= =?us-ascii?Q?aE+Q3Z6DNgMDP6+RFLAbrqvKeTnC5HtwkkOgz325VuNNvH8/8SPMAKASlAJ3?= =?us-ascii?Q?p2YsaDLWr1tELFxwiQWqPxuIy3AyJChRtNT6oUKQh/V2bTGV7AAcWpEn4c0w?= =?us-ascii?Q?303KodZdwYRxHraA+clHnA9xk1hfch/NjlDX2jp4H5T35Z+Pvbm5fvNSe6mB?= =?us-ascii?Q?fp1VbjYyR3J+khF6ngu3AB+7?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: e51cd95d-801e-4814-766b-08d8fabf517e X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2021 18:51:28.7617 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5b7lTCLUZWEv6rtaz7KzDEOSm1Lf27ibfxQbYrTuPFYZmk6A8dtIOab/h7ryP+IN9/s7xPk5ckyGP93Kt58Yxq1naolziz4NqrBFAUjhvfY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0611 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 18:51:38 -0000 Some of these make no sense to me and I wonder whether we really need to define these. On Thu, Apr 08, 2021 at 05:58:58PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi Rob, > I like the reformulation of this. > Jason > > From: Rob Wilton (rwilton) > Sent: Wednesday, April 7, 2021 5:19 AM > To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf.org > Subject: Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] > > // As a contributor > > Hi Jason, all, > > In yesterday's meeting there was a discussion on this text, and Joe pointed out that any sensible client must validate its input. > > While incoming configuration data is checked according to YANG > constraints, constraints on state data sent by the server MAY or MAY > NOT be enforced. The following guidelines are provided for client > application designers to allow a smooth interworking with servers. > > o A client MUST tolerate any data received (or not received) without > crashing. What is 'tolerate', what is 'without crashing'? Are we talking about buggy parsers or buggy backend logic or backend logic fooled by inconsistent values? > o A client MUST be able to discard any data that is not part of the > model but is sent by the server additionally (e.g. XML elements > or attributes, JSON properties). > > o A client SHOULD be able to handle valid parts of a received data > set even if it discards other parts as invalid. In all cases? > o A client SHOULD be able to handle data that is outside the > valuespace defined, as long as it is of the same basic type. Really? What does 'handle' mean? If a value makes no sense at all, what should the client do other than discarding the value (and logging an error)? Or is this 'handling'? > o A client SHOULD be prepared to handle more items for a list or > leaf-list than what is defined by the model. Again, what does 'handle' mean??? > Based on Joe's comments, I suggest that this text could potentially be written as something like: > > > > > Client applications are expected to perform sanity checking of data > > received from a server and to handle unexpected or missing data > > gracefully, e.g., this could include ignoring unexpected data, or > > logging unexpected values for further analysis. Clients SHOULD NOT > > discard an entire response from a server because some data contained > > within the response is not expected. Examples of well-encoded but > > unexpected data received from a server may include: > > > > o Values that are outside the value space of a data node defined > > in the YANG schema, but that are within the value space of the > > underlying base type, e.g., if the value represents an unexpected > > error condition on the server. > > > > o Additional data nodes, e.g., if the server implements a > > different, but compatible, version of a YANG module. > > > > o A greater or lesser number of list or leaf-list items than the > > permitted range defined in the YANG module. > > > > o Non mandatory data nodes that are sometimes missing from the > > response. Noting that the server is expected to deviate any data > > nodes for which it will never return values for. > > > > o Values that do not conform to the semantic constraints of the schema. > > > > o Additional YANG meta data in the encoding (e.g., XML elements or > > attributes, JSON properties). > > > > NMDA [RFC 8342], section 5.3, provides additional constraints on the > > data that a server can return from the operational state datastore. It might be necessary to write the security considerations text for this. From a security perspective, being lenient is often a mistake. For example, if a leaf is of type inet-address, I rather not have clients accepting any garbage strings as IP addresses. I am not sure why we go into this. Which problem are we solving by requiring clients to accept any garbage? /js > Thanks, > Rob > > > > From: netmod > On Behalf Of Sterne, Jason (Nokia - CA/Ottawa) > Sent: 06 April 2021 15:10 > To: netmod@ietf.org > Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06 > > YANG Versioning Weekly Call Minutes - 2021-04-06 > > Focus for this meeting was going through Jason's review comments for section "3.1.2 Backwards-compatibility rules for config false and output data" of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02. > > (A) > Valuespace: > - value space (with a space between the words): use 7950 meaning/definition (remove the definition in our draft) > - make "must" its own bullet > - don't particularly address "description" > - Balazs propose updated text > > (B) > replace this: > > "an additional state leaf can easily be discarded" > > with this: > > "the presence of an unexpected state leaf is not typically a problem and may be ignored by the client" > > (C) > replace "config=false data" in the 1st paragraph with the following (and keep the quotes - that is how RFC8342 presents it): > "config false" data > > (D) > Lots of debate about the "client" bullets in 3.1.2. Didn't conclude. Perhaps just summarize and say clients need to sanitize data (give examples of data they might get, values outside range) > > ACTION: focus on reviewing section 3.1.2 > > ---------------------------------------------- > Weekly webex call details: > Meeting number (access code): 171 069 0374 > Meeting password: semver? > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Canada) > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70 > Tap to join from a mobile device (attendees only) > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 9 06:32:25 2021 Return-Path: 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 A25C03A2151 for ; Fri, 9 Apr 2021 06:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 yZgmBnMUQ-1S for ; Fri, 9 Apr 2021 06:32:17 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2116.outbound.protection.outlook.com [40.107.223.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0143A2150 for ; Fri, 9 Apr 2021 06:32:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=do9tcUhg10V1qDB3p3k+NjbCH9MvDRAKEytyzQWLdTxrV5GBRN7KF31SFocpRd6UXQAhlK0ZIATPz86IMxrMaSdzKOjNHRG5LMZnHWCYXcQHV5JntOJRXC/ltb0FDeKZ/O2e48RWXJ/044f0buT2eL6srfg9GMyrPktGHN7duf8jsuLn27xT0Y/Ph//2xEuEYaIDOXGmcLrDgvpbTSvtB56vOOhri5wnKhUb6ugBBwuL8TTXjHoZJvMkVyg4Kg4GkPiVGR2peJpP/AQI8mFQq50qMfT1+3i1elqwNwUYG7u7FOLEcxuD3G18ryo7HVevjOEplX4H2V5U4TxSp68J4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SKdXH0LKRQo7++1OQGWRVouo/5H/EL6f4o4rc+epOVY=; b=JiSIPKsHWpG1JJiCYZQIdfwgSPCSBVgoZa/htDAmy9LuUhumf2RrT2a0CeeuQJEKZpBPv5PkkdbPYnrMfZYDZJWoV+xuVST72fkvaeUlilKs5u5sJm8kg6ys2u2Vrrh9KHRsGEKrxi/XjxCp6WhbIZSyMPA1vufwWKIdmsxNw63oIAYgERKMws5KDp54sZDmKK4Qb0qhL3ssct9SwDPf1QcClPTqbGk7dM/grKrSNWfdp7+48g8AsnvSFFESuLAnX70f3fr/90c8SsBLzs8nJFEP38WM0dGeiZ7Q97R0eKpJkIe7N1EfHy2Et1HvFfrAHNvWCs4QhWsXYKy2AOsumg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SKdXH0LKRQo7++1OQGWRVouo/5H/EL6f4o4rc+epOVY=; b=xaFCDD3KBG6Uvvb8K/MrpelgDyLK+ipeepMi+B9peYfeKOngheXUwyvM9ZhmzQZ1eqzSyQSNLsnVmBftthWLsloROQp2ndiMphDsGCagTf5MyYsK6s5vSznDrT2XPJDywGFgyyQ+uY3j4UhEu11JlJeOHNrXLHNMbb4ZQ4TizHY= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB2859.namprd08.prod.outlook.com (2603:10b6:3:144::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Fri, 9 Apr 2021 13:32:15 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3999.036; Fri, 9 Apr 2021 13:32:15 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder CC: "Rob Wilton (rwilton)" , "netmod@ietf.org" Thread-Topic: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] Thread-Index: Adcrjvs0u1Y2kX7cTWaMCLlk2EmADgBEca5wAAHbCoAAJt+v8A== Date: Fri, 9 Apr 2021 13:32:15 +0000 Message-ID: References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> In-Reply-To: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bccd0f56-d55e-4ad7-b08d-08d8fb5be3f0 x-ms-traffictypediagnostic: DM5PR08MB2859: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uAVcVkLnDUJBKy49Zk493kVA65PpUqu5wAE87+DGCoZwxHJcreMfPg0dZyeoqSWTmseszDqMq4OJzdiA4ndC40wTwSqUGTEl//RPZAAGB+mRrKxhDzJ302UVqkl+Xehb+u9nCwahwGp+Q1+m4bG/YpY/5Nf0HL8uFituPr1kayAvsJY0pNBL4x4A1XaWJzCeEdiJQBZecqyvUzQsWo+7974y4jqSzREpu5cDeKRcT0GBPhB/whIMD5k3/us23dYc3ysd3K7k5KfxSRUuPJpjJ1uHJRXC/jW49H91uxzi0x5l+JXN04UHbOx6LLhl7FhZf42elbOndgcr7cI+SGSYX3AvHZYrNQsp9os//JxjqUv53yqLEYc8jr+iiEyU2jE7jJFtbVL5gObB3yyJ7jX4wZfeHdwUek9mkn+mHH22WhjUK4NSK/yusAFLP4bnVTKaXSRbGYJTClP/1Mg+GoFU+JRCfkiknQvTnWnuq5TsHbfm/Zizjhf/kAHU9GPc6xCcbrPtbGkBJZGIx50NwFlt5rpfQ1plghteu5sjcX9LxDY2QP0h23+2CH/NR9hr2arIgwbQY2jB38NnNyjsDekJ01GFUCWp6qYlg0RaXUixSinHK8hk/T23oYW3CneIYZ8bXanpEnEZ1+BGHBMSSpgfkbAwKEzL3Mr3xPgY68RYqAxr+7rCI9psPZnmwkM0yvSIDK/8fyLzkqLQ7IMuKYGUeppQqL03q8aMHiIk12lXMjk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(366004)(136003)(39860400002)(346002)(55016002)(71200400001)(33656002)(16799955002)(316002)(966005)(9686003)(26005)(7696005)(38100700001)(54906003)(8676002)(186003)(66556008)(5660300002)(64756008)(6916009)(76116006)(86362001)(52536014)(83380400001)(8936002)(6506007)(53546011)(478600001)(2906002)(66946007)(4326008)(66446008)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?4D2aF5SmfC3s0frXEtIcsUgos6gkWR4tpZrJtiptSmBrdhaALe3MKzGwtcmI?= =?us-ascii?Q?QrFlv4XhM3iHa05M17aJ5X4jS5k6/S90I9+9SzgiTKIa8Xfe8U5lqgpkeFtS?= =?us-ascii?Q?rlK/zYTfQryRfSLUEHApNiaRrO5vsFo+P6pl/IEceFGXnyAMEpik+H+8bZKw?= =?us-ascii?Q?s48+6SZjZ+3N25WK3OJRNz4JkAxDeEDraM0yGtj36VEf1jg8tIhjQRUyMHO5?= =?us-ascii?Q?NyVXJLrUtIcfmyxxG/yUIN/mYtxItoCHtzLxlCG8/0CsMuv7pY7VJ6kntowj?= =?us-ascii?Q?RAHig92d9xv9zWmbDPu9dxB2IAh1B2slLo4SOjJWjlYU51qLo7VRXVdF2Iv5?= =?us-ascii?Q?+XVvuuCpw9bX9sBm/OAvYpGtrDFYMRwQvDP96/eoqd9nuSAf4TTL/OZzzlQy?= =?us-ascii?Q?yrCtLhExCpZbQGg8BFWbPDUwMIVjymB2B4BA1+d8Q0Pu9YrRSlTErp1Dv/FM?= =?us-ascii?Q?Umb7Ogv+lZzlBwK50ZDcpkwKnlb2AUeM65DvESsXzK2nUeRooQ3X0fNPRDTN?= =?us-ascii?Q?RbUo4UPBEZLsWFf7Jl6EvOF0E0faB0G4O75IOFCMEXbuQt4ZSeQSsYjez6aO?= =?us-ascii?Q?wxKzEtaIS7t7u9HTtPRCLgunTC4skiSwLp0hQLv8c67m/lFvjDAou6CBXbgm?= =?us-ascii?Q?Ebnm6SpBMR15jJ+Wo9PiTnTog8i53oT6E51iY8M08gKGDuuCxypql2FCA05F?= =?us-ascii?Q?UuIzv/O73oluUay5voe0UMXmqi0ocW6y6ETpXhdAczJjcxKNPMc5LBo6Is8A?= =?us-ascii?Q?75lWIBinfi3/IqUj3+0MzuMhj8tX3Sr89qTDFn2Ho57eDDjUiJT8MzQeF5oB?= =?us-ascii?Q?kRO6zvpiEgkqPZAFJTJ0vwqgKpoEbs6ptfE8o7YpxgRhlPayJbbrj6ljHQ8/?= =?us-ascii?Q?VoRIVSLezz+vMlDn0qb+urmwTPJy1mSA/0kNeUXJvcLiPsqdI89ciYXlZdG3?= =?us-ascii?Q?zpDgPV7RWDvO5ZKgLg9qYvAuOrwJDVChySi9E8sjtprISd1LSSEWP8qSPHXo?= =?us-ascii?Q?8nJlL6NSE4G/kCM3cSn8CLpAwE/UVx8S3LlzOS5VR1/Uc8MuLaQvgvXRHg+s?= =?us-ascii?Q?Ip2xhigmn7CLlFauky9VX5AnPkF01NCvNIclIHiGVBQ5TgQ5hxSuHpBOQtDg?= =?us-ascii?Q?XiMIPE0U/ZS5Scpn1RThbjoJrcAK9EfBMAYYe/1NTxh8XlRXKZONzZA+64rH?= =?us-ascii?Q?iGI7xTCef4q8rbhGfSVi2WJ9yfgBKZarIShZhiUkJ5H4CDigyCobgx9FwRmi?= =?us-ascii?Q?DvR0bsnbXBivPyRiGgeGypV++HC5iz/7llTg/4tE1P791nCYfnaxYtP06f2Q?= =?us-ascii?Q?liEdpM6mipMVf0LPbc4i73Nn?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bccd0f56-d55e-4ad7-b08d-08d8fb5be3f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 13:32:15.6543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Qs8rPa8GJiq4J4ztx/LLUtqGroIcLJftAayTYK4flgXI18RHZ8wo5d/kapg1i2OO4eLestMe2ex9B7x6EbwFMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2859 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 13:32:23 -0000 Thanks for taking a look Juergen. Note that the first part of Rob's email was the *old* text that he suggests= replacing with the bullets in the second part. But some of your comments = in the old text probably also apply to the new text. The root of this section in our draft is that we wanted to clarify how to d= ecide if a change is BC vs NBC for *state* data (config false). Our feelin= g is that we may want to refine some of the rules in 7950 for state. =20 One key example is this: 7950 says that adding another enum to an enumerat= ion leaf is NBC (and that applies to state). But that may not really be how= most implementations would want to treat state. Would we really want to fl= ag a module as non backwards compatible when a state leaf gets an additiona= l enum? Wouldn't that create a lot of unnecessary noise? Jason=20 > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Thursday, April 8, 2021 2:51 PM > To: Sterne, Jason (Nokia - CA/Ottawa) > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > Weekly Call Minutes - 2021-04-06] >=20 > Some of these make no sense to me and I wonder whether we really need > to define these. >=20 > On Thu, Apr 08, 2021 at 05:58:58PM +0000, Sterne, Jason (Nokia - CA/Ottaw= a) > wrote: > > Hi Rob, > > I like the reformulation of this. > > Jason > > > > From: Rob Wilton (rwilton) > > Sent: Wednesday, April 7, 2021 5:19 AM > > To: Sterne, Jason (Nokia - CA/Ottawa) ; > netmod@ietf.org > > Subject: Client validation text [was RE: YANG Versioning Weekly Call > Minutes - 2021-04-06] > > > > // As a contributor > > > > Hi Jason, all, > > > > In yesterday's meeting there was a discussion on this text, and Joe poi= nted > out that any sensible client must validate its input. > > > > While incoming configuration data is checked according to YANG > > constraints, constraints on state data sent by the server MAY or MAY > > NOT be enforced. The following guidelines are provided for client > > application designers to allow a smooth interworking with servers. > > > > o A client MUST tolerate any data received (or not received) withou= t > > crashing. >=20 > What is 'tolerate', what is 'without crashing'? Are we talking about > buggy parsers or buggy backend logic or backend logic fooled by > inconsistent values? >=20 > > o A client MUST be able to discard any data that is not part of the > > model but is sent by the server additionally (e.g. XML elements > > or attributes, JSON properties). > > > > o A client SHOULD be able to handle valid parts of a received data > > set even if it discards other parts as invalid. >=20 > In all cases? >=20 > > o A client SHOULD be able to handle data that is outside the > > valuespace defined, as long as it is of the same basic type. >=20 > Really? What does 'handle' mean? If a value makes no sense at all, > what should the client do other than discarding the value (and logging > an error)? Or is this 'handling'? >=20 > > o A client SHOULD be prepared to handle more items for a list or > > leaf-list than what is defined by the model. >=20 > Again, what does 'handle' mean??? >=20 > > Based on Joe's comments, I suggest that this text could potentially be > written as something like: > > > > > > > > > > Client applications are expected to perform sanity checking of data > > > > received from a server and to handle unexpected or missing data > > > > gracefully, e.g., this could include ignoring unexpected data, or > > > > logging unexpected values for further analysis. Clients SHOULD NOT > > > > discard an entire response from a server because some data contained > > > > within the response is not expected. Examples of well-encoded but > > > > unexpected data received from a server may include: > > > > > > > > o Values that are outside the value space of a data node defined > > > > in the YANG schema, but that are within the value space of the > > > > underlying base type, e.g., if the value represents an unexpected > > > > error condition on the server. > > > > > > > > o Additional data nodes, e.g., if the server implements a > > > > different, but compatible, version of a YANG module. > > > > > > > > o A greater or lesser number of list or leaf-list items than the > > > > permitted range defined in the YANG module. > > > > > > > > o Non mandatory data nodes that are sometimes missing from the > > > > response. Noting that the server is expected to deviate any data > > > > nodes for which it will never return values for. > > > > > > > > o Values that do not conform to the semantic constraints of the sch= ema. > > > > > > > > o Additional YANG meta data in the encoding (e.g., XML elements or > > > > attributes, JSON properties). > > > > > > > > NMDA [RFC 8342], section 5.3, provides additional constraints on the > > > > data that a server can return from the operational state datastore. >=20 > It might be necessary to write the security considerations text for > this. From a security perspective, being lenient is often a > mistake. For example, if a leaf is of type inet-address, I rather not > have clients accepting any garbage strings as IP addresses. >=20 > I am not sure why we go into this. Which problem are we solving by > requiring clients to accept any garbage? >=20 > /js >=20 > > Thanks, > > Rob > > > > > > > > From: netmod bounces@ietf.org>> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa) > > Sent: 06 April 2021 15:10 > > To: netmod@ietf.org > > Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06 > > > > YANG Versioning Weekly Call Minutes - 2021-04-06 > > > > Focus for this meeting was going through Jason's review comments for > section "3.1.2 Backwards-compatibility rules for config false and output = data" > of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-0= 2. > > > > (A) > > Valuespace: > > - value space (with a space between the words): use 7950 > meaning/definition (remove the definition in our draft) > > - make "must" its own bullet > > - don't particularly address "description" > > - Balazs propose updated text > > > > (B) > > replace this: > > > > "an additional state leaf can easily be discarded" > > > > with this: > > > > "the presence of an unexpected state leaf is not typically a problem an= d > may be ignored by the client" > > > > (C) > > replace "config=3Dfalse data" in the 1st paragraph with the following (= and > keep the quotes - that is how RFC8342 presents it): > > "config false" data > > > > (D) > > Lots of debate about the "client" bullets in 3.1.2. Didn't conclude. = Perhaps > just summarize and say clients need to sanitize data (give examples of da= ta > they might get, values outside range) > > > > ACTION: focus on reviewing section 3.1.2 > > > > ---------------------------------------------- > > Weekly webex call details: > > Meeting number (access code): 171 069 0374 > > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday= , > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > > > https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293 > c70 > > Tap to join from a mobile device (attendees only) > > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) >=20 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Apr 9 06:39:11 2021 Return-Path: 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 9EA7D3A2183 for ; Fri, 9 Apr 2021 06:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=jacobsuniversity.onmicrosoft.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 4TSyYfj69pSe for ; Fri, 9 Apr 2021 06:39:06 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2068.outbound.protection.outlook.com [40.107.21.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EEA3A217E for ; Fri, 9 Apr 2021 06:39:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EmVKKINWeSXoc1pAc+RXxf3MoLWVoQRr99tm9iGKx5A+0Gr31kg5fyd8mrRoNK+n+ok6QPF1hKYU48aTQnCStZqiCsrlwQbgM9ugyF53p2TQS51e14jOhhucT7HrP8embAmKa/3d/VErpZJ8qwtfzRTZxDZ1Or2zK3x76N/Sx1DiAk32IscEXe4SOSyOMHhe3fUC/pf+pAUPHF0d7ksB8SBta9JMfn0Zu2psSZc8DSyMLx6i4gePOAvuUeUAwf4ea6WDM4iHtu+fj3mvzLeGWdjeddUZAyYVscen7RnFwz9xfm8+zN6GWhV7RU2dYVP39M265VopYACeuz7BegQGiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F7aXvHhR04i6nZwevd1m2S3yUty7eW25zBYOd3HPUZU=; b=JGEbz1RUp74n6C3Z+UoLBmlPxQzNC9ZzSfxjMjaONI47LxiUX/NAqYi1Api6Pyw1szOjEd8GGbIhSZNFraapjHkTBgJIPC/lhhUpgDuJNrFFhzsBZ85tDGfY+4bQsusRXT4NKuezpRDZi5rOHuBHRvflu7ehmqJFnITStNFtClEeRk0irMFyQscWpookc5bCvCU2Oqo07d0g2Q/edoEdc6l5lrK9rjshha+p8uA+Lihz/K6jnvmWIpG9utppwZSCjA1wKZxTNhNo+5ojquo5rFQ1g3K5sr6WzljtzuqhCB9o2H2QV1aJFwS8D1B12nq91xAgf//Q9cydjpk5Vdjdkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F7aXvHhR04i6nZwevd1m2S3yUty7eW25zBYOd3HPUZU=; b=uLd/L07LrdD350WJPFx0yAsjW0xsYCDrhNSp3PP76fd3ZwM/1r3mQpgQGNi+Gil2TyRTp9aPycW4OM8y62BptZ7IQ6h99Pg8cT1Xydkpr/E1bvgfFvCWVUMWXjCvsKrb2MOHwv3gGG3tExntgGpfKE2eTEi+3B1AJq64Z+Mg23s= Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:64::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17; Fri, 9 Apr 2021 13:39:02 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.4020.018; Fri, 9 Apr 2021 13:39:02 +0000 Date: Fri, 9 Apr 2021 15:39:01 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "Rob Wilton (rwilton)" , "netmod@ietf.org" Message-ID: <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "Rob Wilton (rwilton)" , "netmod@ietf.org" References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR3P191CA0038.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:55::13) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P191CA0038.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:55::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17 via Frontend Transport; Fri, 9 Apr 2021 13:39:02 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f753661b-228f-4995-2697-08d8fb5cd65d X-MS-TrafficTypeDiagnostic: AM4P190MB0003: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 91SPltKDt6i1Q1e52UIIjxWBdRZndvQMgbfW6xVLbNx+CKYyDq5R9x4XTruRBu1FV/eP9EXRb9AUhAlKwmR4B79TY060SvKAVB9dvKxmytECX6kqFUVLTB6tZG/HyoxF7OSrYTzFzniobj5x2BpuMiVKdL7bg9R8UEYZker2mjbbn6ELDLrTAI2Ko3MjUkzAf4hJRY9SYeKJ485uP3acolkHPrDhGMHJeqhmPl6m5R8FIcgMprlcguCSut4sJV7yU6oe4qVP9CfRTdavbA6hJr/qtS15Xs+pQU0OGnWYPP6w5hMy4ISg+EJzhZP+hQPHgSevn31/nR48jCBpUHPe1es3lshwMbAvJdDy5Jsc2h8psAhKzyo2t0uxLf6SueEQkoYsOZvQhbwMht0D+fcPRa2UAX2aEQSDJ9MdR8VghiOh9PgPZ+OAOvAOTAHdxNQCasqSkdMOtPsn1LsguQbVU8MTWgdrrH2XYjLrojdN69oY6h+JkLQ++VbWT8qpQnbQXUK9iARdBIOYJUqQtxlU4lrWcvN3Jl/0Yq9wkBj9iCRuf5O/NCjFrUKPn9W/LPi/nUblxam4Crw+Wz+hNyZuQ6vyx3idbud/7/evTioHHeO2xZNI3UBRH78BhG1FU9Y4g/TaIg/DbrzGWpVFOYHPWGadLXQivO+iu0vq0iUib8myGvdTcWiEGIGpKqxZ0uLKLLuDP1CCYq7g3qxMghpOf+YdHVoaPlfNZjE2FGjsytQWYt9GsFPuEJOtKZ81s+1o X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(39850400004)(396003)(366004)(376002)(66476007)(66556008)(38100700001)(86362001)(66946007)(38350700001)(5660300002)(186003)(26005)(2906002)(3450700001)(16526019)(1076003)(956004)(83380400001)(478600001)(4744005)(6916009)(8676002)(296002)(6486002)(54906003)(786003)(316002)(4326008)(8936002)(52116002)(6496006); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?E2VRUstTusyZlVavReTquVuJhN9qJ9EEw9yfe4V6JaXfvlYiUEhuLAi1je2o?= =?us-ascii?Q?oZU8tB773mW1PJpplnviQ1DEaR38QrgS8CVh2db2QQfaapT7QDiVyEpDSKfU?= =?us-ascii?Q?vU6RsZTKM6QpO36u4zFCsePNFK5FPzDQ/AZqKGRt5aQR+X/CQa8BknQ4ylzT?= =?us-ascii?Q?jYMpkpqVIvVqzgooWBNeCc9I6lIWOxpnZBhGmGy5o7Z/rl7gJSkEn5GA1zGX?= =?us-ascii?Q?o2HV3WJ3MtImeOEUU37nSbtrOjeojPqSIZo6jQKB34trQ9YCyOn+4To2eYQI?= =?us-ascii?Q?UpE03eO4ZVEy/vyjBjs5BT+qRkXJLHpXiQyBJXDAolkv4KeiJQf0Og3lfZr5?= =?us-ascii?Q?K5ymE5N8YrhV/OwqL5SsrnHdXqhUiZzKeR8OBd0rZWQx1PnAO6+aLkEx+LqN?= =?us-ascii?Q?TF35uZYjJQoYh+O3w0ZLtbhgywiyGrxsTAjQyvLSrGPlaAUr7nf/JhQBdd/O?= =?us-ascii?Q?IjNcYTsoU9dG2g/oJjRsvS5q+JS89vBNfuCaNm9ICw4im5VV6Rw/wRuP7iaW?= =?us-ascii?Q?Nj2sS16kiOhPlTsHmlfFvOvl7HlAgsGapPPg6EUY4YEZybXQkY2FonW1kClQ?= =?us-ascii?Q?3rvSTTOTnjrD4BnlpHMn5ZONIR29TLjZura6OdbdgdZBx2/mfzI5rj8kdiVc?= =?us-ascii?Q?BjebyNFjAVb2fu1KJQDo3LcdY0jQSUZYaBUUN0WbEb2mo5H9Sn/xOMlXeeEd?= =?us-ascii?Q?xUwn849t4v59MovB2qfuVwCiOpwJU6K2CMNYxrcWOEbIbLpBzrz0jtTMB7Ve?= =?us-ascii?Q?El24Ngag6Cgdgwqi8EJiTLcahJ0g/X6hzMTSHFRh6q7GJJEta8CcN9Pl1gCG?= =?us-ascii?Q?nlgqQogUmJC2b6xBZncaKKXrbZo+N+gKoWknTH4mljwidhtVtKI5X+B1WynH?= =?us-ascii?Q?HDn32bsRs3S167aJ2U9hPzNsYdW+d/zpBRWHZSlzWsNq9YH1BlhjKbqv1xOf?= =?us-ascii?Q?0XJQ+MgPBcEZNKV9iSNesfHSJzGgNEL9KSszbkdtKx0HR/nPXGExm/f1OfdP?= =?us-ascii?Q?evdRB/zBj6TOPYOibZ6j+ci8JWZbsBqy1Kx5JEDF8NjyEAONaZHph3Il9KLO?= =?us-ascii?Q?cnP7LJMv9j8i7nqVg5cNEohFB/CHPSyhLU3tQXIbJLsz+yXNOND4fdwH9Fsh?= =?us-ascii?Q?kdmLSar7IYwMBTlnjIFF/UfWybPcA5q26JcS/RBGdLcA4yCks8E5erdMBcjP?= =?us-ascii?Q?5Ug0BsCw7ZxQ0ceSmGHDqsp4kDZn/voyIy4x+cllDjYwCmUg8f05by5jiCxX?= =?us-ascii?Q?DSBX8U9+pPh5vb2uM5nRdfFZNAsMHgf4p+1dvKJ93FNDMAl1kenjdF8F9Rcr?= =?us-ascii?Q?BChNL7WWvKFfMFt5jUULM8rI?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: f753661b-228f-4995-2697-08d8fb5cd65d X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2021 13:39:02.6101 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: anPOpqqBWVn/q736XmoHDf9FYR/zYWOZkeCLpR9wZsBJxcAfKaZvaOfrfw2MBmMc4F2loC6J2J3hPGMnz0qOGulWfgwyQXra5RukDo9/4/A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0003 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 13:39:11 -0000 On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > One key example is this: 7950 says that adding another enum to an enumeration leaf is NBC (and that applies to state). But that may not really be how most implementations would want to treat state. Would we really want to flag a module as non backwards compatible when a state leaf gets an additional enum? Wouldn't that create a lot of unnecessary noise? I read this in RFC 7950: o An "enumeration" type may have new enums added, provided the old enums's values do not change. Note that inserting a new enum before an existing enum or reordering existing enums will result in new values for the existing enums, unless they have explicit values assigned to them. What do you want this to change to? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 9 06:43:17 2021 Return-Path: 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 3A8A93A219A for ; Fri, 9 Apr 2021 06:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 VtBO_BE0qad6 for ; Fri, 9 Apr 2021 06:43:11 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680097.outbound.protection.outlook.com [40.107.68.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA033A2193 for ; Fri, 9 Apr 2021 06:43:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MQjKV6apAnYMM81rU+p9g/+vCFlJqmNeoPDAJdOFAYJFNK1tQVwIlUMCd4+yZctDXEBe/J+3YXa0dWg1tZvYd5necPkd8Tou74iBvoqvSPZHeMjncLV0a31APkB68z/9vw+DsQO5YZz72bIl/3EfGRF4iuD5LrwZ0tHZ+L2yh+kS4tp0odueh5vgiZOP0U+8ngCr9+8xDau56O8YoWQFSdmNXm4Og6Akx1Q7Z5cj1WfLsoELE/X1daXXtDYmIe+8+Bo5jR95+EquJ1BesMFdzr2SNrShO2niDqL2usTmFZ/Muu6qMowRgpmwyeI9MeMXTdCL4aoqJCNMUoDkI3hhDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oNLB8Gg+J0w5royPYU9jsKYOhqDH5CkI8r0hlXLotMM=; b=W0bgszp7f3MxcLGaEgrCeZqsyTtKjZb5BJ3MrwsQySru/Nj2P9Pme+PBAZVKkeAtcdcCViZCTsdzp7XVZm5kXqsEgdA+BNU2w28QkdM4dh82k64gmkZJoUbfarHN/m5UmQHl4kizM38pvL72x9dvY6wHBFqJRJHTt6Geg7BAvI/ie7THU3QEieWOr4XzvKcFz4YpiNX512+w4oc7POOJ6j/+WXC4efl7gQ78n1k0A+M709prIQOUTLd4NG/p1LSExdfz+GxSNfuYg6UUMpTzpKrwdZZPFpSkt+ztY6zyTC/nLAjuudoheonMX7z7orjz0eJwSKind35IaUfud4h7Ag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oNLB8Gg+J0w5royPYU9jsKYOhqDH5CkI8r0hlXLotMM=; b=X2jGQodZdV1MdwETuzpOBUzAFJF6voDxxkhxwFa+PBGtcUehWIef9f0PoP+PmhQE/WsLcuh4UX8NF4VTKl3nGa3VEnjjT83ZEW4Ctt0OlQUb7HHpvMa1tGR7P/+zW24Bagx8Xb5iH3gdiiQ/pmpB91aO4m8WLZ4twZGtKAOmHEo= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR0801MB3688.namprd08.prod.outlook.com (2603:10b6:4:7d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.32; Fri, 9 Apr 2021 13:43:09 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3999.036; Fri, 9 Apr 2021 13:43:09 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder CC: "Rob Wilton (rwilton)" , "netmod@ietf.org" Thread-Topic: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] Thread-Index: Adcrjvs0u1Y2kX7cTWaMCLlk2EmADgBEca5wAAHbCoAAJt+v8AAAgYyAAAAa8OA= Date: Fri, 9 Apr 2021 13:43:09 +0000 Message-ID: References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> In-Reply-To: <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cd96295f-e1d2-4854-6c62-08d8fb5d69cc x-ms-traffictypediagnostic: DM5PR0801MB3688: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1WX7ewAwLMRZ5WaMMqqoLe1kZdW2M+PRi7dXkF5Z5hFTKthrgXB7GbFi4DNuiH3q8yTMJL5SrqRgsJfHMWMyEXUOrYNukY1oYw/W8GwSAodFKaWc+BASHTd6owpuShkTHkZw5QdmiqB2RxC1kweMeQm0RdBLLV/pUFKLByMIwVPL8B/YZuJ/EaeSmeZoO8cB9CE+JFQJ0XH0s9BaHNPKfbuR8Im9bxVbKQrXRVZ+X7WqSl5SNtrBv1uI9VRLOCEoLnkevrHFMZWr/9WgOEKydizaXfOlnzadqyeoHbJhlySIYDi3MsuEwhDo2L2JDUZzlIqGh5FFebQymlH/jEIylczl+Vog3QtXjsyxqlWJJ9I3mku2Z/9NC7VL45NtMDuiqfvvbzwIiUlznI1xAGIs0vobuvffEhuH4M9uOS3WjSsYH1ONKNzv0CVE07QnlZ/BeOndCGvobB8o9rw2vLqQ1kjp+sU0W8uBSE3kpFvMgdqtssSrsuUFtGLiA9Jxt+XfxjB/ezvvf8TCRE/MWOUkqtnMvVcEk/LLzEZ9WtCetG19KH62hWeEdv53xPCJ9mfY8EKrKmcz9OwOW5C8BHgMMHJtNYwuxGg++vRkVN/9F1Bqzh0YiDigWsfPt9asBeKQcXmprgvFxPRys1kB7iJkD9AAKLSFzVMz8at2hWUADjF+QSWN8UN8lsv8Pcv5Fzjij01BQSWjglKN1k104pV9jZncY7gqKKwyFMK3w7klcsw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39860400002)(376002)(396003)(136003)(54906003)(52536014)(66946007)(316002)(76116006)(38100700001)(186003)(8936002)(33656002)(478600001)(71200400001)(86362001)(8676002)(66446008)(64756008)(6916009)(26005)(66476007)(6506007)(53546011)(66556008)(2906002)(55016002)(5660300002)(9686003)(7696005)(83380400001)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?YFujJ06C45kdffXAsB2dPvNYoF0LA20xiU3L8G3gfP3UiJ7TTXzrJ0L1ornt?= =?us-ascii?Q?mRJorUaBhgD55ZoqcruVn8qc6q9iX+uQHVwHJ+PF8qAP7s2glvm2OPxPhN1K?= =?us-ascii?Q?XlRP6WvtfUvc+P/QipYTz3/h1YLGunQ7CbN+jVlOJXYc7nPDDu1VOWsZqqle?= =?us-ascii?Q?DaPgdM3stZYsWIh1M9JnJ5sDhhCvHOZDfkESqvtEhYj5OJanDPLktw+QGO1/?= =?us-ascii?Q?4JqaMHAiu0t7+d6ecNHHBiIKSkHpscl33G1rcoj07Etji+g4DebbqAHA1boR?= =?us-ascii?Q?BbooCY08Lh9CGFulT6hzziXGjaMOCyINpryWT3nNdKFRBgAXHASjpwglod9E?= =?us-ascii?Q?G8vQdxfJ4ch/yOgqNil0bUs1ZcHBNpawZlZ5VN27T7RD/ovWAoC8qkwFtP06?= =?us-ascii?Q?tLu1+lqNoq6PS+0h93gV34qb0QKBwjVYG2Z08VpbXaN6rwm8z2pSvPxOoQjk?= =?us-ascii?Q?2tWHG7tZkuWVHxzhb9MSKcs9t3mBn4IY2r8i7omi7mEOwLaNW5QCJwqWS1yh?= =?us-ascii?Q?QKmELookEsCV/PHQCvM/C6aa4thfhoZarNUk/5zq7EU7+XBUHDYsvNN6W2xH?= =?us-ascii?Q?j8EcbR2QWA/z8MwJr4v9vWmq5GcKRfAUnFx5VlHr9GMA/nLYctrAViCr6767?= =?us-ascii?Q?1LTyMeDY9PAgIsOocaRKc37Ny+sFUPmSbe/+/KeScB8YK+o0ja4OAubEaNLg?= =?us-ascii?Q?aLqDUw5IwxQA47GnejYaqTdUT5uSpRoc1An3twpA+96/k7P6z10w3k2EUegR?= =?us-ascii?Q?p9g8kyBJFcCft0d4ioSW2yCZQ1FVEgIDhNkUETko6yFMliJNkgHUEn7su8O6?= =?us-ascii?Q?X8cyHxp3Yk7Tg3zXtJosnxSwyosi2LgnPouzSC//ZgTpQvpqv4DFpliS5gg2?= =?us-ascii?Q?qzq0cGGW0jFXdyr1/DsWPU5/7IiKth/VN8KzGzMxZXmABdm23PzzEsk7AHLu?= =?us-ascii?Q?nx1nP/1j7lG7e6CIwKJeK34PgSOqLxtIZzwEsmi4WknIRbHtvjyWrDE6zjan?= =?us-ascii?Q?WXmuGxmWXsKvwdrNEb50CzN6mstPcVEnaMTMhA7dl3NQ2TpKjKcP35YiFcNU?= =?us-ascii?Q?cUbmP9LrhbLbY9bI6swZwhFc/xaNGC9doZ7/G8shUw8Bv1fMSBEkdIq115lv?= =?us-ascii?Q?caJJyMVq4dLG98/vRYwwKRThU3YE1slUPS/o6SPezXWW4ZkHIRRHV1rysP0h?= =?us-ascii?Q?46Tmhr7r3S03vwPbb4523uOMVRIgTIX5v8YjjOKM7WQ0dDnjWEt3jKqKNmoG?= =?us-ascii?Q?S2iQpVlqCWpeXjFd6IUa6ycH0K94rNB5xEIaevXzmeKacMhL4wSsFbq9/EIQ?= =?us-ascii?Q?LcOz87T7mT5kRAi97OlY+BrU?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd96295f-e1d2-4854-6c62-08d8fb5d69cc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 13:43:09.7081 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FwfQf/2U062e/FiL+HgmtUW6PBmegdFIzyHg1N92RnBz7h4Ei/A7/1PgJ+MbllRdhjyuYhkMO3TyjlnKhQ0KIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0801MB3688 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 13:43:16 -0000 Urghh. I reversed my example. I should have said removing an enum. Let m= e reword: One key example is this: 7950 says that removing an enum from an enumerati= on leaf is NBC (and that applies to state). But that may not really be how = most implementations would want to treat state. Would we really want to fla= g a module as non backwards compatible when a state leaf has an enum remove= d? Wouldn't that create a lot of unnecessary noise? > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Friday, April 9, 2021 9:39 AM > To: Sterne, Jason (Nokia - CA/Ottawa) > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > Weekly Call Minutes - 2021-04-06] >=20 > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia - CA/Ottaw= a) > wrote: >=20 > > One key example is this: 7950 says that adding another enum to an > enumeration leaf is NBC (and that applies to state). But that may not rea= lly > be how most implementations would want to treat state. Would we really > want to flag a module as non backwards compatible when a state leaf gets = an > additional enum? Wouldn't that create a lot of unnecessary noise? >=20 > I read this in RFC 7950: >=20 > o An "enumeration" type may have new enums added, provided the old > enums's values do not change. Note that inserting a new enum > before an existing enum or reordering existing enums will result > in new values for the existing enums, unless they have explicit > values assigned to them. >=20 > What do you want this to change to? >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Apr 9 06:53:43 2021 Return-Path: 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 396C13A2329 for ; Fri, 9 Apr 2021 06:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=jacobsuniversity.onmicrosoft.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 I8Mpjo5QIwwM for ; Fri, 9 Apr 2021 06:53:29 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10070.outbound.protection.outlook.com [40.107.1.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD763A2201 for ; Fri, 9 Apr 2021 06:53:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RR0LQzRgMfb6NiTEg7dPbINYBAlMuIUeox7871QGAea1MERaEpr2ad2u79z+AU+TOAeSgWVDJWTftdGsNDCk+Ochl3NQQ8rQ59Ce2JDW9FNLZcOWT2gU2Re5FuYf9TqlGBhnYptqcXU+wmCGdoUMLX+KrecwvbSPK3VJmJRdg+MDY0Gee+OlBWbSaHnnqjb+TDfA+qhqm9pNCdycPX7SqR6sJNtREyFbOhML3bTLEYP4ScZ9KNo8sKGvApeW3d5frLBhrtDckFouMCz0w3lpGFN4X5w/Jfulzmeh8/9/17cyNPBatc7NYu93z3EHMlFRtZMoR/v84xfACCdNVoYFOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Om2aUcL4FM9uCZ6v9zl6QRNV2xbGD+s5Dgw0sLfQYh0=; b=EneG89+ypXXYZwo+cbliNjC+3hqzl8nLbrRa8m6VHTebS4Xuj3+Laa3UdWTGr7x7S2nR8yBX5a/ICQq/npGcHZg6KyHM0951vtVLbeGEPB7EGOE3VstBCOwv569uunxL3a1xPOtnNbmCp/Ojoxq014WoxE9XuA1pHFwEM8hFXbRx9rzjNLJoH0epttqhEBo4GDCdS+DFYCnldOtiZERQkAGeGssZXR01TlxzwjV7DyK4wYDJwxROifbal0wi6uAAxUhXzJFtFoQoc/zgeOx2XHpZIj0XYYTaaOpPikWMzp9QE71rqVwbLPWqkqWJS/QiRS+7PDI92gGgcwh1wk7ryg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Om2aUcL4FM9uCZ6v9zl6QRNV2xbGD+s5Dgw0sLfQYh0=; b=ALRA7SUDgsozol1NR0rqRLnM8NPITQNjFV+/6E8hUmadUfTj2VNBcByo/GWFyjGQKJ0bygnUW97SMc4Gnlz+T9SbJKI7859p1UfkA1WVju2JNGE3RehILJXof+XNDvuMoknkJCBvayEDmaK9LLip/dO73fw9IBss4OMC6GAkuVk= Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0610.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:197::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.27; Fri, 9 Apr 2021 13:53:09 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.4020.018; Fri, 9 Apr 2021 13:53:09 +0000 Date: Fri, 9 Apr 2021 15:53:08 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "Rob Wilton (rwilton)" , "netmod@ietf.org" Message-ID: <20210409135308.4nrlvndnj3phjih4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "Rob Wilton (rwilton)" , "netmod@ietf.org" References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR3P193CA0038.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::13) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P193CA0038.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.20 via Frontend Transport; Fri, 9 Apr 2021 13:53:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 54f49e9c-f307-4bf5-7c6c-08d8fb5ecf2b X-MS-TrafficTypeDiagnostic: AM0P190MB0610: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OHRrovegFBB53X6Sd6YN8GmTkdS0emur7/a42UT5Deyg/VsWdGJ0WlqC/vkFTD3HaUE2UsZIoWMDZmhgjWL/BjABZb+uEtBxNHe5IIpgQhTiXNcwIl9dQjolISt9x3zRhrysKIvtG5vCEKHVw/neieAuUNSW2X7Nj7hx9bonjXAn/ctKKoZoiMsDcBCWLF4FDIAocKMr25sFVyWEWu/ZZe/M8zT0QtqOLsS5Z/47GoJ9c2Y9BDU33ZuiHwQlqQ3m8ag5S3SnN/l5CSPLA0/IOwYd5YKHM4QLUOvsfwUDCIhrNY6WV8mjHYWbn8F3Z/5VY4C0hugiR6jyMCtYh9KCvFEl8bnHnvi81li26ezD3bGZKaSygS9KMiG/yVPC+aSN18BZQ45xns/WInXGf1SQCSMvs3BBifGTKoSshewasBB1VuP33Te8iax+jQd8IIWGDh0SQaSq5ZjhpT05b3D6fKwlxj5F321KJrMerZaB1tx++YX+n8pLX8RXf8Jq9+RE/mehIKGTO6XlO3w5Ebkpd/oU92S73G/inN7ctUtK36IAiGz+M9k5dhe2WoK/b7l2RTx4bkTX1fLbCD2zXBT5gkxaqpfpEJZXVU9bsb7zL/Ip9sSHdceZJZfQ5IeqqAWYgsj3mE1b8oJO2lrDqxN+h8AZaHC5mypsneNWMiddrvTBbGdk8CSe3KeM/oK+8XdRmSlb3TfG9qRslIVVSi1LG9SSS/kgx1/33qNVTf6IoacpT/E+s1mEg3FVWJHSB6j66RzF2vjLzdph/Gwl8IQRdA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(136003)(376002)(396003)(39850400004)(38100700001)(38350700001)(5660300002)(8676002)(66476007)(6496006)(478600001)(4326008)(66556008)(54906003)(52116002)(956004)(66946007)(86362001)(186003)(6486002)(83380400001)(2906002)(53546011)(6916009)(8936002)(16526019)(316002)(296002)(3450700001)(786003)(26005)(1076003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?AUQNmtUAMzHKU3afjH8eB+3wK62qlk1XTuCFfJ6QZWRRV+ttO7hnleWcn5yc?= =?us-ascii?Q?e+8EjPreybeJAf+r+Mh9rlR/P4W4MrPlsdes4teq1n003YErF6RcfYLq1EYG?= =?us-ascii?Q?ZMqHdM4NPRdFIkhYS0GYBOwDCpzYJ8mcM+UQYjOmTRyjAMQScfY+RThwUMR1?= =?us-ascii?Q?RW/t8p1fG+IRcCBOCY+Op7A5lphtk2vgTikKDlfmbgmQFKOEjxLXTOe+/RHG?= =?us-ascii?Q?P++Ydw1L2i529/itlKUnvcIiRed6NX8mEU/3zbEBgxKisYqp+DBuQuXnfgeD?= =?us-ascii?Q?/GuShE+iQ1Bn9AmPtLByzuLRHKXTknPeIE3bdKYlwVeyTLUddRdUxQNrsflJ?= =?us-ascii?Q?4OH4Ewy8Jw9nxJjS4HL8YfMlQBZbjLKlcZ+51CTTiLXZRzH2Bh3NADI3vLOH?= =?us-ascii?Q?GhbaeIgW3pAj1ZNIndDVQf4uO13SKUObTurIL/NMZ/fSw36Awye9FxOEYlwf?= =?us-ascii?Q?kxEE9wdXOE0g246cTmIibXxxYpJ9WJCyyOJAjexYSjPl4fyDLq0yQmnM5kKE?= =?us-ascii?Q?BUPv7DngCpJyRhlppFwtTnt8N5SfbODHpwhICVqxn2RZplBgxK8NW+S83E8g?= =?us-ascii?Q?JskUUMV/uEliwu0olS+vD63pqupnEV2djyigdPYgBzmkZXZWXro+4M3lzdse?= =?us-ascii?Q?4C0crtNmC8q9H2xSCgEQ7YKl3hxZLmQBYggM+8rBXnnWyFeFG7zH84hxJr8S?= =?us-ascii?Q?o5F6TewFZ63VG+1iPG6Pm493ifjFyM0wU9dPtlsXGbaw15JFe8rGPxx2gD6k?= =?us-ascii?Q?FtJWXcRWIUielIKrO4yAXg3cYCYFBRtXHVtZ7dRd4Ya3aAoNYGxqee2RdDG/?= =?us-ascii?Q?VWkqIJ83kwawRMWD/a6E3SVCvjgERm0mKdhF63DBoa2e6s5bdw0gWYhxE3kc?= =?us-ascii?Q?fqaAWJ95PZKdgbQnYXR2av1BFX4CRaH3lbltKmcf1anmLlQ6V3pMt5khL1a6?= =?us-ascii?Q?9DovQJMLwjfuQ8DbcVOQZdwv4AH8Q+CgaQUVvLVFAla0Un8R3jh1H1tNbcJr?= =?us-ascii?Q?ohe0QyfxKQB0vtmV45JYC0MJBQtV7ORjc47Cn8943zJvPIC2WABIoFy9irW7?= =?us-ascii?Q?B/zds0aNgdqUmGwDot13ABS+5L70fKtmeBBMKmAB3XE3TOutK/bYYPXzZk1S?= =?us-ascii?Q?eVdkAUWm86HokEVYTGbF5JlAUxpCtSdbpNbMjvGV64m8IHKeoc11m3DzsBEn?= =?us-ascii?Q?IXVNlTVcn5DSH2w7U7HicQ3v3zrDEQnRJjJKErhXWbzEwyIhP5SeGYFdSB+z?= =?us-ascii?Q?7OrpzjjA/lg6plU9/j9KKQP8BtXyPHObf0nkTVRJZG/YmDA1ZLJo81HRFKtl?= =?us-ascii?Q?Y+OC/klmWQ+nqMjERYWvhkEh?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 54f49e9c-f307-4bf5-7c6c-08d8fb5ecf2b X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2021 13:53:09.5092 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9WuieRULD5jYeiKx3FWqt2lHjdbOM0d1BtpaqT4O++zE0lfoFal0g5Khp9wabrYYytlc+DpHzCsPXVViOZcukiR4325v2gMHtzZ24q7vpMk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0610 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 13:53:42 -0000 I do not recall that removing an enum was ever an issue in practice. If an enum value is not used anymore, you leave the old enum value and it will slowly but surely not be used anymore. (An enum statement even has a status statement, so you can deprecate or obsolete enum values.) That said, if the module owner decides to remove the value, then this is indeed non-backwards compatible. (And removing an enum paves the way to reallocate the associated number, and be it by accident later again. I suggest people think twice before removing enums.) /js On Fri, Apr 09, 2021 at 01:43:09PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Urghh. I reversed my example. I should have said removing an enum. Let me reword: > > One key example is this: 7950 says that removing an enum from an enumeration leaf is NBC (and that applies to state). But that may not really be how most implementations would want to treat state. Would we really want to flag a module as non backwards compatible when a state leaf has an enum removed? Wouldn't that create a lot of unnecessary noise? > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: Friday, April 9, 2021 9:39 AM > > To: Sterne, Jason (Nokia - CA/Ottawa) > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > Weekly Call Minutes - 2021-04-06] > > > > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia - CA/Ottawa) > > wrote: > > > > > One key example is this: 7950 says that adding another enum to an > > enumeration leaf is NBC (and that applies to state). But that may not really > > be how most implementations would want to treat state. Would we really > > want to flag a module as non backwards compatible when a state leaf gets an > > additional enum? Wouldn't that create a lot of unnecessary noise? > > > > I read this in RFC 7950: > > > > o An "enumeration" type may have new enums added, provided the old > > enums's values do not change. Note that inserting a new enum > > before an existing enum or reordering existing enums will result > > in new values for the existing enums, unless they have explicit > > values assigned to them. > > > > What do you want this to change to? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 9 07:00:50 2021 Return-Path: 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 D15693A2232 for ; Fri, 9 Apr 2021 07:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 92ihrAVfS0vR for ; Fri, 9 Apr 2021 07:00:44 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2092.outbound.protection.outlook.com [40.107.244.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AAA3A222C for ; Fri, 9 Apr 2021 07:00:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IpPmAoMjtdJVmASfE0fN5VE8QD5Bjw7CeLT4WAiSyVutlGMtA8qJ+AN/ZjGCn76qIEIx6egM8ep/QbhDdZUASpC8QQUcx/qKU1vgJynliKHfZG0hUplylD0b/9xriyVgX9JuNxN5fChAi+ExASiWhVPSCcKQDyRBfbBcPx7RA3LuO4E18lB9mqXxz6ltAn0FY9piFSw0BY25KyT6uV68ZUZA4+l/HIWAtJOnO9C1dKNLb5NCIWG9Fh/vgDUKzFOkq/rpWtUej/bBGI4mBzLE1PVWxU+0sMVM0gIE5UgCPDbRFGlsFC+5DtGbmPEWC52PPCzfo0ot+7jH1AWj9OXp8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v8PJB+UAmSTqMlADZMzr47gAguc7HE12/ZRSHO3Irz0=; b=BsHaMa/va17JeGGo2nZLZSLUpzbwzePBlMkMj6u2+P1ClZF/Ggqny7Tb0F9AU9K6tclaaGKE5InHLG7ND9FFOvUQYuM0gjc6nRzN9vSfCw1LkWIqF+LUZVUDnW83XZs8RaZXak/ODhsLjZ5i3AtH8HmXUy8pEB0LOxsp9zFQ1ZEG+7tSJCpqymEpnxVMTr5NOiZ3hUM/wcuWiYVxtSxvGxYrYlYwCPdIaR0TBCm1uHZ9A2IyBRCAe8bmO5vLQjfoqk6w238v9Q4XApVOsuUtb3zdfhPS1pR7YqwCUwjqnkfLYXZlGF6ZXFQqkG0HCh+xDp8dgTvnv9T1+FKAqFbznA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v8PJB+UAmSTqMlADZMzr47gAguc7HE12/ZRSHO3Irz0=; b=k0ySxBrkndaVklkTlK8J67GmdECjgIKEwo9twlPn0l0+/8+Gb6ig3p3HogqfgKivwh+TC3SXdjMMUGm4yFLoYF9M7r9T+otw6vYjOPa5Yenjta1y9FgTTX98zS/awKzDao4dpLvNDe+PlPH8hsr7jEhbv8MLDfV+2kFF7tCEQZ8= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5804.namprd08.prod.outlook.com (2603:10b6:5:153::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17; Fri, 9 Apr 2021 14:00:42 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3999.036; Fri, 9 Apr 2021 14:00:42 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder CC: "Rob Wilton (rwilton)" , "netmod@ietf.org" Thread-Topic: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] Thread-Index: Adcrjvs0u1Y2kX7cTWaMCLlk2EmADgBEca5wAAHbCoAAJt+v8AAAgYyAAAAa8OAAAGNHAAAAJCmA Date: Fri, 9 Apr 2021 14:00:42 +0000 Message-ID: References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> <20210409135308.4nrlvndnj3phjih4@anna.jacobs.jacobs-university.de> In-Reply-To: <20210409135308.4nrlvndnj3phjih4@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0362845b-8962-4288-e6ad-08d8fb5fdd21 x-ms-traffictypediagnostic: DM6PR08MB5804: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RtlOq13dcU5q0mPe/FbygJRv6+v0935pWHkbMdtxKrnd40snPDIw12XwYjkiIy5IOiJL+i+uajvEG047yXnTVMM9HMshO74DCgE18UXDwAdpKlp2z33AiX0LB40R8eZHF2b1NZCy1tNHylgS5LM4YKkr6JJG0Q7unlm5OBLsUB4j3Yl87uCg/u54RO6TRF7VeWN6Ls1I1KbwGWgFE9H3PF8BcbeIrBWDxesTbai19vFB9K+4pmuRP5Z5rHCQ+F7x9tQIvqkFAXP4wHB/WGbMbmAhJcgbIgd4vfAVHIRNPnZaxkD2H4xLmOyagfFhcHkJWM1IMV3mAEZXHn7swz2GVwNN2JnpKOtouoSokPvkOqiHixKS7GuwbFo7eDn6zegZ/ikgP9UsLPzyUX8i7lzoWY36YOFjlY6XDJB5nSYt+NZrPSDbl6vTf9RpWl8MwHuuH0057uMWDYiWfpDljCRe55EVnyCUK4MhtivrVNxpxkfmiv+ym543ZdWcBFr7uJHd08JQ7mbytfrhufkSvSlzuaCuJLab1jlcuK+HJH6Nz4KGci/V1C4F+K8rL1/NazLBe90rD60BS4ECLX8ezfuoXQEvdm38ikdv5G3EtODYl2TEFO2Km0vgZ64q3O4ZRm1OKRf9/nx6gtbv8Vrn6VXVwbCAqYRXdHrTw00uofi620tmycLTNs+9k4wGjQtv3bbv6xoCG4Kb8zLXrBLPYwS11qgRajCyiQ2XW7Ql0YGOCYFBpM3ON3EW228QaSyn7d73 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39850400004)(346002)(376002)(136003)(186003)(316002)(83380400001)(71200400001)(33656002)(26005)(66556008)(5660300002)(52536014)(54906003)(2906002)(7696005)(38100700001)(4326008)(6916009)(478600001)(64756008)(66476007)(76116006)(66446008)(8936002)(8676002)(6506007)(55016002)(86362001)(66946007)(9686003)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?hcPgppZermrzS1zKD7CB/GOVrur/p1DoH5WNFrWFHYvu52OpdihOdXNDhJQj?= =?us-ascii?Q?KFdFPHyLTBbHZQuvawMvWDHFr7PJH0Qc+hPvii52hIUXrdA1bVuguv0aijlH?= =?us-ascii?Q?B/MpebXUNpxr0MkhUX+bbMGSwHOLGvvkZy4bpYLw5GoK2jZdbIbbWPSXummM?= =?us-ascii?Q?FYnvp77Hk/PYxHUkKgp7OFvdB6Dfc2QbDa1oZIJPWZKjCW6cWfWuzU/1WWsZ?= =?us-ascii?Q?npQ9arZWWI7DG30Flxi6h0Cx+iCjydyRMGP8gUH1Oh3zEIa65WHKcw0bbYi7?= =?us-ascii?Q?QPSaqWL4x2LUmIsCQxH9fPg3pChnjXs/KIpVZwmyAab10k1dIh2sdPNWwGdx?= =?us-ascii?Q?BKv6w4dHRFyH4DCbGZWlto6xwJio2av+IpxQr002U4oSXQ15Y8K6GVEj4zCo?= =?us-ascii?Q?7bxFSwOXyKyXHOqzCn8Tos5ztlgtmShGP0CeoROU13DchZdICIqwd7zWvtQf?= =?us-ascii?Q?kxyooqbzJBsg79mQkkopdqmB39p14wvOmIC0T0PNlHlwVHLz7w+z2I8kbqUo?= =?us-ascii?Q?QxrUE7TAF615xRM0xV8TZPqqKEuMJNYRpHlEChUib4dY7HsPa1Qr2PwLaNj4?= =?us-ascii?Q?57nnOGDKhMyAZRtO0T7eYskHeYbI5K1KJo571uYu/vzirwxztvhWXgT+PlTK?= =?us-ascii?Q?fhngwAZ5UL/ifAb6sk3gi8UGwMmN924XN/qotO31bb1CqhoG1FB5fB1tRZ7L?= =?us-ascii?Q?upogDaCWqPN98tMVgnqv6nB09Jp29YTw9pxzGEsP8wDToNv2yxFbtRiCx/yW?= =?us-ascii?Q?JQNTjWSu/Reuu9u5F+X1EEVce4XImT+a8aAn1bDG4obFIUcAVJuCphee9zEi?= =?us-ascii?Q?jkBdK3rWRl20kBVX7Ijck4DWIIOzSbynOdDwGY2saiKTvhR3e0BZ6Q/uvQx/?= =?us-ascii?Q?SbvB9jb2TC/09Wz5VA76vYfYJACJmK3VKlsOdKxavsQ6oSkhe3kLdJVMqF5b?= =?us-ascii?Q?IBVH8gvBC9mi0usOHvDXJQlh/u+8e/C32qrw8nyCgNlUcKPaoVZu5D1oeLmy?= =?us-ascii?Q?kV2VzolMClZVmNz+wgBOuJEJbqn4FwZjfRyWZVRSXHDUSMYU6PTdX9n7+Uzp?= =?us-ascii?Q?2KvTmaI8z8XiOYpBd2/wgK1nKn8bLKv7aRsZgQ8Ffh14LH3as0j1H+ehq1a1?= =?us-ascii?Q?XndtM3ZFUpNTK2UhFfKNIaPSR3IdHUro/lQ5AKWLhjuhHjQeIPbX6sTzscb9?= =?us-ascii?Q?fUs6iSbVgD1cDfu3s+Rlfzk7mnt4rH5Ovdfuvaa/TuhNPpR3/2Nr4VUYcvhy?= =?us-ascii?Q?wFOCg+to1tXqxA+vRVQkR/0M3VfNJMkLKV80BnvzTBZN7m0X7V7qJ87999Af?= =?us-ascii?Q?kDmwvpYbPgTZ/n8m8VXIkPEC?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0362845b-8962-4288-e6ad-08d8fb5fdd21 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 14:00:42.2227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1eADaxcvaH3DIYZGbazOwtyYr+MG0xec23QrLy5P1lYC2m2DV/RvNeUI0dsoYLYVTxoAaDrBPD9YwXIC4nLggw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5804 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 14:00:49 -0000 The key focus here is *if* the author does remove the enum, then how should= we label the revision -> BC or NBC ? RFC7950 does indeed say that is NBC. But do we actually want that for stat= e for: - removing an enum - shrinking a range - changing a pattern in a manner that reduces the value space We're worried that will create too much "NBC noise" when it really in pract= ice won't be an issue at all for clients. Client just won't receive the ol= d values from the larger value space anymore. So why flag this as NBC and = make people do work to analyze it ? Jason > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Friday, April 9, 2021 9:53 AM > To: Sterne, Jason (Nokia - CA/Ottawa) > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > Weekly Call Minutes - 2021-04-06] >=20 > I do not recall that removing an enum was ever an issue in > practice. If an enum value is not used anymore, you leave the old enum > value and it will slowly but surely not be used anymore. (An enum > statement even has a status statement, so you can deprecate or > obsolete enum values.) That said, if the module owner decides to > remove the value, then this is indeed non-backwards compatible. (And > removing an enum paves the way to reallocate the associated number, > and be it by accident later again. I suggest people think twice > before removing enums.) >=20 > /js >=20 > On Fri, Apr 09, 2021 at 01:43:09PM +0000, Sterne, Jason (Nokia - CA/Ottaw= a) > wrote: > > Urghh. I reversed my example. I should have said removing an enum. L= et > me reword: > > > > One key example is this: 7950 says that removing an enum from an > enumeration leaf is NBC (and that applies to state). But that may not rea= lly > be how most implementations would want to treat state. Would we really > want to flag a module as non backwards compatible when a state leaf has a= n > enum removed? Wouldn't that create a lot of unnecessary noise? > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: Friday, April 9, 2021 9:39 AM > > > To: Sterne, Jason (Nokia - CA/Ottawa) > > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > > Weekly Call Minutes - 2021-04-06] > > > > > > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia - > CA/Ottawa) > > > wrote: > > > > > > > One key example is this: 7950 says that adding another enum to an > > > enumeration leaf is NBC (and that applies to state). But that may not > really > > > be how most implementations would want to treat state. Would we > really > > > want to flag a module as non backwards compatible when a state leaf > gets an > > > additional enum? Wouldn't that create a lot of unnecessary noise? > > > > > > I read this in RFC 7950: > > > > > > o An "enumeration" type may have new enums added, provided the > old > > > enums's values do not change. Note that inserting a new enum > > > before an existing enum or reordering existing enums will resul= t > > > in new values for the existing enums, unless they have explicit > > > values assigned to them. > > > > > > What do you want this to change to? > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Apr 9 07:19:47 2021 Return-Path: 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 CF6C43A22C7 for ; Fri, 9 Apr 2021 07:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=jacobsuniversity.onmicrosoft.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 snhsTQTHit8D for ; Fri, 9 Apr 2021 07:19:41 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60051.outbound.protection.outlook.com [40.107.6.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E478B3A22C4 for ; Fri, 9 Apr 2021 07:19:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dMYAvdLumQ12TcRuRXOZny13xzKNqWPwk2uXsOuvBLKCuoVD7X3YeMUoIuUCRdXxnPWbINNuJWhKCWIzFAOfBHrrrR2xq7co12M9eq6q/y+KsaQAm68j7r/bqwFETN+CBs+HisYPNkC/Nn1Z0y/bEcusTZT0svHLjv+Ydar4uLqB3Y7MxsP4kSdAfxbXhywZfVAmBb4VMPC4kEwPIXi6eoIjwLmfOAranXWRkiBQryuPaC4pFHm86znCz8W5rqXP9ogBipx4ipZr8FgCrC11L3wpRHCg1PkgeGvauYblBj8AxZZT9HT7Zis7RKyFjt2Z73PGOJoe/PQwxMmmXe4pcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gd0NjHpeXBi7xmoG54j903qxW5D0HaOs8Pxzm0wT1mk=; b=jpUuXBJAnvXHvd6U52FxMdnXm621q9RXMocelAXOon3P9VM0efsm/MLAqPj+d+sxz0DD34Czss8TKRHIpkWtRVU0QGddxItkiBzxQDMENNQl6f7GVwSIEMhqSgj7MDKAe86TYFrTZmxF8MjrSg0PaH/RrtM0eVnTMuwruY8lUy1HOAyATpSyH3lm5e0GsfCuci4RrziSmdR2x07s7KvJLRrB+QdQ2DMt5WeBire6eakc3rjzTTh0Sct8ULPTyqPh1kXlg/Q47SoUo8oWgzI9xG0nFB0mjAQlhzeya4K5Zv5re7g6kBUa7VAba0be93szMvjhrDB4HxRBCtUWQHzUQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gd0NjHpeXBi7xmoG54j903qxW5D0HaOs8Pxzm0wT1mk=; b=H9mdMRtq/8DXOLnWYPp6NubgRYsRv+1EB7aIMHZU7K9SDKmuu2CnEA039bm5OGQnpWCBtT7NR4V12AU2IiYGQNUyPL8CGpQ9T8l5xfv8tNl8zF6oWs8gegEMjBPjCLNMfzz/sRbEAJNt83Dik3YSAkwx9wuLAYnborkIm0tlr+w= Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1505.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.16; Fri, 9 Apr 2021 14:19:36 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.4020.018; Fri, 9 Apr 2021 14:19:36 +0000 Date: Fri, 9 Apr 2021 16:19:35 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "Rob Wilton (rwilton)" , "netmod@ietf.org" Message-ID: <20210409141935.xsjj5c272rq453u5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "Rob Wilton (rwilton)" , "netmod@ietf.org" References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> <20210409135308.4nrlvndnj3phjih4@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR0P264CA0220.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1e::16) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0220.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.17 via Frontend Transport; Fri, 9 Apr 2021 14:19:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4996cc35-500c-4e55-0c78-08d8fb628146 X-MS-TrafficTypeDiagnostic: AM9P190MB1505: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: enGw3zpeIfIjT3pXJ4o3UKUF1d54xkoZH3JDeFYYSyDIUtZzsMazEaMOWe04Ocn0BxMwySDK3sOk2CqOnE9so+nWAN/PJF/CfCF2COvtScUGwn4aUMA7b8WBcbMql42iqPe/SojROIpACi2IT+grjEk/f+1KqxwdqqaIhp0Jp7Anmd9djr1/rz7hPmxYajW3Hny5MPQFSZOc+uSgwynbeTuSMahzhnh9jf5p6OQ1CicNv83M2VOxQxNur7c16rhZUTdldo3ToVtlqFtchWY50Ycqe2USJSy7dxlb/6MbmO8vtT0S8Ycmxrzyv9W1Gj1VHSiItUKi4z2777ggdH2cmN55ujpx2IRM0rO2M+Q2wnmtnGkj2mvkn2wmmO0Yk+aZp18FX0Vezwqsb+aENIsUZD+yaKF98609KSH5r+cUOpc9pWNqrlkaqtQk99G9o9COHmuWHkavVGlq38GOD1tzG5gztDJm0QvkbK9oSZgVrBlTySHJVwJgayh48SOKEGsEWlVLugBnu3Ds504qk2CgvbeAwcThNPqfP2Dgih9VHHYzG0LT97zsBJlw4IRVgxqWvgR5eYy1PvqheKMIyHIf/Vr/VzouNNeQD/pITFnY1MBTx1wwR2iYtysfCM81yTCyVkfcfFf5byKH2aTzNar5mvkcQS7TyI+ZojAjcYULXjUoCVf5/P0Nk2shN54kK8EuKiBlIjhMq8WBJKvGmSpTz9pBf0QWX35d7VnNAO46zEPF1fIrHPWzhg6rJ5dCzq+UA7ymOqtBvX/xo/3DRvUUDg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(346002)(366004)(136003)(39850400004)(376002)(296002)(786003)(316002)(1076003)(3450700001)(83380400001)(2906002)(6496006)(478600001)(52116002)(8936002)(6916009)(54906003)(16526019)(8676002)(26005)(186003)(6486002)(956004)(66946007)(66556008)(66476007)(53546011)(5660300002)(38100700001)(4326008)(38350700001)(86362001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?jUxuUVW159K9mwfeIoeOIWxjep/9htmuVmkUlRKMGVPlbkR16XTi8x+UAzD0?= =?us-ascii?Q?k9+k6iGSY2rL5WXwb99cmXHpvCoUaQssEjzjxD1hGGJ+qX/psRwVYOJs24xO?= =?us-ascii?Q?MIowgOG9EM9FwxzGTABt3dWu/E0rR1mTGvk7x2SJ5KVYXBSVMzh2lruWf0Bt?= =?us-ascii?Q?lwLHzeCdZQTyPUVktwbcidbdsVhq4mICWY78ixK+RNisyXUVo9cEC/GgxHw/?= =?us-ascii?Q?dDJmDcGopqGZWaLVa+MzhiTE+Od/+lSifgggAPdenYhH+45l9brhC7JLs4ns?= =?us-ascii?Q?lOb4HgqOSRy7adf8AdomARh9+ZlT1umANXgiNGVtcGVeDj2y60FLiiHzri41?= =?us-ascii?Q?KwvDOXBGTfrcwbPTb4fKrXo3jEtNWsK98VEnZy0LHc+/i6B8OuoUZOnmRGGi?= =?us-ascii?Q?mEu1fE0aWDGAydqMu8D3LYd92ToC3RJOxFkoLymBxhbY+UxflxQPod2wSKCE?= =?us-ascii?Q?UlUns06xrLbKb9/9KNmLmvgABL7HaxCtKrLDI+193koEd7NWJkmxcJMNcW0v?= =?us-ascii?Q?YhP0DLi3mwUU7MUuai7m46tn6vQdIx7NkLCILhuWKEKWDW8LEqEE8ZoI4eE5?= =?us-ascii?Q?Hc8/1ce37e6laiBcVUrvrgXMDfGPXOTtd0aSbUPRmcQI1rJ5wFB+YV7kH308?= =?us-ascii?Q?hNk8juxna1qamRJfvR4ZL8y4O5NWNBkBTW4YcVh/pZLiBjpYzpzX6oLofFDA?= =?us-ascii?Q?h7QWxSPXU0vJK2fsY9Mxsc5jNgDDUoI/3q058Qbn+HPcFkQ+MZ4cDJ7vyyOX?= =?us-ascii?Q?vAuIbIQ3Ocm2sNoK9eFLuzFT/WINIftqdivt0SiHUPasA0TlarCI7IyZvdi2?= =?us-ascii?Q?uMSeJkfgB/uvjyLgvVLjtxf4Ft5d9gErZhIv1h7qWcgLNFz0SRPnUgABuCv9?= =?us-ascii?Q?po1xoYiWA5FHKVzi0GKq8naQbbSwXyF942AjCFkq3U/jAGRxGct/A2uVDdpC?= =?us-ascii?Q?KT5OHI4w3b+DhJnXyfH3mPbvGb+sT1zxZW/Sa3MV9VJZiYR80vGA8o2nAXl9?= =?us-ascii?Q?xST1GXFmhBRrK/kIvMxNcMOndg/2cLrdZ3jrgg3dbM05AlFnNMIo80PqyGiC?= =?us-ascii?Q?rUZ30mYf89/XQXZhSqLoz8Vk6W4ROez6QX//rlR7vxdYp0kxb/WNmcGA8Mda?= =?us-ascii?Q?DETOBpxP7OgVN5aUIXa03dI8bVhelH2j/uIQqjQEu5u3SI5NvhooJ0TomV7u?= =?us-ascii?Q?WYdTGrWmoEGidoU1Fvvxes6guN8jPpGMP80tqskXvIT0/jPs3rTtYUObF4n4?= =?us-ascii?Q?kAomAqy1xFaZQm8T40QQrw5881L054R5ZjiTJS9NMukvOQvJAANvWyySyfJ/?= =?us-ascii?Q?kxX8TLeJE8Ny8Pw+3ftyIk/M?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 4996cc35-500c-4e55-0c78-08d8fb628146 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2021 14:19:36.8119 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: yg9vuBak+xT4oI5oHfYlKwJOOszh3NcHblwYquQ6UJeG9CFFyQVK5MYEKxKiTLJU5t/192Nm7bbHVxvBjGHgOQS1vERCtKGa8ftbBTzqm9E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1505 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 14:19:46 -0000 Creating lots of special rules makes me feel uncomfortable. Is there evidence that people reduce state value spaces a lot and in isolation, i.e., they just rev a module to reduce some state value spaces? /js On Fri, Apr 09, 2021 at 02:00:42PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > The key focus here is *if* the author does remove the enum, then how should we label the revision -> BC or NBC ? > > RFC7950 does indeed say that is NBC. But do we actually want that for state for: > - removing an enum > - shrinking a range > - changing a pattern in a manner that reduces the value space > > We're worried that will create too much "NBC noise" when it really in practice won't be an issue at all for clients. Client just won't receive the old values from the larger value space anymore. So why flag this as NBC and make people do work to analyze it ? > > Jason > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: Friday, April 9, 2021 9:53 AM > > To: Sterne, Jason (Nokia - CA/Ottawa) > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > Weekly Call Minutes - 2021-04-06] > > > > I do not recall that removing an enum was ever an issue in > > practice. If an enum value is not used anymore, you leave the old enum > > value and it will slowly but surely not be used anymore. (An enum > > statement even has a status statement, so you can deprecate or > > obsolete enum values.) That said, if the module owner decides to > > remove the value, then this is indeed non-backwards compatible. (And > > removing an enum paves the way to reallocate the associated number, > > and be it by accident later again. I suggest people think twice > > before removing enums.) > > > > /js > > > > On Fri, Apr 09, 2021 at 01:43:09PM +0000, Sterne, Jason (Nokia - CA/Ottawa) > > wrote: > > > Urghh. I reversed my example. I should have said removing an enum. Let > > me reword: > > > > > > One key example is this: 7950 says that removing an enum from an > > enumeration leaf is NBC (and that applies to state). But that may not really > > be how most implementations would want to treat state. Would we really > > want to flag a module as non backwards compatible when a state leaf has an > > enum removed? Wouldn't that create a lot of unnecessary noise? > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > > > > Sent: Friday, April 9, 2021 9:39 AM > > > > To: Sterne, Jason (Nokia - CA/Ottawa) > > > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > > > Weekly Call Minutes - 2021-04-06] > > > > > > > > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia - > > CA/Ottawa) > > > > wrote: > > > > > > > > > One key example is this: 7950 says that adding another enum to an > > > > enumeration leaf is NBC (and that applies to state). But that may not > > really > > > > be how most implementations would want to treat state. Would we > > really > > > > want to flag a module as non backwards compatible when a state leaf > > gets an > > > > additional enum? Wouldn't that create a lot of unnecessary noise? > > > > > > > > I read this in RFC 7950: > > > > > > > > o An "enumeration" type may have new enums added, provided the > > old > > > > enums's values do not change. Note that inserting a new enum > > > > before an existing enum or reordering existing enums will result > > > > in new values for the existing enums, unless they have explicit > > > > values assigned to them. > > > > > > > > What do you want this to change to? > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > Fax: +49 421 200 3103 > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 9 07:32:41 2021 Return-Path: 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 B83233A231E for ; Fri, 9 Apr 2021 07:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-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=nokia.onmicrosoft.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 hgXis_lfF6dl for ; Fri, 9 Apr 2021 07:32:33 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20700.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eaa::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5E93A231D for ; Fri, 9 Apr 2021 07:32:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kR9VcQiL0KysKShN6spJSQ6e7TEkz5OWcdMdowp/wKx3ec9/G7aHcj5QzJHMvdRJ/SewARr9gl07VNVzqz/EfyXd6VFP/xHZsNfxHbMcSjffbpIRR2vkSvl031/PaMagXdmIP3kLjMhGJFkoh2x4yAFNsbiDW8dUWj5WPWa9oOOtduiUI2okZoIQDFIarw3ao0r30ulDTaaRUBDJc13hrTiBOZ1W3Ej2qxlcp4SQMjxvWOhMGSHd2tFPqH4b67SrAmn2EINKdLc+JuLThd37CtWsDBhN6U7k7vUu3QlVLmGiWNLdTxrMb3D4QAQh4odBV5vBZNtE7evgGdTpVPyeDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lxh9/8r8Q2ZCI0Hao8gKO83XOmitdHq9byRlHu+MdMM=; b=A09EI1mbplzwLA17qauEC6u9bqg8a2cCtQNKmjqxHCCMcxeX6l099FraBKx3Apl7AnT/Mv4VfCFiBW4NktbLiibCkFZTguCSQu6FXrdZADKkLiyU1LvVup1XvUg5mn68wtBkzh/lYvj38fygtYNbq5LJYrJw34gMKBrLhwHl0Z8iMyMKqeJYxrk2fQsuamHdKbQVMy6eupa0tu4OCsUzDJxojU6cJTlke9yo6Yaig69c8nU6DPC4ixUH4CQJtbQGCpJtA9YmWw9OnhMYNyqPUEB1H4Z+pRdkFlH4MQIGK+sUv8CDAkh3nUy1rBMnhlWokB64jbXS4n1WSk7pOAouvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lxh9/8r8Q2ZCI0Hao8gKO83XOmitdHq9byRlHu+MdMM=; b=h3CsSO8TpGuiixeYCb3M6n6J6bJi3McG3sH5cztTOIPDERCcXEtWyKXTVDtHfF0wSKB7PDfAI4FZwaiz7iEmvUynUX9/Yi59odoj/Oksb5q6MFjYhGDF/HHz+oqWnXA3OfTrS7x/diKI+ZCdHNxBqt4LkAJ+9f4/VycrJBrI6Ms= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5403.namprd08.prod.outlook.com (2603:10b6:5:19::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.16; Fri, 9 Apr 2021 14:32:25 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3999.036; Fri, 9 Apr 2021 14:32:25 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Juergen Schoenwaelder CC: "Rob Wilton (rwilton)" , "netmod@ietf.org" Thread-Topic: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] Thread-Index: Adcrjvs0u1Y2kX7cTWaMCLlk2EmADgBEca5wAAHbCoAAJt+v8AAAgYyAAAAa8OAAAGNHAAAAJCmAAADIUoAAAD73IA== Date: Fri, 9 Apr 2021 14:32:25 +0000 Message-ID: References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> <20210409135308.4nrlvndnj3phjih4@anna.jacobs.jacobs-university.de> <20210409141935.xsjj5c272rq453u5@anna.jacobs.jacobs-university.de> In-Reply-To: <20210409141935.xsjj5c272rq453u5@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0fd667ba-1405-4221-8afb-08d8fb644bbc x-ms-traffictypediagnostic: DM6PR08MB5403: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F6Q9cEcH7qccQjEtZ/vHllK3U2rJ3L1THzv8mgFQl5bxi6QZlbAgoPRmOym/MTJORyXQLFV5WRJEjTa8FkFqA+u9Gp+Dm1QGAYeRq5iDcnTx2ZFNB6WsPCnatyu6yg2UREjojFBHJlr+DiNp8K204EixB9xgS+qnp14ahv/YmhbC/bnKp7p3aUHGeB0DgSRFMDJrSuh+rXJ2ROPHl9nScSXkAi+q9rr6RnWwIkMpxMLkbmj8vL291bCqe3cel4+vOrfTYcAeEJjPoZTPF6zXH3BKTxGT3KnfbzgMJKMgFtccLiIkuhcyXzIMR+dcN1yq7GFuU6Sl+zXEeJaw2aEQNNB7/6D4kn1sPDxZc8I6JdBLExhW+3GffsEUIgSkn02ZjBhM9tszD+AFZkX2ofE24FFLBaExwMyZl6Mm4aeDsFL2Tu0EuFXY+shcE0EKaPTDnFvCaK9gQd+/NjSlqABt8m7rFvpHjoOMDcETRGFr2q5cv+cbeYsBTZ1N3CMI1jX6y/XKDuauxJRIUrkl6lnxNNFsHOP5j68X0Yt6UPAkAghs+E3kN2TLMyTUwnaSLbGRD2d00yDL+gHtb++R/LF/cdgpP3SP/tvTY7r0n6/RodMdm9wGfIvoacyysyJbrq6gQd8H+cSu7abFgKsLjbi2ZndvtwWPVDuIkvpaxlDx14qXJe7DiSRf1GzVH6WTofk0FN1KW3d51/GUD+oYqJRRsWIrPuidDAWN60CYy/yfLQsVRvrdTZTmQ/QM4nVJIACW x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(39860400002)(376002)(396003)(136003)(66476007)(6506007)(478600001)(66946007)(76116006)(26005)(66446008)(53546011)(8936002)(64756008)(66556008)(2906002)(5660300002)(52536014)(33656002)(86362001)(38100700001)(71200400001)(54906003)(316002)(8676002)(83380400001)(55016002)(6916009)(66574015)(186003)(4326008)(7696005)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?t0k4rtas/PO7RhgFnppxL3sOTj5Y2LaLzMmn76iioo6gIZgwVGtgL7mOfOdQ?= =?us-ascii?Q?KjfTS8UzRyStkaw0b4bUe+LoRG8VvgoNc8IJSlh+y+VHh30sZGvudRUP3VH1?= =?us-ascii?Q?LXd/zbSTbdeesWNaejcfgNlEY6vEdV+AjdE1J3Lwkl/IpMgmU4AbiD8eFooC?= =?us-ascii?Q?eCV6V496NmVyXUKvGNZSfx1eA+DJtVKM+RtfUeUKqxaCqUc/bG5pDugZSh11?= =?us-ascii?Q?Ayk/+R0P8+WG6jnwmQTnLpy9xdaRNOx2x0rpMb+T/x43ydSnTnHYF7jLAiyk?= =?us-ascii?Q?XYppE2lfbN00YEQrAGLRZ5xR4WwXjp+46MW0txHWWFBOBxSk5uYHIefDT8MO?= =?us-ascii?Q?zdtWYthnixcr0z4GJksRSNLJhYeSFpOo1LAe6Lmx4F8FP2bLiuPe2o3tdLKK?= =?us-ascii?Q?AdrGs0VwRdxgAXMSPWDlivA5A5kwu/l7dvaU9xhnVZm7E6WTAUHayh8Rm+yS?= =?us-ascii?Q?HGJrgpQXMoThKK57iB6FemXbn/bj/d8HtuRdNDosTd1nNgBBfUl32crFX59v?= =?us-ascii?Q?UCKRrySRZr42U6llYYoL46bPuV1KfT76lhtnK3pMFV8Mt74Q2T4asHNbl6uQ?= =?us-ascii?Q?YYfQWopposFWEea+daycUdX9J4QnPjQcgGFb3VFFJJTSpx5mg13nnzfA7ykk?= =?us-ascii?Q?frijQy3Md86TpRX/LMaXtZn6YLZijLSdlEBv2m/mQiEd/kILlCVqU0Vx7Knh?= =?us-ascii?Q?cmneBZgLSaLttxrwQYqZu8tYKfAKbCqSIuM7rSQmCyKnoD03ApU4Z8xV6FuW?= =?us-ascii?Q?caOUmQ368odAD1ztbpIvST0G+D/M2wAC/ao3e8PxA7IJo1l6zHrV1CjlfBNC?= =?us-ascii?Q?lZ7ClquZDwchM6F7KI1aCDmL2UC48Tk/MiSucc1JI1ipr1VXRkQAp8iEobOV?= =?us-ascii?Q?bMOFCcuK1tV6c6IQMwVjKlfDev7wUx9XcXIXtTkrO9yLWFHCpfGghVTaG2wj?= =?us-ascii?Q?CdJeWlxblcELp1N0uSYy+AwXI4+Y5unhwPD9APzFlzMgBRQQ5D1x4aC1FV9s?= =?us-ascii?Q?rcS1ZwJtEDRjSbWpWyeeFsLLa+z20VDUt9jlBUvYQPaPUtQ0pesf4aGIKbzM?= =?us-ascii?Q?RD6s+d7p97t2ImP98iU8849DOLUdXhpXULLgK10YaVnYC6pf6k+1quvME4MB?= =?us-ascii?Q?kpnQOUZRICmcqAN6a4HD0yRZDZ0YoD4NRkChFSe0EYwHNpFGcQhuucKxzgAW?= =?us-ascii?Q?T8VxaKxxBWvHH3yl9mnvF5QzZ0k3Ov+rwLYUiBPyioeOPqtDVxzUIvzO/KEf?= =?us-ascii?Q?PgfasJWnFNS75z15OqhwGF/CYHf7063hnRIvHvh/IxePWbmoGaS8mF/9Cl0O?= =?us-ascii?Q?D40sRkYKZopthn5ycJwRYcVf?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0fd667ba-1405-4221-8afb-08d8fb644bbc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2021 14:32:25.7165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NvNZZSKm4ki737UfICkfoz+s00W/OaTk8jc0ZXSjWTcvOcAjCKICQLUxNRbcTAB1lm2n5fP/1Ax5UMQj7RXA2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5403 Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 14:32:40 -0000 Hi Juergen, Yes - it isn't obvious and we've been struggling with what to do about stat= e. It just feels like maybe the 7950 rules were more focussed on config and= it might be worthwhile adapting some of them a bit for state for this YANG= Revision work we're doing. The big one is this value space issue. It feels like expanding/reducing val= ue space has different impacts on clients for config vs state. I think a fairly common use case for this is bug fixes in vendor modules. A= nd note that at least two major router vendors have separate modules for st= ate (Nokia and Cisco). Jason > -----Original Message----- > From: Juergen Schoenwaelder > Sent: Friday, April 9, 2021 10:20 AM > To: Sterne, Jason (Nokia - CA/Ottawa) > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > Weekly Call Minutes - 2021-04-06] >=20 > Creating lots of special rules makes me feel uncomfortable. Is there > evidence that people reduce state value spaces a lot and in isolation, > i.e., they just rev a module to reduce some state value spaces? >=20 > /js >=20 > On Fri, Apr 09, 2021 at 02:00:42PM +0000, Sterne, Jason (Nokia - CA/Ottaw= a) > wrote: > > The key focus here is *if* the author does remove the enum, then how > should we label the revision -> BC or NBC ? > > > > RFC7950 does indeed say that is NBC. But do we actually want that for > state for: > > - removing an enum > > - shrinking a range > > - changing a pattern in a manner that reduces the value space > > > > We're worried that will create too much "NBC noise" when it really in > practice won't be an issue at all for clients. Client just won't receive= the old > values from the larger value space anymore. So why flag this as NBC and > make people do work to analyze it ? > > > > Jason > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: Friday, April 9, 2021 9:53 AM > > > To: Sterne, Jason (Nokia - CA/Ottawa) > > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > > Weekly Call Minutes - 2021-04-06] > > > > > > I do not recall that removing an enum was ever an issue in > > > practice. If an enum value is not used anymore, you leave the old enu= m > > > value and it will slowly but surely not be used anymore. (An enum > > > statement even has a status statement, so you can deprecate or > > > obsolete enum values.) That said, if the module owner decides to > > > remove the value, then this is indeed non-backwards compatible. (And > > > removing an enum paves the way to reallocate the associated number, > > > and be it by accident later again. I suggest people think twice > > > before removing enums.) > > > > > > /js > > > > > > On Fri, Apr 09, 2021 at 01:43:09PM +0000, Sterne, Jason (Nokia - > CA/Ottawa) > > > wrote: > > > > Urghh. I reversed my example. I should have said removing an enum= . > Let > > > me reword: > > > > > > > > One key example is this: 7950 says that removing an enum from an > > > enumeration leaf is NBC (and that applies to state). But that may not > really > > > be how most implementations would want to treat state. Would we > really > > > want to flag a module as non backwards compatible when a state leaf h= as > an > > > enum removed? Wouldn't that create a lot of unnecessary noise? > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder university.de> > > > > > Sent: Friday, April 9, 2021 9:39 AM > > > > > To: Sterne, Jason (Nokia - CA/Ottawa) > > > > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > > > > Subject: Re: [netmod] Client validation text [was RE: YANG Versio= ning > > > > > Weekly Call Minutes - 2021-04-06] > > > > > > > > > > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia - > > > CA/Ottawa) > > > > > wrote: > > > > > > > > > > > One key example is this: 7950 says that adding another enum to= an > > > > > enumeration leaf is NBC (and that applies to state). But that may= not > > > really > > > > > be how most implementations would want to treat state. Would we > > > really > > > > > want to flag a module as non backwards compatible when a state le= af > > > gets an > > > > > additional enum? Wouldn't that create a lot of unnecessary noise= ? > > > > > > > > > > I read this in RFC 7950: > > > > > > > > > > o An "enumeration" type may have new enums added, provided > the > > > old > > > > > enums's values do not change. Note that inserting a new en= um > > > > > before an existing enum or reordering existing enums will r= esult > > > > > in new values for the existing enums, unless they have expl= icit > > > > > values assigned to them. > > > > > > > > > > What do you want this to change to? > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > Fax: +49 421 200 3103 > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Apr 9 10:00:37 2021 Return-Path: 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 874133A27AA for ; Fri, 9 Apr 2021 10:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 NbZzXB0jUMhX for ; Fri, 9 Apr 2021 10:00:30 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 285FE3A27AF for ; Fri, 9 Apr 2021 10:00:29 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id v140so10794131lfa.4 for ; Fri, 09 Apr 2021 10:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yUwBvONhM2SrHwMasxgS3JD4rno35nDNjTb3i8JGwQk=; b=VoqZbvPg4rGfUxg4a7utRZYwGPs6QW/akJAlSFWq5q45RVzEeyVoL7nK3LtUtiwF0h DFYHixeUZGaVz72RQkYG4TM0JGgJmv/pRg8ZX/fGQlA9h1iqQM8LReCI8CLCkc6yxhKN i1RcDCOjFZj5srVNUShJZgmopErgL4aAEFPFLe1R5Q0XSDksA+Y4kKbtiapx7DLqh7R2 1LSVxX9hQ32kklk7a4EbbV9ZjPEL4WW4ExJQBsHuMANhnHepr9Bbqu0dB3wgJ0DO9DtM jLeB6QIXE81ojdQxZzgl2GP28wTRZzEW2i0tPYbbxt/wMDBrd+1QOBmsBePft8TiycEh yfNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yUwBvONhM2SrHwMasxgS3JD4rno35nDNjTb3i8JGwQk=; b=BmjnLALGGxD2Lj2p9rq9DsMHQYAfWpDn5iWZx4pfrJk/24X/bDZsPVX4nn7f81jnNo 3bo8ZOFnUdUjG00wD7xFuFy7Zzd3bd9bajP6q+lt5+W6ToYjK3r8J+9A4yiWe07WTvBT 4jIva5/v4o3df7eu/1V/RyV8+oin80HHHLr0ScezQovfzzYfXTohmBo78THjr9LmvgYK o9nZvdiYO4hBIoHl902Tv5rVXbFGBr4hH6j3S//i4i6I/AYScfyH3OSAdn3K9KUtCn2b wLa7X5VXHqH0BPhf7jSuTQaQeb+wiUILoIqrptpo0nuyg71YAe2MfRAcI75WrbBF2nDy VJ7w== X-Gm-Message-State: AOAM532fWFQ/WnCyN/UkKNJxWSKuF8N9LPJOSkHBfHnKHOfzVjECMdwa AVPshOZZsdGsl9lXoJj2I4b8XGvF+bGSYBToOqUBuA== X-Google-Smtp-Source: ABdhPJxL3GzKtMLerntKBMQoNrC4soUXinv8LjbtJ5aRE/y+hlJ3UUOCUBjR283fZXrF5fudrLCaG62VS76RL06E1SU= X-Received: by 2002:a05:6512:3e27:: with SMTP id i39mr4879275lfv.38.1617987626725; Fri, 09 Apr 2021 10:00:26 -0700 (PDT) MIME-Version: 1.0 References: <20210408185127.l7cafoeq6svs4ns4@anna.jacobs.jacobs-university.de> <20210409133901.ifffu3jg4cghyji6@anna.jacobs.jacobs-university.de> <20210409135308.4nrlvndnj3phjih4@anna.jacobs.jacobs-university.de> <20210409141935.xsjj5c272rq453u5@anna.jacobs.jacobs-university.de> In-Reply-To: <20210409141935.xsjj5c272rq453u5@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Fri, 9 Apr 2021 10:00:15 -0700 Message-ID: To: Juergen Schoenwaelder , "Sterne, Jason (Nokia - CA/Ottawa)" , "Rob Wilton (rwilton)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000be0cca05bf8d1985" Archived-At: Subject: Re: [netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 17:00:36 -0000 --000000000000be0cca05bf8d1985 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 9, 2021 at 7:19 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Creating lots of special rules makes me feel uncomfortable. Is there > evidence that people reduce state value spaces a lot and in isolation, > i.e., they just rev a module to reduce some state value spaces? > > The IETF does not typically focus this much on implementation details. (Like I need the IETF to write "MUST NOT crash" in an RFC to get better code. ;-) Do we need 20 pages of rules on how to increment a SEMVER? I sure hope not. The client app still needs to access specific objects and it depends on the implementation details how to handle NBC changes. The SEMVER value is not very useful at the YANG object level, where the code needs to focus. /js > Andy > > On Fri, Apr 09, 2021 at 02:00:42PM +0000, Sterne, Jason (Nokia - > CA/Ottawa) wrote: > > The key focus here is *if* the author does remove the enum, then how > should we label the revision -> BC or NBC ? > > > > RFC7950 does indeed say that is NBC. But do we actually want that for > state for: > > - removing an enum > > - shrinking a range > > - changing a pattern in a manner that reduces the value space > > > > We're worried that will create too much "NBC noise" when it really in > practice won't be an issue at all for clients. Client just won't receive > the old values from the larger value space anymore. So why flag this as > NBC and make people do work to analyze it ? > > > > Jason > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: Friday, April 9, 2021 9:53 AM > > > To: Sterne, Jason (Nokia - CA/Ottawa) > > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > > Subject: Re: [netmod] Client validation text [was RE: YANG Versioning > > > Weekly Call Minutes - 2021-04-06] > > > > > > I do not recall that removing an enum was ever an issue in > > > practice. If an enum value is not used anymore, you leave the old enum > > > value and it will slowly but surely not be used anymore. (An enum > > > statement even has a status statement, so you can deprecate or > > > obsolete enum values.) That said, if the module owner decides to > > > remove the value, then this is indeed non-backwards compatible. (And > > > removing an enum paves the way to reallocate the associated number, > > > and be it by accident later again. I suggest people think twice > > > before removing enums.) > > > > > > /js > > > > > > On Fri, Apr 09, 2021 at 01:43:09PM +0000, Sterne, Jason (Nokia - > CA/Ottawa) > > > wrote: > > > > Urghh. I reversed my example. I should have said removing an > enum. Let > > > me reword: > > > > > > > > One key example is this: 7950 says that removing an enum from an > > > enumeration leaf is NBC (and that applies to state). But that may not > really > > > be how most implementations would want to treat state. Would we really > > > want to flag a module as non backwards compatible when a state leaf > has an > > > enum removed? Wouldn't that create a lot of unnecessary noise? > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder > > > > > Sent: Friday, April 9, 2021 9:39 AM > > > > > To: Sterne, Jason (Nokia - CA/Ottawa) > > > > > Cc: Rob Wilton (rwilton) ; netmod@ietf.org > > > > > Subject: Re: [netmod] Client validation text [was RE: YANG > Versioning > > > > > Weekly Call Minutes - 2021-04-06] > > > > > > > > > > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason (Nokia - > > > CA/Ottawa) > > > > > wrote: > > > > > > > > > > > One key example is this: 7950 says that adding another enum to > an > > > > > enumeration leaf is NBC (and that applies to state). But that may > not > > > really > > > > > be how most implementations would want to treat state. Would we > > > really > > > > > want to flag a module as non backwards compatible when a state leaf > > > gets an > > > > > additional enum? Wouldn't that create a lot of unnecessary noise? > > > > > > > > > > I read this in RFC 7950: > > > > > > > > > > o An "enumeration" type may have new enums added, provided the > > > old > > > > > enums's values do not change. Note that inserting a new enum > > > > > before an existing enum or reordering existing enums will > result > > > > > in new values for the existing enums, unless they have > explicit > > > > > values assigned to them. > > > > > > > > > > What do you want this to change to? > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > Fax: +49 421 200 3103 > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000be0cca05bf8d1985 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 9, 2021 at 7:19 AM Juerge= n Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Creating lots of special rules makes m= e feel uncomfortable. Is there
evidence that people reduce state value spaces a lot and in isolation,
i.e., they just rev a module to reduce some state value spaces?


The IETF does not typically focus this= much on implementation details.
(Like I need the IETF to write &= quot;MUST NOT crash" in an RFC to get better code. ;-)

<= /div>
Do we need 20 pages of rules on how to increment a SEMVER?
<= div>I sure hope not. The client app still needs to access specific objects = and it depends on
the implementation details how to handle NBC ch= anges.=C2=A0 The SEMVER value is not
very useful at the YANG obje= ct level, where the code needs to focus.



/js

Andy
=C2=A0

On Fri, Apr 09, 2021 at 02:00:42PM +0000, Sterne, Jason (Nokia - CA/Ottawa)= wrote:
> The key focus here is *if* the author does remove the enum, then how s= hould we label the revision -> BC or NBC ?
>
> RFC7950 does indeed say that is NBC.=C2=A0 But do we actually want tha= t for state for:
> - removing an enum
> - shrinking a range
> - changing a pattern in a manner that reduces the value space
>
> We're worried that will create too much "NBC noise" when= it really in practice won't be an issue at all for clients.=C2=A0 Clie= nt just won't receive the old values from the larger value space anymor= e.=C2=A0 So why flag this as NBC and make people do work to analyze it ? >
> Jason
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.= de>
> > Sent: Friday, April 9, 2021 9:53 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org
> > Subject: Re: [netmod] Client validation text [was RE: YANG Versio= ning
> > Weekly Call Minutes - 2021-04-06]
> >
> > I do not recall that removing an enum was ever an issue in
> > practice. If an enum value is not used anymore, you leave the old= enum
> > value and it will slowly but surely not be used anymore. (An enum=
> > statement even has a status statement, so you can deprecate or > > obsolete enum values.) That said, if the module owner decides to<= br> > > remove the value, then this is indeed non-backwards compatible. (= And
> > removing an enum paves the way to reallocate the associated numbe= r,
> > and be it by accident later again. I suggest people think twice > > before removing enums.)
> >
> > /js
> >
> > On Fri, Apr 09, 2021 at 01:43:09PM +0000, Sterne, Jason (Nokia - = CA/Ottawa)
> > wrote:
> > > Urghh.=C2=A0 I reversed my example.=C2=A0 I should have said= removing an enum.=C2=A0 Let
> > me reword:
> > >
> > > One key example is this:=C2=A0 7950 says that removing an en= um from an
> > enumeration leaf is NBC (and that applies to state). But that may= not really
> > be how most implementations would want to treat state. Would we r= eally
> > want to flag a module as non backwards compatible when a state le= af has an
> > enum removed?=C2=A0 Wouldn't that create a lot of unnecessary= noise?
> > >
> > > > -----Original Message-----
> > > > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-u= niversity.de>
> > > > Sent: Friday, April 9, 2021 9:39 AM
> > > > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com&g= t;
> > > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org
> > > > Subject: Re: [netmod] Client validation text [was RE: Y= ANG Versioning
> > > > Weekly Call Minutes - 2021-04-06]
> > > >
> > > > On Fri, Apr 09, 2021 at 01:32:15PM +0000, Sterne, Jason= (Nokia -
> > CA/Ottawa)
> > > > wrote:
> > > >
> > > > > One key example is this:=C2=A0 7950 says that addi= ng another enum to an
> > > > enumeration leaf is NBC (and that applies to state). Bu= t that may not
> > really
> > > > be how most implementations would want to treat state. = Would we
> > really
> > > > want to flag a module as non backwards compatible when = a state leaf
> > gets an
> > > > additional enum?=C2=A0 Wouldn't that create a lot o= f unnecessary noise?
> > > >
> > > > I read this in RFC 7950:
> > > >
> > > >=C2=A0 =C2=A0 o=C2=A0 An "enumeration" type ma= y have new enums added, provided the
> > old
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enums's values do not cha= nge.=C2=A0 Note that inserting a new enum
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0before an existing enum or re= ordering existing enums will result
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0in new values for the existin= g enums, unless they have explicit
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0values assigned to them.
> > > >
> > > > What do you want this to change to?
> > > >
> > > > /js
> > > >
> > > > --
> > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<https://www.jacobs-university.de/>
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.jacobs-university.de/>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000be0cca05bf8d1985-- From nobody Mon Apr 12 15:00:34 2021 Return-Path: <01000178c8197d0b-f63d33b3-0d23-402e-98e9-6905d8221418-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 E779C3A10D2; Mon, 12 Apr 2021 15:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3jNvK6o33Jw0; Mon, 12 Apr 2021 15:00:18 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761EE3A10D4; Mon, 12 Apr 2021 15:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618264817; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Feedback-ID; bh=boXNZlVUCr+e76kJAXYgSvCJ+AMANM5ds9ZgOL/C3y0=; b=E+zY0k4JdE5/SSx+N+LGEXs9aFrIVLjJj5VJEX8lfTnBN6BW/cWhnUvfSfN4ckAh LmkGR6VtTPARM4qCpFzsAwJXeliYc5WUNG6HeEvlJObb+s2taqIresiDeCMj8mkx5pZ odlRKYI0fmHfj5+v2bKl2gPBPXen+wh2aHhzWVpI= Content-Type: multipart/alternative; boundary="Apple-Mail=_1D8B9787-030F-4A7A-87C0-9CD0F2A67824" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Kent Watsen In-Reply-To: <01000178c7f052f4-6427fb3a-f109-4c4f-b391-5182dad5f40f-000000@email.amazonses.com> Date: Mon, 12 Apr 2021 22:00:17 +0000 Cc: "netmod@ietf.org" Message-ID: <01000178c8197d0b-f63d33b3-0d23-402e-98e9-6905d8221418-000000@email.amazonses.com> References: <01000178c7f052f4-6427fb3a-f109-4c4f-b391-5182dad5f40f-000000@email.amazonses.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.12-54.240.8.96 Archived-At: Subject: Re: [netmod] Please fill in WG Summaries - https://trac.ietf.org/trac/ops/wiki/IETF110summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 22:00:24 -0000 --Apple-Mail=_1D8B9787-030F-4A7A-87C0-9CD0F2A67824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oops, netconf --> netmod K. > On Apr 12, 2021, at 5:15 PM, Kent Watsen wrote: >=20 > Joel, >=20 > During the chair=E2=80=99s call, Lou and I decided to ask you to do = this, if your willing=E2=80=A6 ;)=20 >=20 > Kent and Lou >=20 >=20 >=20 >> On Mar 11, 2021, at 1:04 PM, Warren Kumari > wrote: >>=20 >> Hi there all, >>=20 >> Could y'all please take a few minutes to fill in short summaries (a = paragraph or two) on what happened during your WG meetings? This is = especially useful for Rob and I to use at the post-IETF110 IESG/IAB = meeting so that we can highlight any hot topics in the WG. >>=20 >> Link: >> https://trac.ietf.org/trac/ops/wiki/IETF110summary = >> W >>=20 >> --=20 >> Perhaps they really do strive for incomprehensibility in their specs. >> After all, when the liturgy was in Latin, the laity knew their place. >> -- Michael Padlipsky >=20 --Apple-Mail=_1D8B9787-030F-4A7A-87C0-9CD0F2A67824 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oops,= netconf --> netmod

K.



On Apr 12, 2021, at 5:15 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:

Joel,
During the chair=E2=80=99s call, Lou = and I decided to ask you to do this, if your willing=E2=80=A6 =  ;) 

Kent and Lou



On Mar 11, 2021, at 1:04 PM, = Warren Kumari <warren@kumari.net> wrote:

Hi there all,

Could = y'all please take a few minutes to fill in short summaries (a paragraph = or two) on what happened during your WG meetings? This is especially = useful for Rob and I to use at the post-IETF110 IESG/IAB meeting so that = we can highlight any hot topics in the WG.

Link:
https://trac.ietf.org/trac/ops/wiki/IETF110summary
W

--
Perhaps they really do strive for = incomprehensibility in their specs.
After all, when the = liturgy was in Latin, the laity knew their place.
-- = Michael Padlipsky


= --Apple-Mail=_1D8B9787-030F-4A7A-87C0-9CD0F2A67824-- From nobody Mon Apr 12 19:38:26 2021 Return-Path: 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 2E5603A0DD8; Mon, 12 Apr 2021 19:38:25 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 w_Fr9rcx4li3; Mon, 12 Apr 2021 19:38:20 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 234123A0DD9; Mon, 12 Apr 2021 19:38:16 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2790580E53; Tue, 13 Apr 2021 02:38:16 +0000 (UTC) From: Christian Hopps Message-Id: <55915FD1-7563-4058-96D8-AC4ED9A37957@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_55F29526-415C-466A-BABC-BFCDC9DE691A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 12 Apr 2021 22:38:15 -0400 In-Reply-To: Cc: Christian Hopps , "netmod@ietf.org" , "draft-ietf-netmod-geo-location.all@ietf.org" To: "Rob Wilton (rwilton)" References: X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-geo-location-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 02:38:25 -0000 --Apple-Mail=_55F29526-415C-466A-BABC-BFCDC9DE691A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) = wrote: >=20 > Hi Chris, >=20 > Apologies for the delayed AD review of this document. >=20 > I found that this document to be interesting, enlightening, and well = written, so thank you. >=20 >=20 > I only have a few minor comments, the rest are grammatical nits. Some = I spotted manually; the rest are from a beta version of a grammar tool = that I am playing with. >=20 > Minor comments/questions: >=20 > 1. > In the YANG module, the pattern statements have 3 ranges of = characters, > but the description only indicates two ranges. Is there a reason that > the following pattern doesn't work? > pattern '[ -@\[-~]*'; =46rom an old email on the list: "These 3 ranges seem to make pyang = happy. I don't know why I need to break up the second range into 2 = adjacent ranges like that to make pyang not complain, but complain it = does if I just use: '[ -@\[-~]*'" > 2. > I note that the YANG module allows just a lat, or a long, or a height > to be specified, rather than requiring at least a pair of lat/long or > x/y coordinates. I think that this is fine (and keeps the model > flexible), but wanted to check that this is the intentional. > 3. > I also note that that grouping doesn't require that any coordinates be > specified at all. I presume that this is intentional, it makes sense > to me (e.g., if it is intended to be optional). My answer to a thread on the list asking for removal of some of the = mandatory designations which cause problems: "The intention was for a location node to be required if the = container was present. Apparently this will only work if = "container geo-lcoation" is a presence container. I'm not even sure = that's all that smart of a requirement (e.g., maybe someone just wants = to indicate the reference-frame for an object). I'll remove the = mandatory from location." > 4. In the YANG module, > "v-east is the rate of change (i.e., speed) perpendicular > to truth-north as defined by the geodetic-system."; >=20 > As a nit, this doesn't actually define whether a positive v-east > value is in the East or West direction. I appreciate that this is > obvious, but for the other two components in the vector, it is > unambiguously specified. How about: "v-east is the rate of change (i.e., speed) perpendicular to the right of truth-north as defined by the geodetic-system."; >=20 > 5. > In Security Considerations: >=20 > Since the grouping defined in this module identifies locations, > authors using this grouping SHOULD consider any privacy issues that > may arise when the data is readable. >=20 > Perhaps, expand this paragraph to give an example, e.g., revealing > the physical location of a device, or data center. How about: "Since the grouping defined in this module identifies locations, authors using this grouping SHOULD consider any privacy issues that may arise when the data is readable (e.g., customer device locations, etc)." >=20 > The rest are just grammar nits: >=20 >=20 > In addition to identifying the astronomical body we also need to > define the meaning of the coordinates > =3D> > In addition to identifying the astronomical body, we also need to > define the meaning of the coordinates fixed >=20 > In addition to the "geodetic-datum" value we allow refining the > coordinate and height accuracy using "coord-accuracy" and "height- > accuracy" respectively. > =3D> > In addition to the "geodetic-datum" value, we allow refinement of = the > coordinate and height accuracy using "coord-accuracy" and "height- > accuracy" respectively. fixed > This is the location on or relative to the astronomical object. It > is specified using 2 or 3 coordinates values. > =3D> > This is the location on, or relative to, the astronomical object. = It > is specified using 2 or 3 coordinates values. fixed > The intent of the grouping being defined here is to identify > where something is located, and generally this is expected to be > somewhere on or relative to Earth (or another astronomical body). > =3D> > The intent of the grouping being defined here is to identify > where something is located, and generally this is expected to be > somewhere on, or relative to, Earth (or another astronomical body). fixed > At > least two options are available to YANG models that wish to use this > grouping with objects that are changing location frequently in non- > simple ways, they can add additional motion data to their model > directly, or if the application allows it can require more frequent > queries to keep the location data current. > =3D> > At > least two options are available to YANG models that wish to use this > grouping with objects that are changing location frequently in non- > simple ways. They can add additional motion data to their model > directly. Or, if the application allows, it can require more = frequent > queries to keep the location data current. fixed > When coord-accuracy is specified it overrides the geodetic-datum = implied > accuracy. > =3D> > When coord-accuracy is specified, it overrides the geodetic-datum = implied > accuracy. fixed >=20 > When specified it overrides the geodetic-datum implied default. > =3D> > When specified, it overrides the geodetic-datum implied default. fixed > indicated by the reference-frame value. > =3D> > indicated by the reference-frame. fixed > For a formula to convert these values to speed and heading see > this modules defining document RFC XXXX."; > =3D> > For a formula to convert these values to speed and heading see > RFC XXXX."; fixed > You have "truth-north" and "truth north" and "true-north". Should > these all be "true north"? fixed >=20 > YANG grouping using decimal64 values rather than strings. For the > relative height cases the application doing the transformation is > expected to have the data available to transform the relative height > into an absolute height which can then be expressed using the YANG > grouping. > =3D> > YANG grouping using decimal64 values rather than strings. For the > relative height cases, the application doing the transformation is > expected to have the data available to transform the relative height > into an absolute height, which can then be expressed using the YANG > grouping. fixed > Grammar Warnings (generated by a tool): > Draft Text: > Indeed it is easy to imagine a network or device located on The Moon, = on Mars, on Enceladus (the moon of Saturn) or even a comet (e.g., = 67p/churyumov-gerasimenko). >=20 > Warning: Did you forget a comma after a conjunctive/linking adverb? > Suggested change: "Indeed," fixed >=20 > Draft Text: > This document defines a "geo-location" YANG grouping that allows for = all of the above data to be captured. >=20 > Warning: Consider using all the. > Suggested change: "all the" fixed > Draft Text: > When specified these values override the defaults implied by the = "geodetic-datum" value. >=20 > Warning: "When" at the beginning of a sentence usually requires a 2nd = clause. Maybe a comma, question or exclamation mark is missing, or the = sentence is incomplete and should be joined with the following sentence. > Suggested change: "When specified, " fixed > Draft Text: > In both choices the exact meanings of all of the values are defined by = the "geodetic-datum" value in the [xref]. >=20 > Warning: Consider using all the. > Suggested change: "all the" fixed > Draft Text: > During the development of this module, the question of whether it = would support data such as orientation arose. > Warning: Wordiness: Consider shortening this phrase. > Suggested change: "whether" ? >=20 > Draft Text: > For test "A.1.2.1" the YANG geo location object either includes a CRS = ("reference-frame") or has a default defined ([xref]). >=20 > Warning: This word is normally spelled as one. > Suggested change: "geolocation" unchanged. > Draft Text: > Many systems make use of geo-location data, and so it's important to = be able describe this data using this geo-location object defined in = this document. >=20 > Warning: The preposition 'to' is required in front of the verb = 'describe'. > Suggested change: "able to describe" Removed this paragraph it's unneeded and not very clear. >=20 > Draft Text: > For accuracy it has a single "u" parameter for specifying uncertainty. > Warning: The comma is probably missing here: accuracy, it. > Suggested change: "accuracy, it" fixed > Draft Text: > This is used by many application (e.g., Google Maps API). >=20 > Warning: Possible agreement error. The noun application seems to be = countable; consider using: many applications. > Suggested change: "many applications" fixed > Draft Text: > Thus GML "gml:pos" values can be mapped directly to the YANG grouping, = with the caveat that some loss of precision (in the extremes) may occur = due to the YANG grouping using decimal64 values rather than doubles. >=20 > Warning: Did you forget a comma after a conjunctive/linking adverb? > Suggested change: "Thus," fixed > Draft Text: > Furthermore "gml:validTime" can either be an Instantaneous measure = ("gml:TimeInstant") or a time period ("gml:TimePeriod"). > Warning: Did you forget a comma after a conjunctive/linking adverb? > Suggested change: "Furthermore," fixed > Draft Text: > As with the "kml:altitudeMode" value, the YANG grouping supports the = ignore case but not the relative case. >=20 > Warning: After 'the', do not use a verb. Make sure that the spelling = of 'ignore' is correct. If 'ignore' is the first word in a compound = adjective, use a hyphen between the two words. Note: This error message = can occur if you use a verb as a noun, and the word is not a noun in = standard English. I think it just wants me to hyphenate "ignore-case". "ignore" is an = adjective here "case" is the noun. *shrug*, I think it reads fine the = way it is for a technical document. > Draft Text: > Thus the YANG grouping and KML values can be directly mapped in both = directions (when using a supported altitude mode) with the caveat that = some loss of precision (in the extremes) may occur due to the YANG = grouping using decimal64 values rather than strings. > Warning: Did you forget a comma after a conjunctive/linking adverb? > Suggested change: "Thus," fixed > Draft Text: > The allocation policy for this registry is First Come First Served, = [xref] as the intent is simply to avoid duplicate values. >=20 > Warning: It seems that a comma is missing. > Suggested change: "Come," fixed > Draft Text: > All of the data nodes defined in this YANG module are = writable/creatable/deletable (i.e., "config true", which is the = default). > Warning: Consider using all the. > Suggested change: "All the" fixed > Draft Text: > These are the subtrees and data nodes and their = sensitivity/vulnerability: > None of the writable/creatable/deletable data nodes in the YANG module = defined in this document are by themselves considered more sensitive or = vulnerable then standard configuration. >=20 > Warning: Did you mean than? > Suggested change: "than" fixed > Draft Text: > Some of the readable data nodes in this YANG module may be considered = sensitive or vulnerable in some network environments. > Warning: If the text is a generality, 'of the' is not necessary. > Suggested change: "Some" I think it's correct to leave this, but I could be misunderstanding the = advice. > Draft Text: > Below is a the YANG tree for the fictitious module that uses the = geo-location grouping. >=20 > Warning: Maybe you need to remove one determiner so that only a or = the is left. > Suggested change: "a" fixed with "the" only. >=20 > Draft Text: > We would also like to thank Peter Lothberg for the motivation as well = as help in defining a broadly useful geographic location object, and = Acee Lindem and Qin Wu for their work on a geographic location object = that led to this documents creation. >=20 > Warning: Possible typo: apostrophe is missing. Did you mean = documents' or document's? > Suggested change: "documents'" fixed. Nice tool! Thanks, Chris. >=20 > Regards, > Rob >=20 --Apple-Mail=_55F29526-415C-466A-BABC-BFCDC9DE691A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmB1BBcACgkQLh2DDte4 MCU86Q/+P6jkbeUc8kt380MX9eyZf5Bd1kF/ciCrHxtjYckimxq3KciSa6Oaffmg fqMPhngFvYX9RByOAOh4JhrWwj1GHGDznAg28Bq8EIGhkwQX95cJMwCPje17XrG8 SsbsR+DtTy0a9a12HRBylJUS6FOnDRNH6Qw3kKuTBQt9t8cNKBsz101CAFipgAnf j3Z0U+djTzAqqV1JZTIpzBAUubFr28y1C3sH5fnMKnOuQkJDn3Yvri4UfcW4+n3x OUcHrldVMEX2BYIxeFnpe/9D34Oj1W5+xtLayck36vilM0A8vsh3zD17lQHSUCg8 HOwpnBnct3Ao+2kR3BzkWQF6F4/wiP/8Q6uTamw04/Ggsd5JGbv+yeZFsVDogYXs o3uXNVpcbNm9iz28oSFVcpgg3YWDEZUulMSCNbXjJ6QXtlgHHpw6wk/XmJMASiDR F6HLKYCVqQntXFh0sHCoz/5wUIbk5L6qLEDnvg5DTJ+2gSuwth8VDm/X/g33dzqJ lPA/Bxd2GwRTKAIUvzylasAKF62LWD8XrjFpMaVzQoClhha9//x+q1j567kol7Db HoAgUn++jo8Y4Dmsqlmk7eZJeYa//I2VpMqNgN+0Omhw8/G43+/e/Cok+j4qQ2yE d7F9myKeSoFl4FILcgF414eKrKLEQKdtoJeEgE9lbuVId7pVrdc= =qSYj -----END PGP SIGNATURE----- --Apple-Mail=_55F29526-415C-466A-BABC-BFCDC9DE691A-- From nobody Tue Apr 13 03:08:30 2021 Return-Path: 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 C84223A1037; Tue, 13 Apr 2021 03:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.918 X-Spam-Level: X-Spam-Status: No, score=-11.918 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=e7OIxFHl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vQ/yfRdw 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 yHb9ET084F_3; Tue, 13 Apr 2021 03:08:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B2B3A0B13; Tue, 13 Apr 2021 03:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14531; q=dns/txt; s=iport; t=1618308503; x=1619518103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GKOwZDz6g/T7tDgkfB3c5tv4MyF7M+xxMsxZfimCTC8=; b=e7OIxFHl99p0wtazPM8UBgY1kWFJ11TYhyDpH8pzBJ6Tj8VvNdDcnxi+ Q+vYTKuqwmGkcL9q7MQJJc7itcgbygQPAHCMHHOdbBbk7rn/yWGCrKgH1 9QTthmmbfcjYVJ8Eenu9NRIh0d40IBEorNqp+uLnUi3kkFpOKo199viKc 8=; X-IPAS-Result: =?us-ascii?q?A0DpAQC7bHVgmJldJa1QChwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFSgVNRgVg2MQuIAAOFOYhiA48oihSBQoERA1QLAQEBDQEBMgIEAQGBFgGDO?= =?us-ascii?q?QKBcQIlOBMCAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFohVANhkQBA?= =?us-ascii?q?QEBAgE6BgEBNwELBAIBCA4DBAEBAR4QMh0IAQEEDgUIgmmCVgMOIQEDSZ9pA?= =?us-ascii?q?oofd4E0gQGCBAEBBoUgGIITCYE5gneKWyccgUlCgRNDgl8+gmAEgSkBBwsBB?= =?us-ascii?q?xyDSoIrgVgGDFoGAjwCJAEDFAQyDR41OgdFARkFBgEBAQ0ZSZAxAo8WiSqRY?= =?us-ascii?q?gqDC5AwjHaDTYp7ljCzYAQLI4QzAgQCBAUCDgEBBoEjSCE7MHBwFTuCaVAXA?= =?us-ascii?q?g6OHwwNCYNOillzOAIGCgEBAwl8iwMBgQ4BAQ?= IronPort-PHdr: A9a23:7006sRNNLL26sO6NViEl6nfxWUAX047cNxMJ6pchl7NFe7ii+JKnJ kHE+PFxlzfhVoXc8+pfze3MvPOoVW8B5MOHt3YPONxJWgQegMob1wonHIaeCEL9IfKrCk5yH MlLWFJ/uX3uN09TFZX1Z1rKumb06iQdSV3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/N lO4twLU48IXmoBlbK02z0ihnw== IronPort-HdrOrdr: A9a23:P+4GhawRo10rUEcL83rcKrPxXe8kLtp033Aq2lEZdDV8Sebdv9 yynfgdyB//gCsQXnZlotybJKycWxrnlKJdybI6eZOvRhPvtmftFoFt6oP+3ybtcheRysd07o 0lSaR3DbTLYmRSpczx7BCkV/Mpx9ea+K6l7N2usEtFZysCUdAG0y5SDAGHHkpqACxPApQkHJ SRj/A32QaIU3IRc8i9Gz05RODFvdLGj9bLZhQBCh4h5mC1/HKVwZT9FAWV2QpbbiNXzd4ZgC b4uiHaxoHmifG0zRfAy3Tehq43pPLNwsZObfb88fQ9BS7rjm+TFeFccp2E+As4ueS+rGst+e O83ysIG+RWxzfvcnquoR3rsjOQkAoGz3P501eXjT/CjKXCNUgHIvFMj45YbRfVgnBI1LoXvc 47vBP6i7NtARzNhyj77dTTPisa63acm2YokuIYkhVkIO0jQYJRtoAW8Qd0F5oNDUvBmfgaOd RuF83V6bJqd0qbZRnizxBS6eGrN05DeiuucwwngIi4wjJWlHd2ww8z38oEhEoN85o7Vt1t+/ nEGr4ArsAMcuYmKYZGQMsRS8q+DWLABTjWNniJHFjhHKYbf1rQtp/M5qkv7u3CQu1L8LIC3L D6FH9Iv287fEzjTeeU2odQzxzLSGKhGRPg199Z/Jo8nrHnXrLkPWmiRTkV4o6disRaJveed+ e4OZpQDfOmB3DpA5x10wr3XIQXJmIZVMETp9YnS1ODqs/GMeTRx6vmWceWAICoPScvW2v5DH dGdiP0Pt984keiXWK9gBW5YQKqRmXPubZLVITK9ekaz4YAcqdWtBIOtFi/7saXbTlLsqk8el piMKrq+5nL/FWezCLt1SFEKxBdBkFa7PHLSHVRvzIHNEvybPIEoNWQeWdb2XOdPR9hR8bKEA pSzm4HvZ6fHti1/2QPGtinOmWVgz84v3SRVaoRnaWF+IP4YJ8iF40nX6ZwDA3PEBRwlW9R2T 9+QT5BYnWaOiLliK2jgpBROfrWcMNkhhy3ZeROr2jEiEmarcYzZ3cSUjK0S/SLiQI2Szc8vC wrz4YvxJ673RemMy8WnfkxOlwkUhXnPJt2SCC+ILhytp+uUgdqVmuOjSGdkHgICxrX3nRXoH fgIy2ScezMGXxHtBljo/zX2WIxUHmBdERtbX0/lotxGQ39yypO+N7OQLav2G2MbVZH+MUhCX XuZDsfJR4G/aHr6DechCuCGXI6xp8nI+zaC/A5f6vO3262Qbf45p0uDrta+o1oO8vptfJOWe WDexWNJDe9EO8x3ReJz0xVdRVcuT0hkfny3gfi43X91HkjAeDKKFAOfcBRH/iMq2zlTe2Pyp N3kJY8uvaxKHz4bpqDxbvMZzBObhPVrmjedZBjlblE+aYzvqB0BZ/VTH/B02xGxgw3KIPsj1 wFKZ4LlozpK8tqZYgfaihZ9l0mmJCGK1YqqBX/Bqs7cUs2h3HWMtuV69Pz2PYSK1zEoBG1NU iU8iVb8fuARSeF2LIAA687IGhdaiEHmTxf1fLHc5eVBBShdulF8lb/L2S0d6VFTrOZXboXtR R37riz7qCqXju93BqVuzR1IqhDqTn6BcyzBR+BAu5O/ZixP0+Wjq6j/c60i3P2RFKAGjAlrJ wAcVZVaMJJziQmhskw1CO5T6TsuEIrk1dE+1hc5xfQ85nj5H2eBF1MNA3Sn45fUjZSOGWZlM ity5ns6F3tpDxenYTZHEhefttSC8EdQ4j+ISBpM9URtteTjt0SqzUGZgwvAW46gC382O0j3a 7R4oShZ9Hf X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,219,1613433600"; d="scan'208";a="669088391" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Apr 2021 10:08:22 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13DA8MEO001171 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 13 Apr 2021 10:08:22 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 13 Apr 2021 05:08:22 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 13 Apr 2021 05:08:21 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Tue, 13 Apr 2021 05:08:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a+Bul3kW4O4QDjtZkdXPKZmSI04iRh2BGbMH88YpgnrvbpA6psyTGLfwi6DBiD363en3lHLJfZC+6oKzwNV/fyRKCFHuRadaSLLEsl/Qbtg4yYv5ABCkZztAP99IujoZiQz00K97uhaz6SpXJx5d9XwELsUi6N0J0vAZ+RsdtJe7q7oRnHHvzZLOuYQyfVdH9GdLNgUGaAjoKdtHHXBpY9L4wkDIBe36Ib6D7lFamR9LT9cMNqiQltLMWa22IPgP4L/wsJbV5mLyOeBN/e1QnpIyTY9ItXl/vYoM71xTCWx9pwQB7bcxF2+g7wPTSP+JjihTPwA4h6Gmp5Mc3PevjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+wcjfiwNq7xLmDHTC9l3PYaUeAo8MFg1Dg75Ef9rpc=; b=fd3KeGyoVjCO0e4w1KCFgH5UR09cqse7JCDZ2sfdrn/P4wrJV+rDctVki9MbChAnaAk0jjMvD0OUoXGENSq/GnTVVqqRm9/1tfsLameC+AYmR9npXf3E/7qU6Ied3GWtPb950gV9Kj55HjzbDeZyFZzQkOEzG1d9RIeyk8JBp9gHcGi9S6QwMQWziIe9X5dzNfnbq1pVlfQBaN31BWBhtn6E9w6KnYLbZC1Kl9jVSffVVWgnbVHkbtuEEX3yqTMxGoCSF4q1O5ZihOlMMelbfyBkuvkeQCQdzJStvtffrA5UHc9ImEnXwaICvM+Z5PkxBKaRHsxarO+KcfI0XBmKEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+wcjfiwNq7xLmDHTC9l3PYaUeAo8MFg1Dg75Ef9rpc=; b=vQ/yfRdwDs+yuvB2C2CKihmh0oPSwr/LA5tHBGXR5sz5Qw+8xMg7MgSVgG7aT2ZltHR6RJ0V6zSiwu3o0dejDtloPQCyJYLY/ECnu0MOwz7chtp8MpTb791ka1cb8RdJ0yq9yzrACwje9aYHYXie0G34g+4fQolyAir8sbOPA7M= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4598.namprd11.prod.outlook.com (2603:10b6:208:26f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Tue, 13 Apr 2021 10:08:21 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.4020.022; Tue, 13 Apr 2021 10:08:20 +0000 From: "Rob Wilton (rwilton)" To: Christian Hopps CC: "netmod@ietf.org" , "draft-ietf-netmod-geo-location.all@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-geo-location-07 Thread-Index: AdcTkShqN1Smhf9ATFKg3L8WBycm5QcfOVmAAA4md6A= Date: Tue, 13 Apr 2021 10:08:20 +0000 Message-ID: References: <55915FD1-7563-4058-96D8-AC4ED9A37957@chopps.org> In-Reply-To: <55915FD1-7563-4058-96D8-AC4ED9A37957@chopps.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a492e0fb-b64c-459a-f32e-08d8fe641105 x-ms-traffictypediagnostic: MN2PR11MB4598: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RmkanzXKvsBIAQaQ0g7MI8G1TGIV2+Vg5hJH9SMvuGysUENxjl86iZReaaD/6EQ37Slm0k6FAUHCJBTSHTymuFayBeTk5l/5J89JUpXRqwgc9U+lQNIxuT+LbMefsY3FrE3i6wy/trmBJlajzJFM8GgehcIciT4PCkTqgeIYGOdCzTPxDGPDZO0wG8+BJPJRHvOpEBDWZYA3oNWRPA25FmF9h7/Cv6DsoP2CiLOtW4XyQzd1OggQ4dsmsKIeeB9JwjZrnF311e9dyq4+1TCtvUZY79gIcV/6+viAaR2KNWeRYyYpscpXTW0QIt5AOeFAmqv/mQs3Jo8mcFuE1PiF98DVp4qNAuNPADHUsu1PmJ4wX6JKW6+G/I5yPPZ6beh92iQ97kwpYwSYg4eRjnh50Fnxjqs8gTUEKuoMcwVxJVu6p9eGhwoUZJJ6PNpokDd6wHpKfFlA5vvyY92g9tQ4c5eOAfDVnHUiBOcHKxb8nFy3t5KKM/3CiRqiWMdeehiBtBOQSr3rQ2up8vfYdX6O9ZHiynsYfPPBizaww+06BolmXBW8mBvYUV7QA0q11vUsbbnUXN+nkod2XhaggnzMUmh78FVJiOdmqRvviRjhrsg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(376002)(396003)(136003)(366004)(64756008)(66446008)(186003)(5660300002)(71200400001)(66556008)(9686003)(86362001)(2906002)(30864003)(55016002)(66476007)(4326008)(478600001)(6506007)(8676002)(6916009)(8936002)(52536014)(66946007)(33656002)(83380400001)(54906003)(316002)(7696005)(53546011)(76116006)(26005)(38100700002)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Z5pWNUCzDPYA34JcO11WVNx1dUH/kzaCZYHdgunHDiGLBUnAwMt/dlLecRfu?= =?us-ascii?Q?hArBMdW5u+wNttZ64GMyccBWJ3Ywlb3ZbFmrSYOEDdbsYKK8I1S1m7k/Rict?= =?us-ascii?Q?+6fQHB3APpT5aoHqKQQ1xvetgCqX9zJ4M1RFd5/zpbN3iiglH9PCXGyR/MCM?= =?us-ascii?Q?NVWBMeVzVlddGOmXFBAW7Mg3aPf4HfHOnQXNrJn35iOH0n2YirSNMXYNYtJi?= =?us-ascii?Q?VUBXyG4HkIHh9OdKIwcm+AyqlGFucE4YL/TnTotYu3Lp+VFPPRu/hx0y0Uvs?= =?us-ascii?Q?SJ9tyF1M975B2P+oW2i4P6/TpWQhDRW3t5WRECTEtRtHx6ti7HtKpbsm/Hn/?= =?us-ascii?Q?812ZXNmERs6b/IoIC/p0tr8wQE/UWr07+/Ye0XVRhhw6n1aff7OYo+5+WpoA?= =?us-ascii?Q?jHYXMlNzvRYE0LQ5abCAk7O5/2sxYc1VJ5B44WqnTmh9rqKRu+HCmCi/HTiN?= =?us-ascii?Q?nfd/2j7QEdwLzW5oN+5qv6WDyZdqsus20MG7YPnbDNQld2h6oryIdrcIfENi?= =?us-ascii?Q?xyjZfvgzsyQTaS2zo9r+R4z6hmfQY3jl7Ofd7d4VGJSfGaBqIHfStGEJHu6D?= =?us-ascii?Q?3AatilIoGscN+v2xKauiZP9kXd/mXqyCx1iugsyx2gWgdyRD/5s0n/FeLdy1?= =?us-ascii?Q?Xa7x20v1eucMl1fPktSouVZu4Sz/zkHKk+IdE6rfRg9aXjsbGZzPWKppjphj?= =?us-ascii?Q?VUY4tfeXKhh6dTpMh6u76sUoq8aKPKqL5p7mObv43nDueBj8GHkLuV0nZ6Jx?= =?us-ascii?Q?u3kRsgPH2LDvghyP+KhOLE/0HN984PuaiyZDJuacp+NbsO7rrT3rz4QRHkYL?= =?us-ascii?Q?CdfnYdf2t1VQZOf7nCGo8k8vR766Uv+WJQFMxGxUgv3DrhjNASd6ziMSkqn3?= =?us-ascii?Q?i6mOy8CE9loUTznqdeT8Up5FXL60etSMehjndcmU9GnYI7vXDcJP5Hyp5Zbu?= =?us-ascii?Q?tHSkJxSEG6/JMSJtmQ3fV3/qBYUY9Wd3Om+D0D+TSxb2e10URNcgUqWYaf1k?= =?us-ascii?Q?UR20RjkO4bF5qvJWF5/+kG9nmC/VV2RmYHsO1qYzvvCpBNEWF8p3RrSS0Yxt?= =?us-ascii?Q?v9IWhYF66VDaWELYfl3qWsbUVR/JcaWjJgAAi0GhqSAJLe9x0qXuwn/9ZnwW?= =?us-ascii?Q?LQS7sCjycFy12QJrli25VrJqRodIMNAR/LabVkFJYraHVq47upGpO1a0bR0T?= =?us-ascii?Q?VEl1ClfB4Ur4A3ATyG5j/xCtEbGExRQDgWbj9ADZOCZQdff9GzVaGPhC+qzx?= =?us-ascii?Q?hsMoV1HhII4tqG8Cn+rMwwqgWjqyg7mHmgSgVcZwwtG5l0VMVgygHTPehh2+?= =?us-ascii?Q?pmthfrHEcxAZbeUpX4RhNOQT?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a492e0fb-b64c-459a-f32e-08d8fe641105 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 10:08:20.6883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +76bnAUF/gjeIeI3plLouNOcMWRldCAOhnSn4Z7pHmRita539csqpBwUZepATBLJmwt6dqzZMfSFKTrnzFJ7lQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4598 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-geo-location-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 10:08:29 -0000 Hi Chris, > -----Original Message----- > From: Christian Hopps > Sent: 13 April 2021 03:38 > To: Rob Wilton (rwilton) > Cc: Christian Hopps ; netmod@ietf.org; draft-ietf- > netmod-geo-location.all@ietf.org > Subject: Re: AD review of draft-ietf-netmod-geo-location-07 >=20 >=20 >=20 > > On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) > wrote: > > > > Hi Chris, > > > > Apologies for the delayed AD review of this document. > > > > I found that this document to be interesting, enlightening, and well > written, so thank you. > > > > > > I only have a few minor comments, the rest are grammatical nits. Some I > spotted manually; the rest are from a beta version of a grammar tool that > I am playing with. > > > > Minor comments/questions: > > > > 1. > > In the YANG module, the pattern statements have 3 ranges of characters, > > but the description only indicates two ranges. Is there a reason that > > the following pattern doesn't work? > > pattern '[ -@\[-~]*'; >=20 > From an old email on the list: "These 3 ranges seem to make pyang happy. = I > don't know why I need to break up the second range into 2 adjacent ranges > like that to make pyang not complain, but complain it does if I just use: > '[ -@\[-~]*'" [RW]=20 Okay.=20 >=20 > > 2. > > I note that the YANG module allows just a lat, or a long, or a height > > to be specified, rather than requiring at least a pair of lat/long or > > x/y coordinates. I think that this is fine (and keeps the model > > flexible), but wanted to check that this is the intentional. >=20 > > 3. > > I also note that that grouping doesn't require that any coordinates be > > specified at all. I presume that this is intentional, it makes sense > > to me (e.g., if it is intended to be optional). >=20 > My answer to a thread on the list asking for removal of some of the > mandatory designations which cause problems: >=20 > "The intention was for a location node to be required if the location> container was present. Apparently this will only work if > "container geo-lcoation" is a presence container. I'm not even sure that'= s > all that smart of a requirement (e.g., maybe someone just wants to > indicate the reference-frame for an object). I'll remove the mandatory > from location." [RW]=20 Okay. >=20 >=20 > > 4. In the YANG module, > > "v-east is the rate of change (i.e., speed) perpendicular > > to truth-north as defined by the geodetic-system."; > > > > As a nit, this doesn't actually define whether a positive v-east > > value is in the East or West direction. I appreciate that this is > > obvious, but for the other two components in the vector, it is > > unambiguously specified. >=20 > How about: >=20 > "v-east is the rate of change (i.e., speed) perpendicular > to the right of truth-north as defined by > the geodetic-system."; [RW]=20 LGTM. >=20 >=20 > > > > 5. > > In Security Considerations: > > > > Since the grouping defined in this module identifies locations, > > authors using this grouping SHOULD consider any privacy issues that > > may arise when the data is readable. > > > > Perhaps, expand this paragraph to give an example, e.g., revealing > > the physical location of a device, or data center. >=20 > How about: >=20 > "Since the grouping defined in this module identifies locations, > authors using this grouping SHOULD consider any privacy issues > that may arise when the data is readable (e.g., customer device > locations, etc)." [RW]=20 LGTM. >=20 >=20 > > > > The rest are just grammar nits: > > > > > > In addition to identifying the astronomical body we also need to > > define the meaning of the coordinates > > =3D> > > In addition to identifying the astronomical body, we also need to > > define the meaning of the coordinates >=20 > fixed >=20 > > > > In addition to the "geodetic-datum" value we allow refining the > > coordinate and height accuracy using "coord-accuracy" and "height- > > accuracy" respectively. > > =3D> > > In addition to the "geodetic-datum" value, we allow refinement of the > > coordinate and height accuracy using "coord-accuracy" and "height- > > accuracy" respectively. >=20 > fixed >=20 > > This is the location on or relative to the astronomical object. It > > is specified using 2 or 3 coordinates values. > > =3D> > > This is the location on, or relative to, the astronomical object. It > > is specified using 2 or 3 coordinates values. >=20 > fixed >=20 > > The intent of the grouping being defined here is to identify > > where something is located, and generally this is expected to be > > somewhere on or relative to Earth (or another astronomical body). > > =3D> > > The intent of the grouping being defined here is to identify > > where something is located, and generally this is expected to be > > somewhere on, or relative to, Earth (or another astronomical body). >=20 > fixed >=20 > > At > > least two options are available to YANG models that wish to use this > > grouping with objects that are changing location frequently in non- > > simple ways, they can add additional motion data to their model > > directly, or if the application allows it can require more frequent > > queries to keep the location data current. > > =3D> > > At > > least two options are available to YANG models that wish to use this > > grouping with objects that are changing location frequently in non- > > simple ways. They can add additional motion data to their model > > directly. Or, if the application allows, it can require more frequen= t > > queries to keep the location data current. >=20 > fixed >=20 > > When coord-accuracy is specified it overrides the geodetic-datum implie= d > > accuracy. > > =3D> > > When coord-accuracy is specified, it overrides the geodetic-datum > implied > > accuracy. >=20 > fixed >=20 > > > > When specified it overrides the geodetic-datum implied default. > > =3D> > > When specified, it overrides the geodetic-datum implied default. >=20 > fixed >=20 > > indicated by the reference-frame value. > > =3D> > > indicated by the reference-frame. >=20 > fixed >=20 > > For a formula to convert these values to speed and heading see > > this modules defining document RFC XXXX."; > > =3D> > > For a formula to convert these values to speed and heading see > > RFC XXXX."; >=20 > fixed >=20 > > You have "truth-north" and "truth north" and "true-north". Should > > these all be "true north"? >=20 > fixed >=20 > > > > YANG grouping using decimal64 values rather than strings. For the > > relative height cases the application doing the transformation is > > expected to have the data available to transform the relative height > > into an absolute height which can then be expressed using the YANG > > grouping. > > =3D> > > YANG grouping using decimal64 values rather than strings. For the > > relative height cases, the application doing the transformation is > > expected to have the data available to transform the relative height > > into an absolute height, which can then be expressed using the YANG > > grouping. >=20 > fixed >=20 > > Grammar Warnings (generated by a tool): > > Draft Text: > > Indeed it is easy to imagine a network or device located on The Moon, o= n > Mars, on Enceladus (the moon of Saturn) or even a comet (e.g., > 67p/churyumov-gerasimenko). > > > > Warning: Did you forget a comma after a conjunctive/linking adverb? > > Suggested change: "Indeed," >=20 > fixed >=20 > > > > Draft Text: > > This document defines a "geo-location" YANG grouping that allows for al= l > of the above data to be captured. > > > > Warning: Consider using all the. > > Suggested change: "all the" >=20 > fixed >=20 > > Draft Text: > > When specified these values override the defaults implied by the > "geodetic-datum" value. > > > > Warning: "When" at the beginning of a sentence usually requires a 2nd > clause. Maybe a comma, question or exclamation mark is missing, or the > sentence is incomplete and should be joined with the following sentence. > > Suggested change: "When specified, " >=20 > fixed >=20 > > Draft Text: > > In both choices the exact meanings of all of the values are defined by > the "geodetic-datum" value in the [xref]. > > > > Warning: Consider using all the. > > Suggested change: "all the" >=20 > fixed >=20 > > Draft Text: > > During the development of this module, the question of whether it would > support data such as orientation arose. > > Warning: Wordiness: Consider shortening this phrase. > > Suggested change: "whether" >=20 > ? [RW]=20 Ignore. >=20 > > > > Draft Text: > > For test "A.1.2.1" the YANG geo location object either includes a CRS > ("reference-frame") or has a default defined ([xref]). > > > > Warning: This word is normally spelled as one. > > Suggested change: "geolocation" >=20 > unchanged. >=20 > > Draft Text: > > Many systems make use of geo-location data, and so it's important to be > able describe this data using this geo-location object defined in this > document. > > > > Warning: The preposition 'to' is required in front of the verb > 'describe'. > > Suggested change: "able to describe" >=20 > Removed this paragraph it's unneeded and not very clear. >=20 > > > > Draft Text: > > For accuracy it has a single "u" parameter for specifying uncertainty. > > Warning: The comma is probably missing here: accuracy, it. > > Suggested change: "accuracy, it" >=20 > fixed >=20 > > Draft Text: > > This is used by many application (e.g., Google Maps API). > > > > Warning: Possible agreement error. The noun application seems to be > countable; consider using: many applications. > > Suggested change: "many applications" >=20 > fixed >=20 > > Draft Text: > > Thus GML "gml:pos" values can be mapped directly to the YANG grouping, > with the caveat that some loss of precision (in the extremes) may occur > due to the YANG grouping using decimal64 values rather than doubles. > > > > Warning: Did you forget a comma after a conjunctive/linking adverb? > > Suggested change: "Thus," >=20 > fixed >=20 > > Draft Text: > > Furthermore "gml:validTime" can either be an Instantaneous measure > ("gml:TimeInstant") or a time period ("gml:TimePeriod"). > > Warning: Did you forget a comma after a conjunctive/linking adverb? > > Suggested change: "Furthermore," >=20 > fixed >=20 > > Draft Text: > > As with the "kml:altitudeMode" value, the YANG grouping supports the > ignore case but not the relative case. > > > > Warning: After 'the', do not use a verb. Make sure that the spelling o= f > 'ignore' is correct. If 'ignore' is the first word in a compound > adjective, use a hyphen between the two words. Note: This error message > can occur if you use a verb as a noun, and the word is not a noun in > standard English. >=20 > I think it just wants me to hyphenate "ignore-case". "ignore" is an > adjective here "case" is the noun. *shrug*, I think it reads fine the way > it is for a technical document. [RW]=20 Yes, please just ignore. The tool isn't perfect. >=20 > > Draft Text: > > Thus the YANG grouping and KML values can be directly mapped in both > directions (when using a supported altitude mode) with the caveat that > some loss of precision (in the extremes) may occur due to the YANG > grouping using decimal64 values rather than strings. > > Warning: Did you forget a comma after a conjunctive/linking adverb? > > Suggested change: "Thus," >=20 > fixed >=20 > > Draft Text: > > The allocation policy for this registry is First Come First Served, > [xref] as the intent is simply to avoid duplicate values. > > > > Warning: It seems that a comma is missing. > > Suggested change: "Come," >=20 > fixed >=20 > > Draft Text: > > All of the data nodes defined in this YANG module are > writable/creatable/deletable (i.e., "config true", which is the default). > > Warning: Consider using all the. > > Suggested change: "All the" >=20 > fixed >=20 > > Draft Text: > > These are the subtrees and data nodes and their > sensitivity/vulnerability: > > None of the writable/creatable/deletable data nodes in the YANG module > defined in this document are by themselves considered more sensitive or > vulnerable then standard configuration. > > > > Warning: Did you mean than? > > Suggested change: "than" >=20 > fixed >=20 > > Draft Text: > > Some of the readable data nodes in this YANG module may be considered > sensitive or vulnerable in some network environments. > > Warning: If the text is a generality, 'of the' is not necessary. > > Suggested change: "Some" >=20 > I think it's correct to leave this, but I could be misunderstanding the > advice. [RW]=20 I think that either is probably fine/correct. >=20 > > Draft Text: > > Below is a the YANG tree for the fictitious module that uses the geo- > location grouping. > > > > Warning: Maybe you need to remove one determiner so that only a or the > is left. > > Suggested change: "a" >=20 > fixed with "the" only. >=20 > > > > Draft Text: > > We would also like to thank Peter Lothberg for the motivation as well a= s > help in defining a broadly useful geographic location object, and Acee > Lindem and Qin Wu for their work on a geographic location object that led > to this documents creation. > > > > Warning: Possible typo: apostrophe is missing. Did you mean documents' > or document's? > > Suggested change: "documents'" >=20 > fixed. >=20 > Nice tool! [RW]=20 Thanks. It needs a bit more time and work, but the hope is that it can be an easy w= ebtool that can be used by authors to help check the grammar/spelling in th= eir drafts. I don't want it to be an id-nits style gatekeeper tool, becaus= e as you have seen, some of the warnings/suggestions are somewhat arbitrary= . Also, the real credit goes to an open source grammar tool (dev.languaget= ool.org) that is doing all the heavy lifting. Thanks, Rob >=20 > Thanks, > Chris. >=20 >=20 > > > > Regards, > > Rob > > From nobody Tue Apr 13 04:43:52 2021 Return-Path: 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 26C2A3A116A; Tue, 13 Apr 2021 04:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=hq.sk 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 LQY23kYyUV5T; Tue, 13 Apr 2021 04:43:44 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF193A1166; Tue, 13 Apr 2021 04:43:44 -0700 (PDT) Received: from nitebug.nitenet.local (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 31F0A245135; Tue, 13 Apr 2021 13:43:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1618314219; bh=XwdX1JJxfjoOCwVXlWEens2Yu5qpa8AoJfYDK6hH5Fw=; h=To:References:From:Subject:Date:In-Reply-To; b=Y6cE2Xlcwnh6ziZ859s5XuFwL0JlFPnomWB3LRBgGNh4Aiqal8y6IluCEGnGaue2d j8E7/WqS5m+ZogOzMv2dtvzkffi3dTuds5EuRL2XZWzpXPIK2RmRW21tnCyy07Uf2I Pv/mYkqiUeykhlxawlpIm4C/CHKjQKKjCvDnJ0QU= To: =?UTF-8?Q?Michal_Va=c5=a1ko?= , Andy Bierman , "Eric Voit (evoit)" , netconf , netmod References: <52f2-606b1d80-d-7afd9d00@152658395> <87wntf3nca.fsf@nic.cz> From: Robert Varga Message-ID: <44da4ec9-da0e-ba39-eda1-b785b0f8d478@hq.sk> Date: Tue, 13 Apr 2021 13:43:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87wntf3nca.fsf@nic.cz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL" Archived-At: Subject: Re: [netmod] [netconf] YANG Push module errors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 11:43:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL Content-Type: multipart/mixed; boundary="0By5s5AUaQ2ivcKUEPiLh3fQvCht8151F"; protected-headers="v1" From: Robert Varga To: =?UTF-8?Q?Michal_Va=c5=a1ko?= , Andy Bierman , "Eric Voit (evoit)" , netconf , netmod Message-ID: <44da4ec9-da0e-ba39-eda1-b785b0f8d478@hq.sk> Subject: Re: [netmod] [netconf] YANG Push module errors References: <52f2-606b1d80-d-7afd9d00@152658395> <87wntf3nca.fsf@nic.cz> In-Reply-To: <87wntf3nca.fsf@nic.cz> --0By5s5AUaQ2ivcKUEPiLh3fQvCht8151F Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/04/2021 09:04, Ladislav Lhotka wrote: >> I see. Okay, thanks for the clarification and yes, if this was explici= tly mentioned in the RFC it would be great. Although, the validity of you= r example was not in question. Rather something like: >> >> container foo { >> if-feature X; >> container bar; >> } >> >> augment /foo/bar { >> container Y; >> } >> >> I am just going to assume this is what you meant and simply that the r= equirement is that any schema path must point to an existing schema node,= ignoring any "if-feature" statements. > I think it also depends on whether features are set before or after pro= cessing the modules. In the former case, an augment statement with an eff= ectively missing target node can IMO be silently ignored, without even pa= rsing its contents. This very case has been discussed here: https://mailarchive.ietf.org/arch/msg/netmod/Icd5c8J27P3UKjloNG8VC9fApoM/= FTR the original request for OpenDaylight lives here: https://jira.opendaylight.org/browse/YANGTOOLS-859 and it provides some additional context. As an implementation author, I certainly did not like the implications of the request, but Andy brought up a very important point in that thread= : > The modules are valid. > The conformance decision (i.e., which features are advertised and which= are > not by a server implementation) > does not change the compile-time validity of the YANG modules i.e. even if the YANG modules are being interpreted as part of assembling a server implementation, if-feature processing phase comes only after cross-statement relationships have been established and therefore the augment is valid, but 'container Y' disappears just as 'container bar' does. This is further reinforced by Martin's response in this (related) thread: https://mailarchive.ietf.org/arch/msg/netmod/9JgPZphOdim-wLZA3NrSe3I1un4/= Regards, Robert --0By5s5AUaQ2ivcKUEPiLh3fQvCht8151F-- --excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE9xJg9S8sgC+6qlK6U310SwoeP0UFAmB1g+oFAwAAAAAACgkQU310SwoeP0XJ 8xAAlwqTYFWd/JXqbx//UPLGE+/Q0OnFDbk+UVZAYQf7ZDVl8Chb87Ft9i87n+twQQbcFROCBT3O fYMVDHiM9Jm95pCc+gYwK3Nv5F0LFtqPcEd22C9H/ehc+5K/hu44KE+VBo4IpF0EKKML892gj8lK rL58Mo7MhBsu5a1O8SeWLsZWMa/e99pUU7Alkb1rzW7UisA3c6Vd2h9Z6crhzz+RBWQkuu898TAU DlXrAO5FWR34juRu6krh4hKBqj5xb5ylS/gTGcoj0rYFawLF7V/EPr7yPRsRR74m770NG1K2rXTR ndqIE/8hYojVJ4Y1Qn5oxd9MuBD6Y8Mlfcr8FBZEMkds9AOxFKqne1pU9D/ONUzulU7A/DENRjnY MM/FTBz6WFuwUB0M9GHMsNI5Hha/dPEC23r8PFGZKwDRxjhp7J9SIl+LlakB1v9vpajmCLFKZ726 622LoVr+CeAczLbPAneL8LyOiPozsVP4uqac6F0J3W3K/NhKDKc9KZRrcqsVivdBXhUrx2hwNHGx ThwRV/ebxyrKFwQ8FIA9tCwpYKfP9lFvOfUB9y7DDuZ6zY0AWKbrPPI1mbCz3pO08bOxIsTMefA+ lB8scvhmvp425WRqlyXk3NtsMIfDpZqSpPf4t7MzSjSGOnABBGGBsOhLDw613R4FUX/ehQCbQMtS n40= =HAPX -----END PGP SIGNATURE----- --excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL-- From nobody Tue Apr 13 07:12:25 2021 Return-Path: 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 3A24F3A18A0 for ; Tue, 13 Apr 2021 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 SH3frAmu7ROM for ; Tue, 13 Apr 2021 07:12:19 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2135.outbound.protection.outlook.com [40.107.220.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A8B3A189E for ; Tue, 13 Apr 2021 07:12:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YSi0mTVXMinPTbhfTzuUGI+3ZWmLr/6Bc83BvZQ83FwF2qRNVHXfDhznZWp/zbdcxVQdKQ2L1MKQTEShuirsAZU9MR3vozzxk1K1V3jbeJGg62rkTyD3GYH0Xhi1zYU7EpIWPd4chT+pAu3DAiPBiCs+gwR8koo7lM0TBo92VJWKKxJnf4uZbi4772IC+phcL3YwfW/UTjS0noQ8geOmbBgVCQ/j3tjHPV8llhKexJX9Ox6WzsW75G5Xfp+Lu7N184alZtq5+FIMZoh9zoag1ZkFRQP4TT6vGPOCwPqZhGPj4eUNhlGnw6qGlvVsEccdtPrF1bB8ZLZXeeqCUvw+nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fQFqOJZ7XMx5EU6Xc8xhNFBkM6SE6gRVVTv41U40jOs=; b=XUOTDhORBSihsYNqghW9Lvht/gmOkrmjpDlmoihDNT6T7hxzRdCTzyYGKVUfOgw/5VzNviyHA4/oZGJFuhlANEjNP5As5cKqUbS2HSlb6vM4rX6Q7IFxHgi+78Q11oUMp14AjiPiKNK32+HEWACdRFaAqw9FNl2wckLsko8aWeUpy0fpNrnds/zK6VYSd0+z0GonIBKjL4LLMh8OaamzYUKbHQ6Xrq0db90R4xOQDvhhR1+zTj4Q3gzXtTF4L93gnCngNylGaLIr9IUjYjzNVFOisWwF3fg8jSE3SIOnx+pDmR9v3NbciG4e3JY7feOxsR/U2PZtIKIDLI4LE1ApDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fQFqOJZ7XMx5EU6Xc8xhNFBkM6SE6gRVVTv41U40jOs=; b=naQqd/58US5CmY4fjyxyrJQkSLY9tm7h3vw5JLaSqOSookKZR0Hd6Gj8Lz0t3v8Bn85pCzNBK8xSSJo7qvu+kpWJa1rEHMZiPRAUVgwse9LapCm3cGULryw3LuFfznIJLfJR+31uZDfcjf8gARPbcKTa9fMVgJ1H1U0uc/x+Ld0= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4985.namprd08.prod.outlook.com (2603:10b6:5:48::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Tue, 13 Apr 2021 14:12:17 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4020.022; Tue, 13 Apr 2021 14:12:17 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-04-13 Thread-Index: AdcwbvJ73nHRwisWQiGZsVCuOZkrmg== Date: Tue, 13 Apr 2021 14:12:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ef0bf91-3a5d-4668-8856-08d8fe8624f9 x-ms-traffictypediagnostic: DM6PR08MB4985: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xpkF+pm5sHhwEngm8fNZny+2Xy7D+QqL1bmhueNTsF/Ok+FXrfLWy1z2FKXg9vpfAqCI3FJf8Xx/V0Tu2YlerH1WdoCbY4sxXpddcJK4sRf1/p6pNV0bOdIWbJy77Ap+MRoIUTgIvWYjXjIZUcVF7wvopjrIb+uF2SgVMflyqd58toh/7FkgObQ3R6cCa+gXWzQmHRdt1OTRpzkkYo7xvTEv/uKbcDEst8ukdWkuugAyDQ91PYLptKGVQ5GJj58Ucrn+d4v1hXaXSLKl/dbsNFcycojkOmhdq96mRRaYDIxofmF9JHLfS8AfE2rMBGx6JRbrLCZJaF3TtVfQDn+WF/iASUJSEXZGbTyvw0KreaJ/Ov1Xqdkzf7d9qnyyT4KF8VZ//npIuMWvMFqkNN3Z28aa8YiPiklB55CaJedYNJZLEAZ3euH4pjiKHpbw7b9RfAbQiAQNrABf183WUF5TT35IE3sgaA3NnXTjUA95k7r/8ond+8XRPehgMDrtOvi1t+m1vukvyqSUYs3mljJT/IJAFyFQBTmqe14X8gkUhiGFestbpuYCOQ4P1gee35hOVrTZoTEIMQIKZaSE6Lai6JCiOoFkZf9BOBqHS8p342P5EXXhfANmIiofqOQZMBXqSlSAlFCiswX/OgeGHTs9UhwBIhFEUtMVHF4Mhr5ZxrKYlT3WmSTQ4gK+m6e94WbC x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(16799955002)(66946007)(66556008)(64756008)(66446008)(966005)(86362001)(76116006)(498600001)(66476007)(5660300002)(7696005)(38100700002)(2906002)(52536014)(6916009)(6506007)(9686003)(8676002)(71200400001)(55016002)(186003)(26005)(33656002)(122000001)(8936002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?OhIjGnqfMf3G98pmskHApquF2lRJjJR96s51cbWwHAAAUBlrPHV32l3fdOzw?= =?us-ascii?Q?2vaNTVL6wIRyDaA6Nd/+HbLAOTXe+glPX2j9hJRyhzIC1t03WAz1plP71tWu?= =?us-ascii?Q?6Vw05+Ln1vlozwT51G37xL6ghzWTh01CK0RO3a1P10c7SZaRvG683BhJSHpV?= =?us-ascii?Q?yhQvYVOyXKG5WlrXOZWOUG1SkVFTQB7tsfNUbPNymwrHwllDUwWQdaKLgIcA?= =?us-ascii?Q?3RzC7P+O63u76k3hVNb5K73vvHt8vCmfS67NLHEIsPXIg5+tgZj6IDByujI5?= =?us-ascii?Q?fXatBME3d2yUGYgp9FGGIr/efQVZPil0p06GGZtRI799CUJ9tuzTXDvDeReg?= =?us-ascii?Q?3nhBubHibu36V8V0V5b0/ZkRaOJ8TtKoBpWhL/fEA1sjSTtT/tOyDrdE4oeW?= =?us-ascii?Q?UJ2jZa+uP8Ae3HqRH2rCexHoYWN9Sr5r6nB0wSPwllJVF6AG1qZ6sibIX6fl?= =?us-ascii?Q?mVO2r4/hQgmwY/8YpJQPUkjIe8kbb6keFuGHYb17wQQgMkKgyO1VMYhz/L7F?= =?us-ascii?Q?+/cQffUzzMTPiuI0mb6+K2mFKuuUU41U/7JZ2HxoGHypXDap833Ata8WFWFT?= =?us-ascii?Q?x8Ks/DPVOHwjwBZkrfZM7VMZHVDfzNyn0M4fopmBeseO8aAwrodreKzvLaEj?= =?us-ascii?Q?sFGVBmEglcKJlfQ2O3dqKb2Ww1KBxO1KH0+GzYo7M5BjG0/kFYSK1MgSw+su?= =?us-ascii?Q?cqvuP3a6EMfEDi3u0btg7hEqM5THyNF1scHyWVRDGVBpsAhYi4qCFJURLEEj?= =?us-ascii?Q?ojYJLOQK6eAfQhwwu2klMHgfq5uNWR2ITGPj8b0nrat8PBQqPtyMxAo7VZCe?= =?us-ascii?Q?qAA20IVXpWSpAGlnEixuXFP/udMrrxyLMh53XcJOMIDi0x35n/fiMMKRMXz8?= =?us-ascii?Q?akkPU0FrxOghlZ67y03kPsW5+qwFFTwbL2XSG8ZqPHYr6b6r4MMP5n2r7n+9?= =?us-ascii?Q?3/c7Z5uUYTVjVsi/KLqIXa4U9k5CHTPK/TKDBc0loqh0xFzjo4u7ZW/dxUWa?= =?us-ascii?Q?ijEYL9veHqeA3ExZZya5Jrr3no0FCF/ExMR9F0CWHwLBkcRVZ0mBkrHeCmfL?= =?us-ascii?Q?FL5aG9uwk40UdIQsupnNt617IY66+/4z42ofm042YrEvSE0ClRBgfv4iwF4p?= =?us-ascii?Q?I+LzerIhF2KTgkQMW4h5l0t9ONPhid7dUVp6g1tts7FrDG+apZ3MNaGhpMKo?= =?us-ascii?Q?OQBQ2L2mPT0JgLDwEubtLJzMdUSp4z9DmT5wKS+r9Fx90wbscgqUL7cFWWN/?= =?us-ascii?Q?lxa6Grchulh+0GIbKDu3z3h2hMk5FnNCuVlhD0nmRpKyrNAQqt3in+LLL8L9?= =?us-ascii?Q?Q2XKrHWXlvWLsa7N/t41g/ep?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB50847B2EED48E0C642ABE2249B4F9DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ef0bf91-3a5d-4668-8856-08d8fe8624f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 14:12:17.0442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /xql7bSFiXhhZr+onT6pw7lQRDdNjk0YCYB/Ywbu0deNVJX2CL5xC3Ky36xM3m14TvACa9hUynDQx6h9ZgAHMw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4985 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 14:12:24 -0000 --_000_DM6PR08MB50847B2EED48E0C642ABE2249B4F9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-04-13 Primary discussion was around the BC/NBC rules for state. Value space for config false: - more informative if you actually remove the enum from the model if it isn= 't used anymore (vs leaving it in and servers just not returning it) - a server implementation should deviate if it doesn't return something eve= r (schema should try to accurately define the API) - standard module -> remove the item if it isn't part of the API anymore - NMDA operational DS has a copy of config true, so increased value space i= n config automatically casues increased value space in "state" (operational= ) - a config true MTU in the operational DS and a dedicated config false "ope= r-mtu" leaf should have the same rules for increasing value space Maybe a better formulation of the state rules is to take the 7950 rules and= apply minimal text changes. Rob will take a stab at this. 7950: o A "must" statement may be removed or its constraint relaxed. Adjusted 7950 text: o A "must" statement may be added, removed, or changed 7950: o A "range", "length", or "pattern" statement may expand the allowed value space. Adjusted 7950: o A "range", "length", or "pattern" statement may expand or reduce the = allowed value space. Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB50847B2EED48E0C642ABE2249B4F9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-04-13

 

Primary discussion was around the BC/NBC rules for s= tate.

 

Value space for config false:

- more informative if you actually remove the enum f= rom the model if it isn't used anymore (vs leaving it in and servers just n= ot returning it)

- a server implementation should deviate if it doesn= 't return something ever (schema should try to accurately define the API)

- standard module -> remove the item if it isn't = part of the API anymore

- NMDA operational DS has a copy of config true, so = increased value space in config automatically casues increased value space = in "state" (operational)

- a config true MTU in the operational DS and a dedi= cated config false "oper-mtu" leaf should have the same rules for= increasing value space

 

Maybe a better formulation of the state rules is to = take the 7950 rules and apply minimal text changes. Rob will take a stab at= this.

 

7950:

   o  A "must" statement ma= y be removed or its constraint relaxed.

  

Adjusted 7950 text:

   o  A "must" statement ma= y be added, removed, or changed

 

 

7950:

   o  A "range", "leng= th", or "pattern" statement may expand the allowed

      value space.

Adjusted 7950:

   o  A "range", "leng= th", or "pattern" statement may expand or reduce the allowed=

      value space.

 

Jason

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

--_000_DM6PR08MB50847B2EED48E0C642ABE2249B4F9DM6PR08MB5084namp_-- From nobody Tue Apr 13 11:16:09 2021 Return-Path: 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 8D8563A21A7 for ; Tue, 13 Apr 2021 11:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 FOWdf4z-nwx0 for ; Tue, 13 Apr 2021 11:16:04 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 343D83A21A3 for ; Tue, 13 Apr 2021 11:16:04 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id o16so20435626ljp.3 for ; Tue, 13 Apr 2021 11:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1eYX964kkNzKk5wHTeLxKae+R8bdWRRuP+VGjppxO+k=; b=1vAu/3MRKz137is+ig15jLNn2J3VFOp3cW0aDqNuZ5AlytdX6U8KW4ZxXBo9d4QUuJ lGvsO8z9LIMCj5ZTmOMWVAK/pje2VSVgkYLiNF2gMsyrjhFLsBJDvXW02mUvXdfIZfU+ 42CNBJSQQYKmDn8xydN6iQKuHu9r6dW2RftcgF4LYqqq2mLUFo18py+wpw6yMFGxmJOq Y4S2j//X/z2AVn9z2izWLhnEygETQdU8gLvUjWXvC/OK3CiIcr0tqzqFsw4ZYOwm+e83 dG4U5eekGGbwUZQIJ9gP11+kKf14fxQ3qo++KncCPQN8uvZI1s1rg9fto6uo9nmZVaQd FOnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1eYX964kkNzKk5wHTeLxKae+R8bdWRRuP+VGjppxO+k=; b=W9n8+ehgLcDr8ZZCtvL679no7dPgeDFHtzHNuliGQsC1reYVsuxVmmzKsPsbISeA6H u+Af6q2VE5Obu8ERqB6aWVtfnCGLMw9BrLgbznljI0KFtiMe8EGU601HSCgQlm+OS2I9 cKVk8M/E7YZvnxn5X3gdf0b3S/JCpWRWDBUJL1AA9iwQbmQd8uY6+hUR8Vjfy79ZUmpt nyaifBUjNeppRAdEAVbwyiIEevCW1nf7RfaQ3hRwfAHVGvjQZlSWruTZd0JcHMOfMaF4 QC9wrSMlavEus6bB28oO3OYnaAXRCBKRIOgZFsoSRl8MLNpUY3xug9H8IFap1Q+wrm38 AuFg== X-Gm-Message-State: AOAM531WCVn+uVZbSWc8Apkp61eX0PRiAG4NisTa6X6UR0nKOfOvD7N/ fKRlgUR4Q8xevuxwYcDwEv4lx6yqlkMtum5Goz1rLQ== X-Google-Smtp-Source: ABdhPJzEKblLRxLF9CdNSjjPFUmnJbJp15+ADqRgyptDx0qYhoY/i1TirAPkx8DCSoQLqienLQudLOBN9Z7jyR1OjpY= X-Received: by 2002:a05:651c:1248:: with SMTP id h8mr9302342ljh.160.1618337761351; Tue, 13 Apr 2021 11:16:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 13 Apr 2021 11:15:50 -0700 Message-ID: To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000646b0605bfde9f04" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 18:16:09 -0000 --000000000000646b0605bfde9f04 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.sterne@nokia.com> wrote: > YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > Primary discussion was around the BC/NBC rules for state. > > > > Value space for config false: > > - more informative if you actually remove the enum from the model if it > isn't used anymore (vs leaving it in and servers just not returning it) > > - a server implementation should deviate if it doesn't return something > ever (schema should try to accurately define the API) > > - standard module -> remove the item if it isn't part of the API anymore > I assume you mean to use the status-stmt to transition from current -> deprecated -> obsolete in an orderly fashion. Especially since sec 11 is very clear: Obsolete definitions MUST NOT be removed from published modules, since their identifiers may still be referenced by other modules. - NMDA operational DS has a copy of config true, so increased value space > in config automatically casues increased value space in "state" > (operational) > > - a config true MTU in the operational DS and a dedicated config false > "oper-mtu" leaf should have the same rules for increasing value space > > > > Maybe a better formulation of the state rules is to take the 7950 rules > and apply minimal text changes. Rob will take a stab at this. > > > > 7950: > > o A "must" statement may be removed or its constraint relaxed. > > > > Adjusted 7950 text: > > o A "must" statement may be added, removed, or changed > > > > > 7950: > > o A "range", "length", or "pattern" statement may expand the allowed > > value space. > > Adjusted 7950: > > o A "range", "length", or "pattern" statement may expand or reduce the > allowed > > value space. > I strongly object to this WG creating an "adjusted YANG 1.1" standard. IMO there is no need or WG consensus to create any sort of replacement for RFC 7950. If YANG 1.1 needs non-backward-compatible changes (which it doesn't IMO) then a new YANG 2.0 RFC must be written to accomplish that. It is possible to introduce support for NBC changes in a way that does not change YANG 1.1 at all. E.g.: Rule 1 of 1: - If any change is made that violates a MUST or MUST NOT provision of RFC 7950, sec. 11, then the major revision number in the semver string MUST be incremented. > > Jason > Andy > > > ---------------------------------------------- > > Weekly webex call details: > > Meeting number (access code): 171 069 0374 > > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > > https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70 > > Tap to join from a mobile device (attendees only) > > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000646b0605bfde9f04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 13, 2021 at 7:12 AM Stern= e, Jason (Nokia - CA/Ottawa) <= jason.sterne@nokia.com> wrote:

YANG Versioning Weekly Call Minutes - 2021-04-13<= /u>

=C2=A0

Primary discussion was around the BC/NBC rules for s= tate.

=C2=A0

Value space for config false:

- more informative if you actually remove the enum f= rom the model if it isn't used anymore (vs leaving it in and servers ju= st not returning it)

- a server implementation should deviate if it doesn= 't return something ever (schema should try to accurately define the AP= I)

- standard module -> remove the item if it isn= 9;t part of the API anymore



I assume you mean to use the status-stmt to transition from= current -> deprecated -> obsolete
in an orderly fashion. E= specially since sec 11 is very clear:

   Obsolete definitions MUST NOT =
be removed from published modules,
   since their identifiers may still be referenced by other modules.



- NMDA operational DS has a copy of config true, so = increased value space in config automatically casues increased value space = in "state" (operational)

- a config true MTU in the operational DS and a dedi= cated config false "oper-mtu" leaf should have the same rules for= increasing value space

=C2=A0

Maybe a better formulation of the state rules is to = take the 7950 rules and apply minimal text changes. Rob will take a stab at= this.

=C2=A0

7950:

=C2=A0=C2=A0 o=C2=A0 A "must" statement ma= y be removed or its constraint relaxed.

=C2=A0=C2=A0

Adjusted 7950 text:

=C2=A0=C2=A0 o=C2=A0 A "must" statement ma= y be added, removed, or changed

=C2=A0=C2=A0

=C2=A0

7950:

=C2=A0=C2=A0 o=C2=A0 A "range", "leng= th", or "pattern" statement may expand the allowed=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value space.

Adjusted 7950:

=C2=A0=C2=A0 o=C2=A0 A "range", "leng= th", or "pattern" statement may expand or reduce the allowed=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value space.



I strongly object to= this WG creating an "adjusted YANG 1.1" standard.
IMO = there is no need or WG consensus to create any sort of replacement for RFC = 7950.

If YANG 1.1 needs non-backward-compatible ch= anges=C2=A0 (which it doesn't IMO) then a new
YANG 2.0 RFC mu= st be written to accomplish that.

It is possible t= o introduce support for NBC changes in a way that does not change YANG 1.1<= /div>
at all. E.g.:

Rule 1 of 1:
=C2= =A0 - If any change is made that violates a MUST or MUST NOT provision of R= FC 7950,
=C2=A0 =C2=A0 sec. 11, then the major revision number in= the semver string MUST be incremented.


=

=C2=A0

Jason


Andy
=C2=A0

<= /u>

=C2=A0

----------------------------------------------

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am=C2=A0 |=C2=A0 (UTC-04:00) Eastern Time (US &= amp; Canada)=C2=A0 |=C2=A0 1 hr

https://ietf.webex.com= /ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)=

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000646b0605bfde9f04-- From nobody Tue Apr 13 11:30:34 2021 Return-Path: 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 EB8EC3A225D for ; Tue, 13 Apr 2021 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 jS6oTZ87gbo4 for ; Tue, 13 Apr 2021 11:30:27 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2129.outbound.protection.outlook.com [40.107.223.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B899C3A225B for ; Tue, 13 Apr 2021 11:30:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LVK9+cuZ9ufw4kSR+YuMaXAWsBX7LnOfTkMTgkknQBy2H9hafmha+xWLRuziuoSxvOVqTIbfHeVkzVpZUMQx5Rz/kRKERDvfTxkoWr7AQg3nuirI4IqW0PHdKxZGyTEkhFP3AmylhN4eQJnZj5b6xJ9cqFDZa4Pb3VeR9O+uYsfQ3h9eESzqXsLW8wxd/KQkRo57f11DLOWDlGT6th8XllDNr0K0iHPe4B184w6JsUKNmd3Q7z0pbirfTW7+3vEqy1yiaDtOVj0lG9W4TNtzpoMEb8UTuEbLLpoYlHSmscxvAcG05M0pAtmPoKcidAiSNFZnXLDG2MztoU9ho2f89g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=93LuRGiVLsF3DuoUhqfF3yTfPmfGQ5Mq11uN9nIiwks=; b=L4oTDEya+5N6ke4euuC6nH3CSWCb/9hosls/NXbir3ol9OMKpmiIgDLKNK+NpnO6o0SPtS+frzWwBbMknPPwxqVA3um03Cjr3sw+hesSVdVtnh7+kUpoBKRYa97as/reU+tsmInFGhZHDUDS3yrRprWICOfMit6I8DbYbb86RDj70IpnGo4Q3YqbAyDaczk+FqDa5aYX/5r4KD9QVS8XlmYd+2zirONZ553vBr/0vgyyeZQy0F/eQOP2UjTdkPRR/8gIyLxAsHoX8K9ICvNPLB1399bqCVTNg2yDseA/v9d4Panxmc2OkfliARtv1xH3b0GokaTkCndeokn99uV/Kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=93LuRGiVLsF3DuoUhqfF3yTfPmfGQ5Mq11uN9nIiwks=; b=njMU7DrrbdgKqoKuRfiQ5qQalARYLlYxagwWkMhUzXzDwrf3NveC9xxb+pMUztCA29ihRweyYWRrA8kv9VVVNKjDR589/hkjPxJzMCrZa+FLkOFu/X1SjEX11LBsrURRNy2Smn+mGCmm6daeA9l6N4pgcIb6+RSD/KH4jYmYYWY= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5353.namprd08.prod.outlook.com (2603:10b6:5:10::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Tue, 13 Apr 2021 18:30:25 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4020.022; Tue, 13 Apr 2021 18:30:25 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 Thread-Index: AdcwbvJ73nHRwisWQiGZsVCuOZkrmgAIhXoAAABXCrA= Date: Tue, 13 Apr 2021 18:30:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c8d61dd-229e-4c07-5346-08d8feaa34ec x-ms-traffictypediagnostic: DM6PR08MB5353: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: huBOMTNtR8l3MEfxfzEmXS70WAyIuTe7kfgz6KiQXGD8LON9vtMXxPoIfD4GsuvmgXDDcJ3FKPddHrPAB+Eew6DLLCH1+It41NPU6qVI9bFv3CyEj3NKw78VwDCsHoY4F1ULtf8+b4FcKrPKowUoP7sYqBnX0Aw8JYouAMq8z1lWmgeuV89n+GwLVFqkySNbIrX0CISvI0aNX0730pJxAUOG47fXRRCA/vkMY8eNoZRcZVFT37LHN05hTKyXCIN6TpQFR/GyZ9o0uAxSgWmCCgRlE29J3zVIUYTdSsBC4na1cxERBx1Tdp5Wtg4zAZGJFnJze9LDpSXXC86iJrPXHHJ3Y8lDTD65OdCDEspuo7n1JhgO9WMJB2r//KgqSXngS78IHh9Bal0b48LuAbMMITrGd7YYYpQWgO4OsJPsIdtHxnju9HYrezNXkpI0PDgbjRjAdX8m0hCS7Cf+Y9fxJEhmx5mnwr7RGUc6l+ENyA0DDGQyk74nzNGBcRXAFRx4BZx7TEIW2IZJXef6QiwadbDDgP82owiiddQg5cnarSFEoLfCAMHzTpaZsg6RTt60lGqGY3olhHHL2a3psT5W7B8b7VxmucgVwViAjIMHlozl+VSez2nUGu6Jzz/4WE0/OG6SAKEnShCgMzVHDa2nbyiaF3/D/pAp2KFgn+r3rg6hJp7Z6pftLod9xR+18lbm x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39850400004)(396003)(346002)(376002)(166002)(316002)(83380400001)(8676002)(86362001)(2906002)(33656002)(478600001)(6916009)(55016002)(26005)(5660300002)(6506007)(8936002)(52536014)(4326008)(66476007)(64756008)(66446008)(66556008)(9326002)(76116006)(16799955002)(966005)(7696005)(122000001)(53546011)(9686003)(71200400001)(186003)(38100700002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?OWxQUTBZVHU4U0Faem1LMVBDc1p2UGNFZE1YZC9zVHJBU2ZsWGZjcGhCWkQ4?= =?utf-8?B?TnlaSUZiWUJyWDBBd1FIdzFsMVNlakhYcGNhTGFyUDgrQ1gzZlVldTVWb3Ey?= =?utf-8?B?WEFteVVOb2RvRnY3eS82Yk1VOWRKWi85QlVRNC93M1AySi9VdFJCMldBYW5Q?= =?utf-8?B?UjdVS3R3dlhCYXNVYlpnYU16N2lPV3hIT1Ryb1ZBR0l2bzllYkRmSnM3TkJw?= =?utf-8?B?SW9zWEJzOWduRzJLeGdTL3E1U3BYdE81TzQ1dmpSMGxiTU5nMHNOUkZiei9Q?= =?utf-8?B?YXBRN21SYzBLMU42Ui9nSlRIS3hIODI0QkpuUVMzNHhnbEI3a3VNYThZNGVn?= =?utf-8?B?R2lDSWxSL0p5TGJBOENnU1VlOVo3elVVd0ZUbWdtVHFuaEdud3NxSVIwUDFy?= =?utf-8?B?Y3hMdktQd25vMXFqcWxSdWk2NkJXYmV4aTIrcDJjejlSVG44UFROTnhKQTZk?= =?utf-8?B?WExKZzVOeWxBaVpSTkd0ZkZkNEFjUVNlVWwrS3ZFRlZkRk9sbHYxaEo1OE1I?= =?utf-8?B?SkFrb2tReEJkMFN4UDVYWEFhaUZUMkNZV2d1bEZKQkl6emVSNzk5cFIxeFJw?= =?utf-8?B?WVRzaVVLVU9tUnBNRTkzSXVSbjArYWUveFZuQm85SkdqNjZ3R2dnVDVoOXVs?= =?utf-8?B?Ky9OaWpoUUJ3eDJPMERkdkRkRDNOVHBURXZ6Z2ZNd04wbXYvL2krdm9ObVpN?= =?utf-8?B?cHQ5RzQyc0N2VS9vb0RCYTdmR1h6R3BUMnR0STBIM043WW5HZDByU2QxWHha?= =?utf-8?B?TVY0Y2R1YmxnSExPUmRHNkszQzU1d2lMU3BUVHFFUG1uaTlLM1cwQzlVSDVh?= =?utf-8?B?M2dwRUdxSkpkTGlBcDFFWDhyWmFLdlk0VTJLS095MWwvb1B3eHM2S29EU0Rl?= =?utf-8?B?cURDbDA4WmMwc2RyZUlxcW5ub0t2eGhkaWJaWVFEbjNBa09jc2lXdDRKbzZ2?= =?utf-8?B?QzhCVjdoSEZEeGNvSUpZWHJHS1pkS01nT3lpMGF3YjNqbVlqWHdDWFFHTjJC?= =?utf-8?B?b2RDOUVNZko4U0I4NUhPMC9SZ1pKaVZQSXNLKzJUTSsyU2FCRWZaNWFiNkR2?= =?utf-8?B?VjVleURmWE9kczFPNVpRTzNhNGhINHYxUHdEcW9HRlE0SW41NnBmSVd2bTkx?= =?utf-8?B?S2JJR05xc0wxQy9RTzhDSWJPMTBEeXRhMU5kcnpPdGR0Z0tEcEFRbzZGemR6?= =?utf-8?B?ZnJ1WTJZTUVzM3JxVFhNQjlCbXQ1MDN5aE9ERWJPVUJYK0s0QmhzTEgvYnd3?= =?utf-8?B?ZkVpTzRRMFpmUmhIeDZyRzIwYktvZ3NaTzZoS2NPZlZRVG5rNmVsS21mRkpU?= =?utf-8?B?WEV1MGpsUTJaWElKUk5SZzBiUnJZeEFoN2w5c1hheDlZWFRSa0lWQlc1Tlg4?= =?utf-8?B?bTJtTmFtZ3MvNGZJemJ4bGwrSWRVUkdkUjQzZ0dNeElrZUtVYnhGTUFEeXpG?= =?utf-8?B?dGhPNlg2ZGQrMzZueWZJdXNKT3RqS2ZBSFIvQVgyZHVWS2cvUFZuV1Q2cUZI?= =?utf-8?B?N3pYZ0cxWVdNVWFvUnhoOWExQmd2aUc2UHNJeGxRRDhLU0doNzVZaTJNR0xT?= =?utf-8?B?T3p6Y2podEg4WS8rdHhMT3NDdHRpc2p5bU4ra3Z4TUtyaTFDd0JjcGVCZW9U?= =?utf-8?B?UFJaYjJhKzhqTVErOElHVi93RUpaYTZ2TFptSlVyVlZDN3c0amlyejVzOGpT?= =?utf-8?B?aklOZTIxekZGRWIzNlhKSERvQUdMeXMzdmxVdmFhRVN5Mmt0b3ZQZmVoZXZi?= =?utf-8?Q?2bjWmfssDwCe4raoP9E0Z3RRdTEVnO4Yl0NG9yH?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084B9510E2EE76F9D7A4D299B4F9DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c8d61dd-229e-4c07-5346-08d8feaa34ec X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 18:30:25.7374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JeKF+QDBX1UN1k/ZDbAnnokOmh+v4wuqLSk/bQ7sSHsyO4b33UcTz+pQmlk6KKve+L+BWhy1qjQQkwtOZvHacg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5353 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 18:30:33 -0000 --_000_DM6PR08MB5084B9510E2EE76F9D7A4D299B4F9DM6PR08MB5084namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGh4IGZvciB0YWtpbmcgYSBsb29rLg0KDQpZZXMgLSBhZ3JlZSB3aXRoIHRo ZSAib3JkZXJseSIgY29tbWVudC4gVGhhdCB3YXMgdmVyeSBicmllZiBzaG9ydGhhbmQgZm9yIHRo ZSBtaW51dGVzLiBCeSAicmVtb3ZlIiBpdCBjb3VsZCBldmVuIGp1c3QgbWVhbiBtYXJraW5nIGFz ICJvYnNvbGV0ZSIgKHdpdGggZGVwcmVjYXRlZCBhcyBhbiBvcHRpb25hbCBpbnRlcm1lZGlhdGUg c3RlcCkuDQoNCldlIGFyZW4ndCB0cnlpbmcgdG8gcmVkZWZpbmUgdGhlIHJ1bGVzIGZvciBjb25m aWcuIEJ1dCBpdCBpcyB3b3J0aCBjb25zaWRlcmluZyB3aGV0aGVyIHNvbWUgb2YgdGhvc2UgYXJl bid0IHJlYWxseSBnb29kIGZvciBzdGF0ZS4gIEltcGxlbWVudGF0aW9ucyBtYXkgYmUgaWdub3Jp bmcgc29tZSBvZiB0aG9zZSBydWxlcyBmb3Igc3RhdGUgYmVjYXVzZSB0aGV5IGRvbid0IHJlYWxs eSBmaXQuDQoNCkphc29uDQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t Pg0KU2VudDogVHVlc2RheSwgQXByaWwgMTMsIDIwMjEgMjoxNiBQTQ0KVG86IFN0ZXJuZSwgSmFz b24gKE5va2lhIC0gQ0EvT3R0YXdhKSA8amFzb24uc3Rlcm5lQG5va2lhLmNvbT4NCkNjOiBuZXRt b2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBZQU5HIFZlcnNpb25pbmcgV2Vla2x5 IENhbGwgTWludXRlcyAtIDIwMjEtMDQtMTMNCg0KDQoNCk9uIFR1ZSwgQXByIDEzLCAyMDIxIGF0 IDc6MTIgQU0gU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpIDxqYXNvbi5zdGVybmVA bm9raWEuY29tPG1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tPj4gd3JvdGU6DQpZQU5HIFZl cnNpb25pbmcgV2Vla2x5IENhbGwgTWludXRlcyAtIDIwMjEtMDQtMTMNCg0KUHJpbWFyeSBkaXNj dXNzaW9uIHdhcyBhcm91bmQgdGhlIEJDL05CQyBydWxlcyBmb3Igc3RhdGUuDQoNClZhbHVlIHNw YWNlIGZvciBjb25maWcgZmFsc2U6DQotIG1vcmUgaW5mb3JtYXRpdmUgaWYgeW91IGFjdHVhbGx5 IHJlbW92ZSB0aGUgZW51bSBmcm9tIHRoZSBtb2RlbCBpZiBpdCBpc24ndCB1c2VkIGFueW1vcmUg KHZzIGxlYXZpbmcgaXQgaW4gYW5kIHNlcnZlcnMganVzdCBub3QgcmV0dXJuaW5nIGl0KQ0KLSBh IHNlcnZlciBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZGV2aWF0ZSBpZiBpdCBkb2Vzbid0IHJldHVy biBzb21ldGhpbmcgZXZlciAoc2NoZW1hIHNob3VsZCB0cnkgdG8gYWNjdXJhdGVseSBkZWZpbmUg dGhlIEFQSSkNCi0gc3RhbmRhcmQgbW9kdWxlIC0+IHJlbW92ZSB0aGUgaXRlbSBpZiBpdCBpc24n dCBwYXJ0IG9mIHRoZSBBUEkgYW55bW9yZQ0KDQoNCkkgYXNzdW1lIHlvdSBtZWFuIHRvIHVzZSB0 aGUgc3RhdHVzLXN0bXQgdG8gdHJhbnNpdGlvbiBmcm9tIGN1cnJlbnQgLT4gZGVwcmVjYXRlZCAt PiBvYnNvbGV0ZQ0KaW4gYW4gb3JkZXJseSBmYXNoaW9uLiBFc3BlY2lhbGx5IHNpbmNlIHNlYyAx MSBpcyB2ZXJ5IGNsZWFyOg0KDQoNCiAgIE9ic29sZXRlIGRlZmluaXRpb25zIE1VU1QgTk9UIGJl IHJlbW92ZWQgZnJvbSBwdWJsaXNoZWQgbW9kdWxlcywNCg0KICAgc2luY2UgdGhlaXIgaWRlbnRp ZmllcnMgbWF5IHN0aWxsIGJlIHJlZmVyZW5jZWQgYnkgb3RoZXIgbW9kdWxlcy4NCg0KDQoNCi0g Tk1EQSBvcGVyYXRpb25hbCBEUyBoYXMgYSBjb3B5IG9mIGNvbmZpZyB0cnVlLCBzbyBpbmNyZWFz ZWQgdmFsdWUgc3BhY2UgaW4gY29uZmlnIGF1dG9tYXRpY2FsbHkgY2FzdWVzIGluY3JlYXNlZCB2 YWx1ZSBzcGFjZSBpbiAic3RhdGUiIChvcGVyYXRpb25hbCkNCi0gYSBjb25maWcgdHJ1ZSBNVFUg aW4gdGhlIG9wZXJhdGlvbmFsIERTIGFuZCBhIGRlZGljYXRlZCBjb25maWcgZmFsc2UgIm9wZXIt bXR1IiBsZWFmIHNob3VsZCBoYXZlIHRoZSBzYW1lIHJ1bGVzIGZvciBpbmNyZWFzaW5nIHZhbHVl IHNwYWNlDQoNCk1heWJlIGEgYmV0dGVyIGZvcm11bGF0aW9uIG9mIHRoZSBzdGF0ZSBydWxlcyBp cyB0byB0YWtlIHRoZSA3OTUwIHJ1bGVzIGFuZCBhcHBseSBtaW5pbWFsIHRleHQgY2hhbmdlcy4g Um9iIHdpbGwgdGFrZSBhIHN0YWIgYXQgdGhpcy4NCg0KNzk1MDoNCiAgIG8gIEEgIm11c3QiIHN0 YXRlbWVudCBtYXkgYmUgcmVtb3ZlZCBvciBpdHMgY29uc3RyYWludCByZWxheGVkLg0KDQpBZGp1 c3RlZCA3OTUwIHRleHQ6DQogICBvICBBICJtdXN0IiBzdGF0ZW1lbnQgbWF5IGJlIGFkZGVkLCBy ZW1vdmVkLCBvciBjaGFuZ2VkDQoNCg0KNzk1MDoNCiAgIG8gIEEgInJhbmdlIiwgImxlbmd0aCIs IG9yICJwYXR0ZXJuIiBzdGF0ZW1lbnQgbWF5IGV4cGFuZCB0aGUgYWxsb3dlZA0KICAgICAgdmFs dWUgc3BhY2UuDQpBZGp1c3RlZCA3OTUwOg0KICAgbyAgQSAicmFuZ2UiLCAibGVuZ3RoIiwgb3Ig InBhdHRlcm4iIHN0YXRlbWVudCBtYXkgZXhwYW5kIG9yIHJlZHVjZSB0aGUgYWxsb3dlZA0KICAg ICAgdmFsdWUgc3BhY2UuDQoNCg0KSSBzdHJvbmdseSBvYmplY3QgdG8gdGhpcyBXRyBjcmVhdGlu ZyBhbiAiYWRqdXN0ZWQgWUFORyAxLjEiIHN0YW5kYXJkLg0KSU1PIHRoZXJlIGlzIG5vIG5lZWQg b3IgV0cgY29uc2Vuc3VzIHRvIGNyZWF0ZSBhbnkgc29ydCBvZiByZXBsYWNlbWVudCBmb3IgUkZD IDc5NTAuDQoNCklmIFlBTkcgMS4xIG5lZWRzIG5vbi1iYWNrd2FyZC1jb21wYXRpYmxlIGNoYW5n ZXMgICh3aGljaCBpdCBkb2Vzbid0IElNTykgdGhlbiBhIG5ldw0KWUFORyAyLjAgUkZDIG11c3Qg YmUgd3JpdHRlbiB0byBhY2NvbXBsaXNoIHRoYXQuDQoNCkl0IGlzIHBvc3NpYmxlIHRvIGludHJv ZHVjZSBzdXBwb3J0IGZvciBOQkMgY2hhbmdlcyBpbiBhIHdheSB0aGF0IGRvZXMgbm90IGNoYW5n ZSBZQU5HIDEuMQ0KYXQgYWxsLiBFLmcuOg0KDQpSdWxlIDEgb2YgMToNCiAgLSBJZiBhbnkgY2hh bmdlIGlzIG1hZGUgdGhhdCB2aW9sYXRlcyBhIE1VU1Qgb3IgTVVTVCBOT1QgcHJvdmlzaW9uIG9m IFJGQyA3OTUwLA0KICAgIHNlYy4gMTEsIHRoZW4gdGhlIG1ham9yIHJldmlzaW9uIG51bWJlciBp biB0aGUgc2VtdmVyIHN0cmluZyBNVVNUIGJlIGluY3JlbWVudGVkLg0KDQoNCg0KDQpKYXNvbg0K DQpBbmR5DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KV2Vla2x5IHdlYmV4IGNhbGwgZGV0YWlsczoNCk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29k ZSk6IDE3MSAwNjkgMDM3NA0KTWVldGluZyBwYXNzd29yZDogc2VtdmVyPw0KT2NjdXJzIGV2ZXJ5 IFR1ZXNkYXkgZWZmZWN0aXZlIFR1ZXNkYXksIFNlcHRlbWJlciAxLCAyMDIwIHVudGlsIFR1ZXNk YXksIEF1Z3VzdCAyNCwgMjAyMSBmcm9tIDk6MDAgQU0gdG8gMTA6MDAgQU0sIChVVEMtMDQ6MDAp IEVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpDQo5OjAwIGFtICB8ICAoVVRDLTA0OjAwKSBFYXN0 ZXJuIFRpbWUgKFVTICYgQ2FuYWRhKSAgfCAgMSBocg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWE3NjI3YTJhZTdiNzcwNTM3Y2ZmNWY1Yjg5MjkzYzcwDQpUYXAgdG8g am9pbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9ubHkpDQorMS02NTAtNDc5LTMy MDgsLDE3MTA2OTAzNzQjIyBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcg bGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K --_000_DM6PR08MB5084B9510E2EE76F9D7A4D299B4F9DM6PR08MB5084namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1DQTt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaHggZm9yIHRha2luZyBhIGxvb2su PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlllcyAtIGFncmVlIHdpdGggdGhlICZxdW90O29yZGVybHkmcXVvdDsgY29tbWVudC4g VGhhdCB3YXMgdmVyeSBicmllZiBzaG9ydGhhbmQgZm9yIHRoZSBtaW51dGVzLiBCeSAmcXVvdDty ZW1vdmUmcXVvdDsgaXQgY291bGQgZXZlbiBqdXN0IG1lYW4gbWFya2luZyBhcyAmcXVvdDtvYnNv bGV0ZSZxdW90OyAod2l0aCBkZXByZWNhdGVkIGFzIGFuIG9wdGlvbmFsIGludGVybWVkaWF0ZSBz dGVwKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+V2UgYXJlbid0IHRyeWluZyB0byByZWRlZmluZSB0aGUgcnVsZXMgZm9yIGNv bmZpZy4gQnV0IGl0IGlzIHdvcnRoIGNvbnNpZGVyaW5nIHdoZXRoZXIgc29tZSBvZiB0aG9zZSBh cmVuJ3QgcmVhbGx5IGdvb2QgZm9yIHN0YXRlLiZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgbWF5IGJl IGlnbm9yaW5nIHNvbWUgb2YgdGhvc2UgcnVsZXMgZm9yIHN0YXRlIGJlY2F1c2UNCiB0aGV5IGRv bid0IHJlYWxseSBmaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkphc29uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5k eSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgQXByaWwgMTMsIDIwMjEgMjoxNiBQTTxicj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBK YXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDtqYXNvbi5zdGVybmVAbm9raWEuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb bmV0bW9kXSBZQU5HIFZlcnNpb25pbmcgV2Vla2x5IENhbGwgTWludXRlcyAtIDIwMjEtMDQtMTM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBBcHIgMTMsIDIwMjEgYXQgNzoxMiBBTSBTdGVybmUsIEphc29uIChOb2tpYSAtIENB L090dGF3YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tIj5qYXNv bi5zdGVybmVAbm9raWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllBTkcgVmVyc2lvbmluZyBXZWVrbHkgQ2Fs bCBNaW51dGVzIC0gMjAyMS0wNC0xMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UHJpbWFy eSBkaXNjdXNzaW9uIHdhcyBhcm91bmQgdGhlIEJDL05CQyBydWxlcyBmb3Igc3RhdGUuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5WYWx1ZSBzcGFjZSBmb3IgY29uZmlnIGZhbHNlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIG1vcmUgaW5mb3JtYXRpdmUgaWYg eW91IGFjdHVhbGx5IHJlbW92ZSB0aGUgZW51bSBmcm9tIHRoZSBtb2RlbCBpZiBpdCBpc24ndCB1 c2VkIGFueW1vcmUgKHZzIGxlYXZpbmcgaXQgaW4gYW5kIHNlcnZlcnMganVzdCBub3QgcmV0dXJu aW5nIGl0KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIGEgc2VydmVy IGltcGxlbWVudGF0aW9uIHNob3VsZCBkZXZpYXRlIGlmIGl0IGRvZXNuJ3QgcmV0dXJuIHNvbWV0 aGluZyBldmVyIChzY2hlbWEgc2hvdWxkIHRyeSB0byBhY2N1cmF0ZWx5IGRlZmluZSB0aGUgQVBJ KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHN0YW5kYXJkIG1vZHVs ZSAtJmd0OyByZW1vdmUgdGhlIGl0ZW0gaWYgaXQgaXNuJ3QgcGFydCBvZiB0aGUgQVBJIGFueW1v cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYXNzdW1lIHlvdSBtZWFuIHRvIHVzZSB0aGUgc3Rh dHVzLXN0bXQgdG8gdHJhbnNpdGlvbiBmcm9tIGN1cnJlbnQgLSZndDsgZGVwcmVjYXRlZCAtJmd0 OyBvYnNvbGV0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+aW4gYW4gb3JkZXJseSBmYXNoaW9uLiBFc3BlY2lhbGx5IHNpbmNlIHNlYyAxMSBpcyB2 ZXJ5IGNsZWFyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJi cmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg T2Jzb2xldGUgZGVmaW5pdGlvbnMgTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIHB1Ymxpc2hlZCBt b2R1bGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBzaW5jZSB0aGVpciBpZGVudGlmaWVycyBtYXkgc3RpbGwgYmUg cmVmZXJlbmNlZCBieSBvdGhlciBtb2R1bGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIE5NREEgb3BlcmF0aW9uYWwgRFMgaGFzIGEgY29w eSBvZiBjb25maWcgdHJ1ZSwgc28gaW5jcmVhc2VkIHZhbHVlIHNwYWNlIGluIGNvbmZpZyBhdXRv bWF0aWNhbGx5IGNhc3VlcyBpbmNyZWFzZWQgdmFsdWUgc3BhY2UgaW4gJnF1b3Q7c3RhdGUmcXVv dDsgKG9wZXJhdGlvbmFsKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t IGEgY29uZmlnIHRydWUgTVRVIGluIHRoZSBvcGVyYXRpb25hbCBEUyBhbmQgYSBkZWRpY2F0ZWQg Y29uZmlnIGZhbHNlICZxdW90O29wZXItbXR1JnF1b3Q7IGxlYWYgc2hvdWxkIGhhdmUgdGhlIHNh bWUgcnVsZXMgZm9yIGluY3JlYXNpbmcgdmFsdWUgc3BhY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk1heWJlIGEgYmV0dGVyIGZvcm11bGF0aW9uIG9mIHRoZSBzdGF0ZSBydWxlcyBpcyB0 byB0YWtlIHRoZSA3OTUwIHJ1bGVzIGFuZCBhcHBseSBtaW5pbWFsIHRleHQgY2hhbmdlcy4gUm9i IHdpbGwgdGFrZSBhIHN0YWIgYXQgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjc5 NTA6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBv Jm5ic3A7IEEgJnF1b3Q7bXVzdCZxdW90OyBzdGF0ZW1lbnQgbWF5IGJlIHJlbW92ZWQgb3IgaXRz IGNvbnN0cmFpbnQgcmVsYXhlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QWRqdXN0ZWQgNzk1MCB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBICZxdW90O211c3QmcXVvdDsgc3RhdGVtZW50IG1heSBi ZSBhZGRlZCwgcmVtb3ZlZCwgb3IgY2hhbmdlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Nzk1MDo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSAmcXVvdDtyYW5nZSZx dW90OywgJnF1b3Q7bGVuZ3RoJnF1b3Q7LCBvciAmcXVvdDtwYXR0ZXJuJnF1b3Q7IHN0YXRlbWVu dCBtYXkgZXhwYW5kIHRoZSBhbGxvd2VkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSBzcGFjZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWRqdXN0ZWQgNzk1MDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSAmcXVv dDtyYW5nZSZxdW90OywgJnF1b3Q7bGVuZ3RoJnF1b3Q7LCBvciAmcXVvdDtwYXR0ZXJuJnF1b3Q7 IHN0YXRlbWVudCBtYXkgZXhwYW5kIG9yIHJlZHVjZSB0aGUgYWxsb3dlZDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dmFsdWUgc3BhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0cm9uZ2x5IG9iamVjdCB0byB0 aGlzIFdHIGNyZWF0aW5nIGFuICZxdW90O2FkanVzdGVkIFlBTkcgMS4xJnF1b3Q7IHN0YW5kYXJk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1P IHRoZXJlIGlzIG5vIG5lZWQgb3IgV0cgY29uc2Vuc3VzIHRvIGNyZWF0ZSBhbnkgc29ydCBvZiBy ZXBsYWNlbWVudCBmb3IgUkZDIDc5NTAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIFlBTkcgMS4xIG5lZWRzIG5vbi1iYWNrd2FyZC1jb21w YXRpYmxlIGNoYW5nZXMmbmJzcDsgKHdoaWNoIGl0IGRvZXNuJ3QgSU1PKSB0aGVuIGEgbmV3PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZQU5HIDIu MCBSRkMgbXVzdCBiZSB3cml0dGVuIHRvIGFjY29tcGxpc2ggdGhhdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgcG9zc2libGUgdG8g aW50cm9kdWNlIHN1cHBvcnQgZm9yIE5CQyBjaGFuZ2VzIGluIGEgd2F5IHRoYXQgZG9lcyBub3Qg Y2hhbmdlIFlBTkcgMS4xPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5hdCBhbGwuIEUuZy46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJ1bGUgMSBvZiAxOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gSWYgYW55IGNoYW5nZSBpcyBt YWRlIHRoYXQgdmlvbGF0ZXMgYSBNVVNUIG9yIE1VU1QgTk9UIHByb3Zpc2lvbiBvZiBSRkMgNzk1 MCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsgc2VjLiAxMSwgdGhlbiB0aGUgbWFqb3IgcmV2aXNpb24gbnVtYmVyIGluIHRo ZSBzZW12ZXIgc3RyaW5nIE1VU1QgYmUgaW5jcmVtZW50ZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5KYXNvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFu ZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5XZWVrbHkgd2ViZXggY2FsbCBkZXRhaWxzOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUp OiAxNzEgMDY5IDAzNzQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5N ZWV0aW5nIHBhc3N3b3JkOiBzZW12ZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9jY3VycyBldmVyeSBUdWVzZGF5IGVmZmVjdGl2ZSBUdWVzZGF5LCBTZXB0ZW1iZXIg MSwgMjAyMCB1bnRpbCBUdWVzZGF5LCBBdWd1c3QgMjQsIDIwMjEgZnJvbSA5OjAwIEFNIHRvIDEw OjAwIEFNLCAoVVRDLTA0OjAwKSBFYXN0ZXJuIFRpbWUgKFVTICZhbXA7IENhbmFkYSkNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj45OjAwIGFtJm5ic3A7IHwmbmJzcDsg KFVUQy0wNDowMCkgRWFzdGVybiBUaW1lIChVUyAmYW1wOyBDYW5hZGEpJm5ic3A7IHwmbmJzcDsg MSBocg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1hNzYyN2EyYWU3Yjc3MDUzN2Nm ZjVmNWI4OTI5M2M3MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW1hNzYyN2EyYWU3Yjc3MDUzN2NmZjVmNWI4OTI5M2M3MDwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGFwIHRvIGpvaW4gZnJvbSBhIG1vYmls ZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4rMS02NTAtNDc5LTMyMDgsLDE3MTA2OTAzNzQjIyBDYWxsLWluIHRvbGwgbnVtYmVy IChVUy9DYW5hZGEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR08MB5084B9510E2EE76F9D7A4D299B4F9DM6PR08MB5084namp_-- From nobody Wed Apr 14 06:55:14 2021 Return-Path: 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 C3AAC3A0B13 for ; Wed, 14 Apr 2021 06:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=ericsson.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 TFgboHlIP9OP for ; Wed, 14 Apr 2021 06:55:07 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80082.outbound.protection.outlook.com [40.107.8.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D633A0B07 for ; Wed, 14 Apr 2021 06:55:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jodrNBW2Hkhk2d0ftSC19brsd1KHRaBj7A1Vmxz3WOepeCaenQjBPfrx1CWNJ34wd8j7VvPieKJtIbyxXLLUUCPHETQgIrLhO6GspfVudGPQ1enkiMWMJohskAg2YM9i1sO4lc0I9uqDAgYxq/GmNZE+MzRbxUEHD/0VYtUecsgCwqmOaJUArcie74R4+XK2RANU1cA9iXBRpYNcj+AO0W3IBcDdIQfW13OMu2K6EeE9iPbk5uPR2JpcXW+YcESdZ98mKeG46XnAlyo/yHSj9eFzppTD8CX7qiLK8BN7mSsRG0cwVwMJJkyEOj91tCY6C2nA9mPhOg6W0PzSBYmDFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wgUf5YTBWLku8fIde+4j1mH3uV5dmgMC5uveqkAakoE=; b=YFNq6Eig8dXklCVCxGWl5F/L6xkOKl4BfM40KaL3IBuvIApjMhW4PTlFWsLz/9zK8toxxxie67/6eyjUOhVTf+FwGL/SQBcDsiAEcsU9gbLYfbtTwQYSRXU6n7jLc9zgHx9IJ+FitqcyOQHs0T1YUShNM1dwT+AJBfUPVPWXITC27O73JGF2C+Hh8OPzVJOJ4MIFXXRhz4+oZZ05s4Bcrmwz+WTB/LHF2hIFfwta9CpynORssjkUgmYJVX6YnSnbAdO5CzP1enffIB7OuHX8Ujo/BX7u/bVW7yCEXRXRpESNx1zIIu5AXunUmF4w/MfWswSO4gj9ihQ5Q0UQOo/o9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wgUf5YTBWLku8fIde+4j1mH3uV5dmgMC5uveqkAakoE=; b=S7KbZuTztJ8oLYfBwFcaHGwyILy/tYJ1/5wiDk/5IQ+cwiznuuBRHoAXtrEpt6SDM4Abs4hkIPCrM1sFx5kdQsTP4qILrUdhXgvgT6MYzy+8dhBEDGJWnstRs4bUJpjWfAMs1PkhHG44xdw1NSiEoZ4pY7nRztbCmDCN+jmSrEc= Received: from AM6PR0702MB3557.eurprd07.prod.outlook.com (2603:10a6:209:d::21) by AM7PR07MB6674.eurprd07.prod.outlook.com (2603:10a6:20b:18f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.6; Wed, 14 Apr 2021 13:55:04 +0000 Received: from AM6PR0702MB3557.eurprd07.prod.outlook.com ([fe80::dfd:a279:c1a9:fc5b]) by AM6PR0702MB3557.eurprd07.prod.outlook.com ([fe80::dfd:a279:c1a9:fc5b%6]) with mapi id 15.20.4042.016; Wed, 14 Apr 2021 13:55:04 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "Sterne, Jason (Nokia - CA/Ottawa)" , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 Thread-Index: AdcwbvJ73nHRwisWQiGZsVCuOZkrmgAIhXoAAABXCrAAKIt+wA== Date: Wed, 14 Apr 2021 13:55:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.248.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 929781f8-03b3-4a69-698a-08d8ff4ce7b3 x-ms-traffictypediagnostic: AM7PR07MB6674: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Lv2x07uOOE8D+I2W9McbSpR1XFSvxO6OUVxTwDOdkvBGTiLM0+/r1455tRWZfIGQixu/hVlvgObhaSScNc1fK9fD92MulokYrTWcBr69aEiQhjaad+CKRndSvPVGX97uTWCQzIlCu8TA0pUsZ+xXJUILSaYonTn92X3KMFDnkRkN1aB+TfipqSrO6qbUeqHKr+V2eOEhxAQzpVOZqTA+bV85sqnso9spnScGjUYKkc6eIrX4KOVHVtksiZ0vCrFfq9YLkA1aWNnAdaDWb0tbuA8dMfEHHsz0leMQqGWmpE1z/g4YDDl8TgXqiTMXl7iNmmJwOLH3qDMnGCIWnECfweRZ35HALJ7UzX1F/7BnaWXhYOx3nRT6Yh/nSt/SoEv72ZU0Z7rLw2AO2cwoMI+VMrcK+GRAiIUTx/5R+99AlCVuZOcoChJo6wkALduiDcR+2/BmcZhq+YLQ8JqIwGqvz8HA/ks7+cSI+v9/4kDytNDF1YlRMfZV6kiv6cfqRFTrPYN0ZPRm1D9a5ssn/Nd3qav9CnHk+bdUqAJBqsWhMYsOcBC0xpHozv7VWulwgKXOL3q3WHodybW7MOm6hZJN1OmSBVs1i8WtXU8NmC7tVsOiuNRUt4p5IzZ+JZoJIQKRWnFbmnfxNp9jrJSmHvUYmP8SIDYgVBesIsGv6vB2SY4gamJP9JqMM7PohHDL/3lL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR0702MB3557.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(346002)(396003)(376002)(166002)(2906002)(53546011)(99936003)(38100700002)(296002)(66946007)(110136005)(4326008)(66476007)(8676002)(316002)(8936002)(55016002)(33656002)(83380400001)(9326002)(85182001)(76116006)(86362001)(66556008)(66616009)(85202003)(26005)(122000001)(16799955002)(71200400001)(186003)(6506007)(52536014)(478600001)(5660300002)(64756008)(966005)(7696005)(9686003)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Uk90ZVVKUDBLNE1rUWk3Q2RQSEplOEp0Tzc5bW5sT1BtY3J1bkd2MVpRYXdD?= =?utf-8?B?N3g1ellmem9PYXBkL2FjdHVhVk5EeCtJRkdHTEhHcnlHcXEwME90QWw5dXVw?= =?utf-8?B?SWRYOTdYU2srS2NjY2ZqUkthTXN5N01neS9tZXh1OHh6Y1IrbjhyZG52RzBU?= =?utf-8?B?TjNhenpzSVN2cURwNTJ5RWFFcVFSaWo0NytSQWZaZFBwZ2s2V0FMckplSmdI?= =?utf-8?B?UGZMWm10elFWZXd1TEI5VlRDMkt3cC91RmhkczZNRmpkQlJ5MmxhWjU3cFdo?= =?utf-8?B?Z3BYaFR0VXI5Umo1V2EyelQ4V3BIakNVN094NjVwMWFXSlV4OWdBM3Jub0ZP?= =?utf-8?B?b1BBYzFPU0huL25xU2ZhdjlkNnJ6TVp5OHJyQkFSbnQxMm95L3cwSU9RZnhy?= =?utf-8?B?d0lleWI4YmlLblJBdktOWkpxZyt1QUJhKytVdCswcTRjaXZrMnJ2Z01QZGRz?= =?utf-8?B?Wko3M3lZT1V3b2tSdWJoQk1iUlgvdlFOcmtjSStaTWNUUEpyQkgwT0Zzb01F?= =?utf-8?B?eWlhWE1oYjFJYmRoVjBSNngrWlZxVC9iWmZ6UzU1ZHF6dEdGZDlWaUpSU05y?= =?utf-8?B?bVRJNUg3aUEvR2JEQm9iNWQrNzMxRmxJM1BSVFVQcFRyNitUSnpHSUJvSW1G?= =?utf-8?B?UGFRdXJoQlRqWHpWd29IWVBSbWJMVmFQNG1WbS83ZG5LOU9QS3FZQUNGNUpQ?= =?utf-8?B?am53R1ZUZ0x4VUh2d1k3TmlCako0aGZaQzZaNGJETUVMb25WZHc4V2lvdGZn?= =?utf-8?B?Z2hpNHFaOGlHUC9kUUFablpjOEVoMjVUbHlsMGZGWWV3MzRFUVlwZWxmQ2Nl?= =?utf-8?B?TnVObWRsN3luSm9IOGJkSytXeWVEemwranJqNmUrMHlNMXhQdUV0Z09OZmFR?= =?utf-8?B?ME95U3FVdkhnWno5dDRzWG56dkQ5bU14RmM0QnFsaFdob0tHSTNVQ2FuUjE2?= =?utf-8?B?QlVWR21QVllNV25KUFcwQzFPajIvc3JHd3VjNGFtbUVtUnB3T1hUU3h5aGhl?= =?utf-8?B?M29GU0NCdXFFSnN0aVpkVkRiVFJDNjdzOGtQQmxRME1SUkpCTzdIWTJWRG5s?= =?utf-8?B?R2tOMzhuYldwTjVxUmJOTmJGbGFkQU1hWmVmVms3TXAwSmF1OHR5ZGJjc3Rr?= =?utf-8?B?THJHY1d0dVA4VFdmOVVkbkNwelI1RHJCMzlHS1pjckZqUVRlRVdZL3E5UDkz?= =?utf-8?B?Y0NybzRWR1VXdDd0c1JjeXhhZXlHMEdUN3hFRmNoZFREOFhmN2NGaUJHZHZt?= =?utf-8?B?L1lXTWtrTi9uMVdKRXBYZitBc2R1TEJ1Z2xWT1RkLzVyY1RGbkpMM0dsNFQ3?= =?utf-8?B?Y1VXaWFTRS9meVMxemoycDQ2T1VRWEhyR2lUV2Y3TnRPZzd5UW53OXplVzBS?= =?utf-8?B?dENvY3dXMTFJU2RPbVkxek1Na3pDeXI4UWdmUFpXNWhCWUdHL0MrQWdReUdt?= =?utf-8?B?ZmltZUhGaGV4NjRMV2x5d1k5V2ZkdmNBT1RhNlV4UjNUT2I1QVh6NHYzejlu?= =?utf-8?B?MGFzQTF5RHBpV2lxcGdIM20yT3Rtb2xwUWVISCtYWnh2UDJpLzRYYTZTcmVo?= =?utf-8?B?UllsaVF4Z2t1dlNpZkRtMEJMQjIxMGxCQUxqVXJBM2xIMFBvOEpVb2F2aDNS?= =?utf-8?B?dTRSdXlYOFBCd3JNRTkwZUk3eEkrenpSd00wZVNBbUhNckhSNTBYSmt3TmRz?= =?utf-8?B?dmZHQm5mcTFYRzZYNUJlNVBWa1BMdFk1dXZObjVWc25yZkMzeThmc0hna3Bk?= =?utf-8?Q?qr+m8lPD645/6TeC5kzAwAZ58lFtOtYwtIF7Oh6?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0303_01D73146.87D36990" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR0702MB3557.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 929781f8-03b3-4a69-698a-08d8ff4ce7b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2021 13:55:04.1708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jf8AO4+5wkHH/nA7XcUt5cgGJicBReqqyKwcsX5LDu5iy0QCNPTXsj1g6nHb3BvGAkusR8mrSHHmbMCPVqaa5FYxn3CN3VWPgrD+B99W4Ps= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6674 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 13:55:13 -0000 ------=_NextPart_000_0303_01D73146.87D36990 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0304_01D73146.87D36990" ------=_NextPart_001_0304_01D73146.87D36990 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Andy, I remember when we wrote these rules, we were concentrating on config = and did not spend much time considering state data. =20 There are rules that are good for config but not for state. E.g. * RFC7950 does not allow changing the mandatory statement from false to = true; as this could make a valid configuration that does not include an = optional leaf invalid. * On the other hand, changing a state leaf from mandatory false to true = means always including the leaf in a response. That should be a = compatible change.=20 Do you agree, that at least in some cases different compatibility rules = for state and configuration data makes sense? Regards Balazs =20 From: netmod On Behalf Of Sterne, Jason (Nokia = - CA/Ottawa) Sent: 2021. =C3=A1prilis 13., kedd 20:30 To: Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 =20 Hi Andy, =20 Thx for taking a look. =20 Yes - agree with the "orderly" comment. That was very brief shorthand = for the minutes. By "remove" it could even just mean marking as = "obsolete" (with deprecated as an optional intermediate step). =20 We aren't trying to redefine the rules for config. But it is worth = considering whether some of those aren't really good for state. = Implementations may be ignoring some of those rules for state because = they don't really fit. =20 Jason=20 =20 From: Andy Bierman >=20 Sent: Tuesday, April 13, 2021 2:16 PM To: Sterne, Jason (Nokia - CA/Ottawa) > Cc: netmod@ietf.org =20 Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 =20 =20 =20 On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) = > wrote: YANG Versioning Weekly Call Minutes - 2021-04-13 =20 Primary discussion was around the BC/NBC rules for state. =20 Value space for config false: - more informative if you actually remove the enum from the model if it = isn't used anymore (vs leaving it in and servers just not returning it) - a server implementation should deviate if it doesn't return something = ever (schema should try to accurately define the API) - standard module -> remove the item if it isn't part of the API anymore =20 =20 I assume you mean to use the status-stmt to transition from current -> = deprecated -> obsolete in an orderly fashion. Especially since sec 11 is very clear: =20 Obsolete definitions MUST NOT be removed from published modules, since their identifiers may still be referenced by other modules. =20 =20 =20 - NMDA operational DS has a copy of config true, so increased value = space in config automatically casues increased value space in "state" = (operational) - a config true MTU in the operational DS and a dedicated config false = "oper-mtu" leaf should have the same rules for increasing value space =20 Maybe a better formulation of the state rules is to take the 7950 rules = and apply minimal text changes. Rob will take a stab at this. =20 7950: o A "must" statement may be removed or its constraint relaxed. =20 Adjusted 7950 text: o A "must" statement may be added, removed, or changed =20 =20 7950: o A "range", "length", or "pattern" statement may expand the allowed value space. Adjusted 7950: o A "range", "length", or "pattern" statement may expand or reduce = the allowed value space. =20 =20 I strongly object to this WG creating an "adjusted YANG 1.1" standard. IMO there is no need or WG consensus to create any sort of replacement = for RFC 7950. =20 If YANG 1.1 needs non-backward-compatible changes (which it doesn't = IMO) then a new YANG 2.0 RFC must be written to accomplish that. =20 It is possible to introduce support for NBC changes in a way that does = not change YANG 1.1 at all. E.g.: =20 Rule 1 of 1: - If any change is made that violates a MUST or MUST NOT provision of = RFC 7950, sec. 11, then the major revision number in the semver string MUST be = incremented. =20 =20 =20 =20 Jason =20 Andy =20 =20 ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374=20 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, = August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & = Canada)=20 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr=20 https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c7= 0 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_001_0304_01D73146.87D36990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Andy,

I remember when we wrote these rules, we were = concentrating on config and did not spend much time considering state = data.

 

There are rules that are good for config but not for = state. E.g.

  • RFC7950 does not allow changing the mandatory statement from false = to true; as this could make a valid configuration that does not include = an optional leaf invalid.
  • On the other hand, = changing a state leaf from mandatory false to true means always = including the leaf in a <get> response. That should be a = compatible change.

Do you = agree, that at least in some cases different compatibility rules for = state and configuration data makes sense?

Regards Balazs

 

From: netmod = <netmod-bounces@ietf.org> On Behalf Of Sterne, Jason (Nokia = - CA/Ottawa)
Sent: 2021. =C3=A1prilis 13., kedd = 20:30
To: Andy Bierman = <andy@yumaworks.com>
Cc: = netmod@ietf.org
Subject: Re: [netmod] YANG Versioning Weekly = Call Minutes - 2021-04-13

 

Hi Andy,

 

Thx for taking a look.

 

Yes - agree with the = "orderly" comment. That was very brief shorthand for the = minutes. By "remove" it could even just mean marking as = "obsolete" (with deprecated as an optional intermediate = step).

 

We aren't trying to redefine the rules for config. But it = is worth considering whether some of those aren't really good for = state.  Implementations may be ignoring some of those rules for = state because they don't really fit.

 

Jason

 

From: Andy = Bierman <andy@yumaworks.com> =
Sent: Tuesday, April 13, 2021 2:16 PM
To: Sterne, = Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
= Cc: netmod@ietf.org
Subject: = Re: [netmod] YANG Versioning Weekly Call Minutes - = 2021-04-13

 

 

 

On Tue, Apr 13, 2021 at 7:12 AM = Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> = wrote:

YANG Versioning Weekly Call Minutes - = 2021-04-13

 

Primary discussion was around the BC/NBC rules for = state.

 

Value space for config false:

- more informative if you actually remove the enum from the = model if it isn't used anymore (vs leaving it in and servers just not = returning it)

- a server implementation should deviate if it doesn't = return something ever (schema should try to accurately define the = API)

- standard module -> remove the item if it isn't part of = the API anymore

 

 

I assume you mean to use the = status-stmt to transition from current -> deprecated -> = obsolete

in an orderly fashion. Especially since sec 11 is very = clear:

 

   Obsolete definitions MUST NOT be =
removed from published modules,
   since their identifiers =
may still be referenced by other modules.

 

 

 

- NMDA operational DS has a copy of config true, so = increased value space in config automatically casues increased value = space in "state" (operational)

- a config true MTU in the operational DS and a dedicated = config false "oper-mtu" leaf should have the same rules for = increasing value space

 

Maybe a better formulation of the state rules is to take = the 7950 rules and apply minimal text changes. Rob will take a stab at = this.

 

7950:

   o  A "must" statement may be = removed or its constraint relaxed.

  

Adjusted 7950 text:

   o  A "must" statement may be = added, removed, or changed

  

<= blockquote style=3D'border:none;border-left:solid #CCCCCC = 1.0pt;padding:0cm 0cm 0cm = 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5= .0pt'>

 

7950:

   o  A "range", = "length", or "pattern" statement may expand the = allowed

      value = space.

Adjusted 7950:

   o  A "range", = "length", or "pattern" statement may expand or = reduce the allowed

      value = space.

 

 

I strongly object to this WG = creating an "adjusted YANG 1.1" = standard.

IMO there is no need or WG consensus to create any sort of = replacement for RFC 7950.

 

If YANG 1.1 needs = non-backward-compatible changes  (which it doesn't IMO) then a = new

YANG 2.0 RFC must be written to accomplish = that.

 

It is possible to introduce support = for NBC changes in a way that does not change YANG = 1.1

at all. E.g.:

 

Rule 1 of = 1:

  - If any change is made that violates a MUST or MUST = NOT provision of RFC 7950,

    sec. 11, then the = major revision number in the semver string MUST be = incremented.

 

 

 

 

Jason

 

Andy

 

 

----------------------------------------------

Weekly webex call details:

Meeting number (access code): 171 069 0374 =

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1, 2020 = until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US & = Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b77= 0537cff5f5b89293c70

Tap to join from a mobile device (attendees = only)

+1-650-479-3208,,1710690374## Call-in toll number = (US/Canada)

_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

------=_NextPart_001_0304_01D73146.87D36990-- ------=_NextPart_000_0303_01D73146.87D36990 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQxNDEzNTUwMlowIwYJKoZIhvcNAQkEMRYEFJmeQOjCimkI 9BhLJi3PqCipnvWhMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBADIJ gcQUhmcwsMOlZLCsfUB5A0eo5bMn1/fJZzW5r4FwNIE9sQNdhYsUac8EMsKXGIanfurr/gTXyW1U VTD79h4hsqPw/cMzsXlBQkDcQo4qSuQRlqf5gG/FLJTPlvxapzkRI2wk0q6yZolOSYBwFt03LKIL TXIrXzhXrXBzHCvY5lplAqEaAH9eFgXSUyPNroPy4WLKLVWx33aOO6fI3R00mFp6GeZt1uHwFa2X mD5N/+EGMuX8Yp7nECJ6nmQq1Mu4Dal6+YWSEY8Wz4Q2eHxL+vPuj+pRTGhxH9MWvoFi7LaHZbxZ xOndNcsci1gDBIrEF1XOw7huNdY7ut/ipAYAAAAAAAA= ------=_NextPart_000_0303_01D73146.87D36990-- From nobody Wed Apr 14 08:08:22 2021 Return-Path: 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 53E133A122C for ; Wed, 14 Apr 2021 08:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.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 vfAB3RN_ANg5 for ; Wed, 14 Apr 2021 08:08:13 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9293A1268 for ; Wed, 14 Apr 2021 08:08:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DqO5JkSlCdxiqkDZmxkaVvxmjpRKf2IoeubppkQvZ8AP4yzrzpyqRREffB0mJKPfXcX19nyABilVI3qxFT9unZXZlQ9F5c5NkM1d4ueaxYQKnvy8ArDj0V1ZPq/c/Qs3FziaUUIN8kEsCDBdTNcD/DoBQzqbhgkbdvxnl9weWvpIjUB2sltSS0rO8puyMRMz7JRb06qfIGMO05JjwdQ8tANcquD6GgiOVAzJ5pVrqI5ui3jet+5r5jCxV92MljxJ4qPyPNH/77kgx0x0H0pDBnupAlmAlZcd/x4is1exM9U1fT1tC9RmzMXJeE7/aPTonhNgKsVJ+uJORFQ+af4PdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HcduLenvdmu6wj7ILWpClSEzhemOzs/51yzc7JpGT6E=; b=hvwamjE99z9yKbTTPtrFhqS7jwBoOkLFiM+P7GYsd14tNIRoZaNfHBkHjLelExuNWrzcWDuSfRla5armL8iBsQraxSaccXKOIyYDg2CnipQkpMFbsJXP+Jaq8REqzXclwmyXzsftd2us3obJWR98tg95YQOEH0pCIqH1xhFcVdm2+qLOX1lXbr0IYAYrIyH8cXPevfpcYr2qikdUx772HfLyWVtXl9wOiwYd9vuciyDosRRUU0wur+mQ39ZUMF2EUbr3udrhjGaNg24+B6m8nsCG0l6dSlLwnIfEm0CF7En/nzJgxtxFkTmncjVx7zA8pwF52++46WVpmvkD045LPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HcduLenvdmu6wj7ILWpClSEzhemOzs/51yzc7JpGT6E=; b=qMIQz623Ic2/tThW4WEYraMfXT5Vfqc8C5S6qmipk8KYrGnBaQd7rTmFQLP7EatbTy5QTdAxSlCylVu34ZP9lFP72Pp4mSZMjkpbrz+uk+US09PYhKN3qUZuuu+se1umxTG3dh5IES1WN+76V3g2w/p0LMhzC9t0CYGiqMmK4to= Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0036.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:5e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Wed, 14 Apr 2021 15:08:09 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.4020.022; Wed, 14 Apr 2021 15:08:09 +0000 Date: Wed, 14 Apr 2021 17:08:07 +0200 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , Andy Bierman , "netmod@ietf.org" Message-ID: <20210414150807.nny4flvrlkvemfnv@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "Sterne, Jason (Nokia - CA/Ottawa)" , Andy Bierman , "netmod@ietf.org" References: Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR0P264CA0204.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::24) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0204.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Wed, 14 Apr 2021 15:08:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e8b02946-2887-40a5-27d5-08d8ff571d8f X-MS-TrafficTypeDiagnostic: AM4P190MB0036: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Auh8qnXdMgjUm+62vtchEswg2KHiMaNVH0AN/tR3+845oBUtYgvi6z3oP21VAfN2GwgvJSSTXU9Pa4TeCTsFGlpdai+Hx3Zqz2KCFdguetesa/gJ75wLi0y4t+bY4BB0CqhArMrIRNrLQ5Oc/ifgiVLSbC2DEatvQKU0Yf+0H0Igemf4J4W0Y6d28K+gBQWZ3zISYd3w2JzaF7ZF8zajseq8PE4q14kHDksnQnr94PJT0KTYbm6p7RaRUxCPIuvVmYmqb0zcnUaAOt64LvV1ihoz32ruY2seC+NBuR7WG17VK4iV0lsfmM93t5/iGQfB212fkuQK0pwMoKpF9hA/XgnDZfoKo6mVLM/cc56/HdZZRemTegXdUnxjI8SKfKTwDc8qC0CwCU0VTs9sYIHmmK8XowgfpWq2jmAO2b4nwXHM35BRXfukw5OG4X1neBJoz2lFK3Grq/SOjaHoL2t/9nWperGSYWRQkvMQVxRKRWAHnfh44D5iAQyO/TmdSEinTldcdpPszJpAZiTcVK8OAvydLqDMh1d92jdz5M/gULln3TZAdWBVxs92oUxwtNWfOThyWj8bcyS7HaL8dEYEB8ZUdM6GNQ5T6eB3K3jVyTo+/Y6x5hip833LHni12ZrJoiyPKA441f2CYmNZeIr54LNWhcdseLGfPuvOc522qkybj2R/vThSYfWfs+lRNbRCbnQwx8qm1sh3UO/XhZ6LxkShyiNl3hdAQJYks2VSKm8= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(39850400004)(346002)(396003)(956004)(8676002)(8936002)(66476007)(66556008)(316002)(1076003)(54906003)(86362001)(66946007)(786003)(2906002)(3450700001)(38350700002)(186003)(26005)(6496006)(4744005)(16526019)(5660300002)(4326008)(478600001)(6486002)(52116002)(38100700002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?wEWYiJlV6Fb+FGauSQ2aJ+zFqGr9dXbmdtzwbd59M7g+E4a/Lo0C6WCoEP?= =?iso-8859-1?Q?dYeeLoOb8gHO3lbIaKrbpCZLZzQuW5QSgGk3ER5v6tyoHbnAisZ5kbh9Nb?= =?iso-8859-1?Q?0na7y6eNL4Ah00MAvvYngUtM7YqMFnBQF2cNPsK94MKjsevzsgFuMC+uKv?= =?iso-8859-1?Q?VpnPJu9WzKa7Wp4oe/rxd0M3ZN4SaNqHTDrM/AOc6Uwv7wv4koArhi1GQ3?= =?iso-8859-1?Q?Rzax7GJvB53tKF+3lmPgj6saeqS3yyybzx/WmdtsHsIFjpugN88FXs8tZw?= =?iso-8859-1?Q?Ve78x7REq1gKguIjNMUm+VAPUkPxmWlQnK3fJPSTd3dPHnro3l6FOr8Edi?= =?iso-8859-1?Q?I0g+ufNoRTMn52imgNTHwDRkthEVwcmiVhD7RKuOY0oPnfXIGQnguyK+eu?= =?iso-8859-1?Q?F2iWUwwXh5zGDcQvmS7gGPsc1PngZ9Kco5psF+jMEmXbLtdb4dKdh/V8qI?= =?iso-8859-1?Q?BKQG2OwFs6XaiCYsq/ZkB7PE1Q7Boa45BFbz00HaDZ5OAXevNt522wsVee?= =?iso-8859-1?Q?xOex15M9YnOnKz4A7pA0lLLDbw61/uFdHnuHBUuwjQ5YibKAz6aZkZqKOm?= =?iso-8859-1?Q?S0AHfKF1ZZ9DunrCDFYG50+QB8YPnVRDo5U4UEdV9DrcfnKbkCTSp+2IVe?= =?iso-8859-1?Q?Fn+V/5AtVhRM2SA7WdoWEcB3T9QWjA3iUYscEVUAyc974kBL4CXgQ24Vdl?= =?iso-8859-1?Q?S2rDGTO7p+CJuYxCDeowsYyHhJ/ErgcWT3+N3b1KXKgp5bP6NBkaBY0Xh6?= =?iso-8859-1?Q?3hUbaf2qmsPOjmKk+48oPJucxnCRh9IXjnWuFvhEUBfeolxAareLw3sYC3?= =?iso-8859-1?Q?PhAriUqoD+8znb9L0FtsvgPaQ2U5D9TMuV1VmQA4YzK48Da9L0cU9JVIel?= =?iso-8859-1?Q?VLuw6n2NXPqtBCIxZ2ugbt3o4gp+0MSlFuz1PwRWYv8cJ6quXcRIUv9Lpt?= =?iso-8859-1?Q?wsHarcra3bzPW7HLBbidg0y+dO07Zw5L5Mo13Nhk1kbWmfmhP5FkoaJ5Kr?= =?iso-8859-1?Q?JtaUckiAzqMrvZgv9+/FaYoxEZyJGCXDii0akyDPf68s3MPcrD7diFqbdE?= =?iso-8859-1?Q?hRfIBFCumI3Sf7dEqj99GCWRkiVDRITHgOTqB3F5G6mlYTirDPKWzwuEdz?= =?iso-8859-1?Q?AfOOoK+elmXOd/SmijQp5i6aXh6i2VtFjV0fycOTS4GcJQgeh3RmYq+Qgh?= =?iso-8859-1?Q?yyu5Y7lIgiu/clFBmRYIs1RlPIWSCSSgX2IyeHgYyEW42NJ8HVc1nxgp/Y?= =?iso-8859-1?Q?LOMXq0rcbD+z0/M/3SgQ2//iJZLuyF+H+13qaFZ4Sdz1knunbkTAj5kiLd?= =?iso-8859-1?Q?lmQOTKD5pslT3772JKlVWJFzwY1lPcVJMFTg4+TlNCRMnmKBCo69Df2dTt?= =?iso-8859-1?Q?b7L+aDllza?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: e8b02946-2887-40a5-27d5-08d8ff571d8f X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2021 15:08:09.7457 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: H8XT9mfZRBxrHpn45GYiuD8DwTN48U2oJ2pzgykEPfPrKdMp4CdkQT6gPAeijc3ITCllw47AbUiIzygcW7nppDzwcqu199SaaBPMcfApbmY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0036 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 15:08:19 -0000 On Wed, Apr 14, 2021 at 01:55:04PM +0000, Balzs Lengyel wrote: > * On the other hand, changing a state leaf from mandatory false to true means always including the leaf in a response. Where do you get this from? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 14 08:17:45 2021 Return-Path: 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 15AD63A12C3 for ; Wed, 14 Apr 2021 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 N0Xrs1y2Xo8G for ; Wed, 14 Apr 2021 08:17:38 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D2EB33A1480 for ; Wed, 14 Apr 2021 08:16:57 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id n8so33895429lfh.1 for ; Wed, 14 Apr 2021 08:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YwSS+TEm9F3gMhokxyw6Lq/L2sacUdKt9a27dDAhzY8=; b=cjur7zXCc2CvJS6RP5EayP+ze6b++59gWmngy9/OAcaKkrg+LZgIN+b7ToH5J8JykS 2rdvzMZr31rM/MiMNEroXXVJU5lkBmGi/4f1FpVbLMPbwM/nEW+yA0w7iSY+6hLQzK+O 52yof6n06fs0b5QuuKtFX6mfbNLbiCmbmVu5+YEJoDgkHnZn3G8UVgXx689Y8E+1m2+H V0mWmChUbzREWtW1mjI5W60YdhW/9Gb9qthP4mahxiyd645GsSmJEq9CGbH3jKyDA3mb G86SuR5CyPaz6//2Va0jT598uHvrNzi7r6PdjcNe89nsI4FxIBb35uBaC5bNtm5CvwnS r2tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YwSS+TEm9F3gMhokxyw6Lq/L2sacUdKt9a27dDAhzY8=; b=ijX5kCKRdmjVlnRmA57f7BJfQQziajYDXdqnlazyqAri81qqhP+2qpNwb28/mfoTbC LtKDCraFAJ3NGCFkBIExv8RUxqRqnbqITbU6DmVyW8kgN7NYnnbyRDbXghAbJWons4Qj jSjMRfkcld2HB0SGY9g+oePRpXHQHlYcUJbogph6xVf3afK/sK58dbGqK/UZe9mx8gq8 A283T+6HVf0s3/KiKCoR3Pj1YzFFT8GGDvD4H3vDWu55Jrq9KLA4Z40xLzAVJ5pPyT3i 3WqbZNr3X1TWxHP0D0u8Tvq7yGV8wr6Ar7C6p3puWV7Fdz2ZrOL3M7tc+ScwHu6oYMlc VJbQ== X-Gm-Message-State: AOAM531QqUq5Ch5oAxSoDamxLLmsquF4BVBk5zznpUVn2T1zgbLumsrG UvNUfAunSjzn+yCY/8fQ2cxlrmyAJK9X+qoS9y548Q== X-Google-Smtp-Source: ABdhPJwnkrWSwk6Sa/g7rxysUIO5RMsjxysPTDpDgH+uEs94p2XiNKxf6mdog61g8kWgBlRbTG8+fwC/n/c21Z7pm3M= X-Received: by 2002:a19:c707:: with SMTP id x7mr3851592lff.478.1618413414567; Wed, 14 Apr 2021 08:16:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 14 Apr 2021 08:16:43 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ace22905bff03c1b" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 15:17:44 -0000 --000000000000ace22905bff03c1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2021 at 6:55 AM Bal=C3=A1zs Lengyel wrote: > Hello Andy, > > I remember when we wrote these rules, we were concentrating on config and > did not spend much time considering state data. > > > > There are rules that are good for config but not for state. E.g. > > - RFC7950 does not allow changing the mandatory statement from false > to true; as this could make a valid configuration that does not includ= e an > optional leaf invalid. > - On the other hand, changing a state leaf from mandatory false to > true means always including the leaf in a response. That should = be a > compatible change. > > Do you agree, that at least in some cases different compatibility rules > for state and configuration data makes sense? > I do not agree that this change is needed in the YANG standard. I do agree that sometimes the YANG change rules get violated. If this happens then incrementing the major version number may alert a developer that NBC changes exist in a new module revision. IMO a new YANG RFC is needed in order to contradict ANY NORMATIVE TEXT in RFC 7950. The alternative seems to be to create 2 separate YANG compatibility tracks, one called YANG 1.1 and another for "NBC-capable YANG". As if routinely breaking backward compatibility was a good thing Regards Balazs > > Andy > > > *From:* netmod *On Behalf Of *Sterne, Jason > (Nokia - CA/Ottawa) > *Sent:* 2021. =C3=A1prilis 13., kedd 20:30 > *To:* Andy Bierman > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > Hi Andy, > > > > Thx for taking a look. > > > > Yes - agree with the "orderly" comment. That was very brief shorthand for > the minutes. By "remove" it could even just mean marking as "obsolete" > (with deprecated as an optional intermediate step). > > > > We aren't trying to redefine the rules for config. But it is worth > considering whether some of those aren't really good for state. > Implementations may be ignoring some of those rules for state because the= y > don't really fit. > > > > Jason > > > > *From:* Andy Bierman > *Sent:* Tuesday, April 13, 2021 2:16 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > > > > > On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com> wrote: > > YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > Primary discussion was around the BC/NBC rules for state. > > > > Value space for config false: > > - more informative if you actually remove the enum from the model if it > isn't used anymore (vs leaving it in and servers just not returning it) > > - a server implementation should deviate if it doesn't return something > ever (schema should try to accurately define the API) > > - standard module -> remove the item if it isn't part of the API anymore > > > > > > I assume you mean to use the status-stmt to transition from current -> > deprecated -> obsolete > > in an orderly fashion. Especially since sec 11 is very clear: > > > > Obsolete definitions MUST NOT be removed from published modules, > > since their identifiers may still be referenced by other modules. > > > > > > > > - NMDA operational DS has a copy of config true, so increased value space > in config automatically casues increased value space in "state" > (operational) > > - a config true MTU in the operational DS and a dedicated config false > "oper-mtu" leaf should have the same rules for increasing value space > > > > Maybe a better formulation of the state rules is to take the 7950 rules > and apply minimal text changes. Rob will take a stab at this. > > > > 7950: > > o A "must" statement may be removed or its constraint relaxed. > > > > Adjusted 7950 text: > > o A "must" statement may be added, removed, or changed > > > > > > 7950: > > o A "range", "length", or "pattern" statement may expand the allowed > > value space. > > Adjusted 7950: > > o A "range", "length", or "pattern" statement may expand or reduce th= e > allowed > > value space. > > > > > > I strongly object to this WG creating an "adjusted YANG 1.1" standard. > > IMO there is no need or WG consensus to create any sort of replacement fo= r > RFC 7950. > > > > If YANG 1.1 needs non-backward-compatible changes (which it doesn't IMO) > then a new > > YANG 2.0 RFC must be written to accomplish that. > > > > It is possible to introduce support for NBC changes in a way that does no= t > change YANG 1.1 > > at all. E.g.: > > > > Rule 1 of 1: > > - If any change is made that violates a MUST or MUST NOT provision of > RFC 7950, > > sec. 11, then the major revision number in the semver string MUST be > incremented. > > > > > > > > > > Jason > > > > Andy > > > > > > ---------------------------------------------- > > Weekly webex call details: > > Meeting number (access code): 171 069 0374 > > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > > https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c7= 0 > > Tap to join from a mobile device (attendees only) > > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --000000000000ace22905bff03c1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 14, 2021 at 6:55 AM Bal= =C3=A1zs Lengyel <balazs.= lengyel@ericsson.com> wrote:

Hello Andy,

I remember when w= e wrote these rules, we were concentrating on config and did not spend much= time considering state data.

=C2=A0

There are rules that are good for= config but not for state. E.g.

  • RFC7950 does not allow changing the mandatory st= atement from false to true; as this could make a valid configuration that d= oes not include an optional leaf invalid.
  • On th= e other hand, changing a state leaf from mandatory false to true means alwa= ys including the leaf in a <get> response. That should be a compatibl= e change.

Do you agree, that= at least in some cases different compatibility rules for state and configu= ration data makes sense?


I do not agree that this change is needed in the YANG standard= .

I do agree that sometimes the YANG change rules = get violated.
If this happens then incrementing the major version= number may alert a developer
that NBC changes exist in a new mod= ule revision.

IMO a new YANG RFC is needed in orde= r to contradict ANY NORMATIVE TEXT in RFC 7950.
The alternative s= eems to be to create 2 separate YANG compatibility tracks,
one ca= lled YANG 1.1 and another for "NBC-capable YANG".=C2=A0 As if rou= tinely breaking
backward compatibility=C2=A0was a good thing


Regards Balazs


Andy=
=C2=A0

=C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Sterne,= Jason (Nokia - CA/Ottawa)
Sent: 2021. =C3=A1prilis 13., kedd 20:= 30
To: Andy Bierman <andy@yumaworks.com>
Cc: netmod@ietf.org
Subject: Re= : [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13

=C2=A0

Hi Andy,

=C2=A0

Thx for taking a look.=

=C2=A0=

Yes - agree with the "= orderly" comment. That was very brief shorthand for the minutes. By &q= uot;remove" it could even just mean marking as "obsolete" (w= ith deprecated as an optional intermediate step).

<= p class=3D"MsoNormal">=C2=A0

<= p class=3D"MsoNormal">We aren't trying to redefine= the rules for config. But it is worth considering whether some of those ar= en't really good for state.=C2=A0 Implementations may be ignoring some = of those rules for state because they don't really fit.

=C2=A0

Jason

=C2=A0

From: An= dy Bierman <andy= @yumaworks.com>
Sent: Tuesday, April 13, 2021 2:16 PM
= To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
Cc:<= /b> netmod@ietf.org
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 202= 1-04-13

=C2=A0

=C2=A0

On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jas= on (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

<= /div>

YAN= G Versioning Weekly Call Minutes - 2021-04-13

=C2=A0

Primary discussion was around the BC= /NBC rules for state.

=C2=A0

Value space for config false:

- more informative if you actually re= move the enum from the model if it isn't used anymore (vs leaving it in= and servers just not returning it)

- a server implementation should deviate if it= doesn't return something ever (schema should try to accurately define = the API)

- standard module -> remove the item if it isn't part of the API a= nymore

=C2=A0

=C2=A0

I assume you mean to us= e the status-stmt to transition from current -> deprecated -> obsolet= e

in an orderly fashion. Especially since sec 11 is very clear:<= u>

= =C2=A0

=C2=A0=C2=A0 Obsolete definitions M=
UST NOT be removed from published modules,
<=
span lang=3D"EN-CA" style=3D"color:black">=C2=A0=C2=A0 since their identifi=
ers may still be referenced by other modules.

=C2=A0

=C2=A0

=C2= =A0

- NMDA operational DS has a copy of config true, so incr= eased value space in config automatically casues increased value space in &= quot;state" (operational)

- a config true MTU in the operational DS and a ded= icated config false "oper-mtu" leaf should have the same rules fo= r increasing value space

=C2=A0

Maybe a better formulation of the state rules is to take = the 7950 rules and apply minimal text changes. Rob will take a stab at this= .

=C2= =A0

795= 0:

=C2= =A0=C2=A0 o=C2=A0 A "must" statement may be removed or its constr= aint relaxed.

=C2=A0=C2=A0

Adjusted 7950 text:

=C2=A0=C2=A0 o=C2=A0 A "must" statemen= t may be added, removed, or changed

=C2=A0=C2=A0

=C2=A0

7950:

=C2=A0=C2=A0 o=C2=A0 A "range", "length", or &qu= ot;pattern" statement may expand the allowed

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v= alue space.

Adjusted 7950:

=C2=A0=C2=A0 o=C2=A0 A "range", "length", = or "pattern" statement may expand or reduce the allowed=

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 value space.

=C2=A0

=C2= =A0

I strongly object to this WG creating an "adjusted YANG 1.1" sta= ndard.

IMO there is no need or WG consensus to create any sort of repla= cement for RFC 7950.

=C2=A0

If YANG 1.1 needs non-backward-compatib= le changes=C2=A0 (which it doesn't IMO) then a new=

YANG 2.0 RFC mus= t be written to accomplish that.

=C2=A0

<= div>

It is possible to introduce= support for NBC changes in a way that does not change YANG 1.1

at all.= E.g.:

=C2=A0

Rule 1 of 1:

=C2=A0 - If any change is made that = violates a MUST or MUST NOT provision of RFC 7950,

=

=C2=A0 =C2=A0 sec. 1= 1, then the major revision number in the semver string MUST be incremented.=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Jason=

=C2=A0

Andy

=C2=A0

=C2=A0

---------------= -------------------------------

Weekly webex call details:

Meeting number (access code): = 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September= 1, 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:0= 0) Eastern Time (US & Canada)

9:00 am=C2=A0 |=C2=A0 (UTC-04:00) Eastern Time = (US & Canada)=C2=A0 |=C2=A0 1 hr

https://ietf.w= ebex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70<= /u>

Tap to join from = a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number= (US/Canada)

_______________________________________________
netmod= mailing list
netmo= d@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--000000000000ace22905bff03c1b-- From nobody Wed Apr 14 10:24:24 2021 Return-Path: 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 856B23A18D0 for ; Wed, 14 Apr 2021 10:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 sUPwUJY7rbPO for ; Wed, 14 Apr 2021 10:24:12 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 CC9213A1857 for ; Wed, 14 Apr 2021 10:24:08 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id l14so21235606ljb.1 for ; Wed, 14 Apr 2021 10:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tMKVBHjENSHt6/EkSe/rp1JWnyCXl8WMAgUaiJb24fE=; b=zxahGlkj6/JAetXuCMckjc916GgCtm9hqTbuzTj/UbjBjNML/Z+wfhzvGvXM6rurP6 UL4TKSCuPtbewIozjb/ENqH5OJ+GaHEHXPW7qu3INhTJJVBaAEMrXqvFDGRaRxDHNrHU 3QP9vu6/J1fO64kvzWGS5J+SldeKIc2PJW/m5O73H+Pr5Y2Ays2KskYqXcluiusrrvge EhmMyUGRL2OPWnI+/gRvMLeL79T7+96FCeHT2pY5YS0Og+w/aN3SGxCuqp2P84b+8GAg tdWCrWHob/pThqYtVtDeDPko6xgw4elYMYX2vgpXCpxPLoMj/tIhptpGrQfMDEuITzPM FkJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tMKVBHjENSHt6/EkSe/rp1JWnyCXl8WMAgUaiJb24fE=; b=Hfk68Wt0jX25ovaif9GDvRlnNpSNcUeTFDsfYnVu6C332r4h0BW8BGpFmjxzzF8uys pg01DVLf7vveSgADMCfmMy6PEDQ5Ye8fgC+WY04xcQ3XjCgaYPax9ZQdKmSZYSKrx0nd RG3nrEG6/mh9GLwTG5gBSERKC2RCZGHDYzmtuRHCe9qn1uyxYcwSvjkcMSPlRZakedky r2Plvn4A4vEmKfoU0EBQLK+lAoI5WMgrZ0NPtG1aM+1b3sGCpy/dUt39ilmeK0zun6v7 6Ml/w5gWkyBKkCa0/TEhwU3eXFfwW4ritjJU1NUaIo11kW88zBTQKMSGf4BdkNuXMjzq lIiQ== X-Gm-Message-State: AOAM531JdHZ7XqqdpSoNdoTv/jtx6xFsGvdSpbx2AoUDcGd2uzYnv2Z1 8KE6AXk9wBXjsk1tDgzrmjMawpIHBNpYHcoei9K1Sg== X-Google-Smtp-Source: ABdhPJziXpfZoYXpboJJZkX8kDF93Q3FP+H88ViGJ7tWuw0/w1qV3vk8lJ/pbWxoeOnCKE2GkLOWjZAl98VqQgz4G8M= X-Received: by 2002:a2e:8416:: with SMTP id z22mr7163122ljg.43.1618421046702; Wed, 14 Apr 2021 10:24:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 14 Apr 2021 10:23:55 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000096058f05bff203d8" Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 17:24:23 -0000 --00000000000096058f05bff203d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2021 at 6:55 AM Bal=C3=A1zs Lengyel wrote: > Hello Andy, > > I remember when we wrote these rules, we were concentrating on config and > did not spend much time considering state data. > > > > There are rules that are good for config but not for state. E.g. > > - RFC7950 does not allow changing the mandatory statement from false > to true; as this could make a valid configuration that does not includ= e an > optional leaf invalid. > - On the other hand, changing a state leaf from mandatory false to > true means always including the leaf in a response. That should = be a > compatible change. > > Do you agree, that at least in some cases different compatibility rules > for state and configuration data makes sense? > I think this is a topic for the yang-next list. There is a list of about 100 issues that people would like to fix or change in YANG. If the WG ever decides to work on yang-next then I will be happy to participate in that work. IMO the YANG-based approach to dealing with NBC in the wild in not going to work. Improvements to the protocol will help but they are not in scope here. Support for warnings would help real implementations right now. It was a mistake to remove (rather than fix) warnings in NETCONF (and now also RESTCONF). > Regards Balazs > > > Andy > *From:* netmod *On Behalf Of *Sterne, Jason > (Nokia - CA/Ottawa) > *Sent:* 2021. =C3=A1prilis 13., kedd 20:30 > *To:* Andy Bierman > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > Hi Andy, > > > > Thx for taking a look. > > > > Yes - agree with the "orderly" comment. That was very brief shorthand for > the minutes. By "remove" it could even just mean marking as "obsolete" > (with deprecated as an optional intermediate step). > > > > We aren't trying to redefine the rules for config. But it is worth > considering whether some of those aren't really good for state. > Implementations may be ignoring some of those rules for state because the= y > don't really fit. > > > > Jason > > > > *From:* Andy Bierman > *Sent:* Tuesday, April 13, 2021 2:16 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > > > > > On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) < > jason.sterne@nokia.com> wrote: > > YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > Primary discussion was around the BC/NBC rules for state. > > > > Value space for config false: > > - more informative if you actually remove the enum from the model if it > isn't used anymore (vs leaving it in and servers just not returning it) > > - a server implementation should deviate if it doesn't return something > ever (schema should try to accurately define the API) > > - standard module -> remove the item if it isn't part of the API anymore > > > > > > I assume you mean to use the status-stmt to transition from current -> > deprecated -> obsolete > > in an orderly fashion. Especially since sec 11 is very clear: > > > > Obsolete definitions MUST NOT be removed from published modules, > > since their identifiers may still be referenced by other modules. > > > > > > > > - NMDA operational DS has a copy of config true, so increased value space > in config automatically casues increased value space in "state" > (operational) > > - a config true MTU in the operational DS and a dedicated config false > "oper-mtu" leaf should have the same rules for increasing value space > > > > Maybe a better formulation of the state rules is to take the 7950 rules > and apply minimal text changes. Rob will take a stab at this. > > > > 7950: > > o A "must" statement may be removed or its constraint relaxed. > > > > Adjusted 7950 text: > > o A "must" statement may be added, removed, or changed > > > > > > 7950: > > o A "range", "length", or "pattern" statement may expand the allowed > > value space. > > Adjusted 7950: > > o A "range", "length", or "pattern" statement may expand or reduce th= e > allowed > > value space. > > > > > > I strongly object to this WG creating an "adjusted YANG 1.1" standard. > > IMO there is no need or WG consensus to create any sort of replacement fo= r > RFC 7950. > > > > If YANG 1.1 needs non-backward-compatible changes (which it doesn't IMO) > then a new > > YANG 2.0 RFC must be written to accomplish that. > > > > It is possible to introduce support for NBC changes in a way that does no= t > change YANG 1.1 > > at all. E.g.: > > > > Rule 1 of 1: > > - If any change is made that violates a MUST or MUST NOT provision of > RFC 7950, > > sec. 11, then the major revision number in the semver string MUST be > incremented. > > > > > > > > > > Jason > > > > Andy > > > > > > ---------------------------------------------- > > Weekly webex call details: > > Meeting number (access code): 171 069 0374 > > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > > https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c7= 0 > > Tap to join from a mobile device (attendees only) > > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --00000000000096058f05bff203d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 14, 2021 at 6:55 AM Bal= =C3=A1zs Lengyel <balazs.= lengyel@ericsson.com> wrote:

Hello Andy,

I remember when w= e wrote these rules, we were concentrating on config and did not spend much= time considering state data.

=C2=A0

There are rules that are good for= config but not for state. E.g.

  • RFC7950 does not allow changing the mandatory st= atement from false to true; as this could make a valid configuration that d= oes not include an optional leaf invalid.
  • On th= e other hand, changing a state leaf from mandatory false to true means alwa= ys including the leaf in a <get> response. That should be a compatibl= e change.

Do you agree, that= at least in some cases different compatibility rules for state and configu= ration data makes sense?


I = think this is a topic for the yang-next list.
There is a list of = about 100 issues that people would like to fix or change in YANG.
If the WG ever decides to work on yang-next then I will be happy to
<= div>participate in that work.

IMO the YANG-based a= pproach to dealing with NBC in the wild in not going to work.
Imp= rovements to the protocol will help but they are not in scope here.
Support for warnings would help real implementations right now.It was a mistake to remove (rather than fix) warnings in NETCONF (and now= =C2=A0also RESTCONF).


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Regards Balazs

=C2=A0

<= /div>

Andy
=C2=A0

From: netmod <netmod-bounces@ie= tf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
= Sent: 2021. =C3=A1prilis 13., kedd 20:30
To: Andy Bierman <= ;andy@yumaworks.com= >
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning Weekly= Call Minutes - 2021-04-13

=C2=A0

Hi = Andy,

<= u>=C2=A0

T= hx for taking a look.

=C2=A0

Yes - agree with the "orderly" comment. That was v= ery brief shorthand for the minutes. By "remove" it could even ju= st mean marking as "obsolete" (with deprecated as an optional int= ermediate step).

=C2=A0

We aren't trying to redefine the rules for config. But it is= worth considering whether some of those aren't really good for state.= =C2=A0 Implementations may be ignoring some of those rules for state becaus= e they don't really fit.

=C2=A0

Jason

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
S= ent: Tuesday, April 13, 2021 2:16 PM
To: Sterne, Jason (Nokia= - CA/Ottawa) <jason.sterne@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmo= d] YANG Versioning Weekly Call Minutes - 2021-04-13

=

=C2=A0

=C2=A0

= =C2=A0

On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@noki= a.com> wrote:

<= p class=3D"MsoNormal">YANG Versioning Weekly Call Minu= tes - 2021-04-13

=C2=A0

Primary discussion was around the BC/NBC rules for state.=

=C2=A0=

Value space f= or config false:

- more informative if you actually remove the enum from the mode= l if it isn't used anymore (vs leaving it in and servers just not retur= ning it)

- a server implementation should deviate if it doesn't return somethi= ng ever (schema should try to accurately define the API)

- standard module -> r= emove the item if it isn't part of the API anymore=

=C2=A0

=C2=A0

I assume you mean to use the status-stmt to transi= tion from current -> deprecated -> obsolete

<= /div>

in an orderly fashion= . Especially since sec 11 is very clear:

=C2=A0

=C2=A0=C2=A0 Obsolete definitions MUST NOT be removed from pub=
lished modules,
=C2=A0=C2=A0 since their identifiers may still be referenc=
ed by other modules.

=C2=A0

=C2=A0

=C2=A0

=

- NMDA o= perational DS has a copy of config true, so increased value space in config= automatically casues increased value space in "state" (operation= al)

- a= config true MTU in the operational DS and a dedicated config false "o= per-mtu" leaf should have the same rules for increasing value space=

=C2=A0=

Maybe a b= etter formulation of the state rules is to take the 7950 rules and apply mi= nimal text changes. Rob will take a stab at this.

<= p class=3D"MsoNormal">=C2=A0

<= p class=3D"MsoNormal">7950:

=C2=A0=C2=A0 o=C2=A0 A "must= " statement may be removed or its constraint relaxed.

=C2=A0=C2=A0 =

Adjusted 7950 te= xt:

=C2= =A0=C2=A0 o=C2=A0 A "must" statement may be added, removed, or ch= anged

= =C2=A0=C2=A0

=

=C2=A0<= /span>

7950:

=C2=A0=C2=A0 o=C2=A0 A= "range", "length", or "pattern" statement ma= y expand the allowed

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value space.

Adjusted 7950:=

=C2=A0=C2=A0 o= =C2=A0 A "range", "length", or "pattern" stat= ement may expand or reduce the allowed

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value space.=

=C2=A0

=C2=A0

I strongly object to this WG= creating an "adjusted YANG 1.1" standard.

IMO there is no ne= ed or WG consensus to create any sort of replacement for RFC 7950.

<= /u>=C2=A0

If YANG 1.1 needs non-backward-compatible changes=C2=A0 (which it do= esn't IMO) then a new

YANG 2.0 RFC must be written to accomplish th= at.

=C2=A0

It is possible to introduce support for NBC changes in a= way that does not change YANG 1.1

at all. E.g.:

=C2=A0

Rule 1 = of 1:

=C2=A0 - If any change is made that violates a MUST or MUST NOT = provision of RFC 7950,

=C2=A0 =C2=A0 sec. 11, then the major revision n= umber in the semver string MUST be incremented.

=C2=A0

=C2= =A0

=C2=A0

=C2=A0

Jason

=C2=A0=

Andy<= u>

=C2=A0

=C2=A0

------------------------------------------= ----

We= ekly webex call details:

Meeting number (access code): 171 069 0374 =

Meeting password: se= mver?

O= ccurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Aug= ust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & C= anada)

9:00 am=C2=A0 |=C2=A0 (UTC-04:00) Eastern Time (US & Canada)=C2=A0 |= =C2=A0 1 hr

https://ietf.webex.com/ietf/j.php?MTID= =3Dma7627a2ae7b770537cff5f5b89293c70

Tap to join from a mobile device (atten= dees only)

+1-650-479-3208,,1710690374## Call-in toll number (US/Canada)=

____= ___________________________________________
netmod mailing list
netmod@ietf.org
http= s://www.ietf.org/mailman/listinfo/netmod

--00000000000096058f05bff203d8-- From nobody Wed Apr 14 14:37:19 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 535AD3A20D4; Wed, 14 Apr 2021 14:37:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <161843623729.23262.16282069190540310015@ietfa.amsl.com> Date: Wed, 14 Apr 2021 14:37:17 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 21:37:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Common YANG Data Types Author : Juergen Schoenwaelder Filename : draft-ietf-netmod-rfc6991-bis-06.txt Pages : 41 Date : 2021-04-14 Abstract: This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6991. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6991-bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 14 17:51:48 2021 Return-Path: <01000178d30320e7-b744818a-bf65-40ef-b4bf-37578bed72d8-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 625603A26CF for ; Wed, 14 Apr 2021 17:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 iwzsK9WpU6v2 for ; Wed, 14 Apr 2021 17:51:42 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750DA3A26CD for ; Wed, 14 Apr 2021 17:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618447901; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=nncAafoq+ILcLJluRKLbI99ftqDEvb54TF6ee/yVhm0=; b=RrgbGOiYzUjq1H6V8xfyTn0I0cbINAyQ+J8GTL3BLu2a11tuoRvGu6p8uYPYQHDE h5wmrQsfoVfLEg9y12U+JyL6QXvOacyMNxHINHI5hvPj4gSLBll0+DFDdPcJogb/C0A uVij/Lc8vdPsnhamhD9b+3nMCy9boUcbPG8y3RPI= From: Kent Watsen Message-ID: <01000178d30320e7-b744818a-bf65-40ef-b4bf-37578bed72d8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BC9F5822-4B5E-451D-B8E9-DA942C38A926" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 15 Apr 2021 00:51:40 +0000 In-Reply-To: Cc: "netmod@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: <010001712ce4c5fe-04a059c3-ced3-4e6d-8389-5dd7c1257ac2-000000@email.amazonses.com> <010001712e483a1b-204d92e3-7046-46fb-b6b8-13d8ad4cb9ff-000000@email.amazonses.com> <0100017160917518-a18954f3-8e57-4286-904a-5a3e9779ff31-000000@email.amazonses.com> <010001788ff302da-dcb9dc37-8e63-4ba1-9f82-5584e0e4f49a-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.15-54.240.48.93 Archived-At: Subject: Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 00:51:47 -0000 --Apple-Mail=_BC9F5822-4B5E-451D-B8E9-DA942C38A926 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Balazs, Please find my comments below. K. > On Apr 7, 2021, at 9:56 AM, Bal=C3=A1zs Lengyel = wrote: >=20 > Hello Kent, > Thanks for the thorough review and sorry for my absence and hence the = earlier slow response. Join the club ;) > See answer below as BALAZS4. Removed already agreed parts. > What is the next step? Time for me to attempt the shepherd writeup again, and then publish it = for IESG review. K. > Regards Balazs > =20 > From: Kent Watsen >=20= > Sent: 2021. =C3=A1prilis 2., p=C3=A9ntek 2:20 > To: Bal=C3=A1zs Lengyel > > Cc: netmod@ietf.org > Subject: Re: [netmod] Shepherd review on = draft-ietf-netmod-yang-instance-file-format-10 > =20 > Please see below for responses. (One question pending) > =20 > Kent // shepherd >=20 > On Mar 23, 2021, at 6:01 PM, Bal=C3=A1zs Lengyel = > = wrote: > =20 > Hello Kent, > I am resuming my work on draft-ietf-netmod-yang-instance-file-format.=20= > Regards Balazs > =20 > =20 > From: Kent Watsen >=20= > Sent: 2020. =C3=A1prilis 9., cs=C3=BCt=C3=B6rt=C3=B6k 22:11 > To: Bal=C3=A1zs Lengyel > > Cc: netmod@ietf.org > Subject: Re: [netmod] Shepherd review on = draft-ietf-netmod-yang-instance-file-format-10 > =20 > Hi Balazs, > =20 > BTW, I assume that you wish to publish this as-is and follow-up later = with an update to adjust for the =E2=80=9Csemver=E2=80=9D work - = correct? > K. > =20 > BALAZS4: Yes, correct.=20 Ack. > Semver will take time and may undergo changes, so it would be too = early to adapt this draft/RFC to it. However, two items already deal = with Semver: > The instance data files themselves will not have a Semver revision as = the concept of compatibility is not defined for instance data. > The YANG module ietf-yang-instance-data already includes: > =E2=80=9C... If = other methods > (e.g., revision-label) are defined to identify > individual module revisions those MAY be used > instead of using a revision date.=E2=80=9D --Apple-Mail=_BC9F5822-4B5E-451D-B8E9-DA942C38A926 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Balazs,

Please find = my comments below.

K.


On Apr = 7, 2021, at 9:56 AM, Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello Kent,
Thanks for the thorough review and sorry for my = absence and hence the earlier slow = response.

Join = the club ;)


See = answer below as BALAZS4. Removed = already agreed parts.
What = is the next step?

Time for me to attempt the shepherd writeup again, = and then publish it for IESG review.

K.


Regards Balazs
 
From: Kent Watsen <kent+ietf@watsen.net> 
Sent: 2021. =C3=A1prilis 2., = p=C3=A9ntek 2:20
To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd = review on draft-ietf-netmod-yang-instance-file-format-10
 
Please= see below for responses.  (One question pending)
 
Kent = // shepherd

On Mar 23, 2021, at 6:01 = PM, Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:
 
Hello Kent,
I am resuming my work on = draft-ietf-netmod-yang-instance-file-format. 
Regards = Balazs
 
 
From: Kent Watsen <kent+ietf@watsen.net> 
Sent: 2020. =C3=A1prilis 9., = cs=C3=BCt=C3=B6rt=C3=B6k 22:11
To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd = review on draft-ietf-netmod-yang-instance-file-format-10
 

Hi Balazs,

 
BTW, = I assume that you wish to publish this as-is and follow-up later with an = update to adjust for the =E2=80=9Csemver=E2=80=9D work - correct?
K.
 
BALAZS4:  Yes, correct. 

Ack.


Semver will take time and = may undergo changes, so it would be too early to adapt this draft/RFC to = it. However, two items already deal with Semver:
  1. The instance data files themselves will not have a Semver = revision as the concept of compatibility is not defined for instance = data.
  2. The YANG module ietf-yang-instance-data already = includes:
 =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;  =E2=80=9C... If =
other methods
          &nb= sp;         (e.g., = revision-label) are defined to identify
          &nb= sp;         individual module = revisions those MAY be used
          &nb= sp;         instead of using a = revision = date.=E2=80=9D

= --Apple-Mail=_BC9F5822-4B5E-451D-B8E9-DA942C38A926-- From nobody Fri Apr 16 14:24:20 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D07FC3A35B7; Fri, 16 Apr 2021 14:24:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <161860825878.24957.3901876395372409910@ietfa.amsl.com> Date: Fri, 16 Apr 2021 14:24:18 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-geo-location-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 21:24:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : A YANG Grouping for Geographic Locations Author : Christian Hopps Filename : draft-ietf-netmod-geo-location-08.txt Pages : 25 Date : 2021-04-16 Abstract: This document defines a generic geographical location object YANG grouping. The geographical location grouping is intended to be used in YANG models for specifying a location on or in reference to Earth or any other astronomical object. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netmod-geo-location-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-geo-location-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 16 14:29:50 2021 Return-Path: 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 3363D3A35DC; Fri, 16 Apr 2021 14:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CJmXYIPcoDdz; Fri, 16 Apr 2021 14:29:44 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8FB3A35DB; Fri, 16 Apr 2021 14:29:44 -0700 (PDT) Received: from ja.int.chopps.org (066-227-211-029.res.spectrum.com [66.227.211.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1455A826A1; Fri, 16 Apr 2021 21:29:42 +0000 (UTC) From: Christian Hopps Message-Id: <1FBEE860-9624-45D2-9297-63A3913898FF@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_6CEE5495-A558-4EBD-84B4-985EDF056F9A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 16 Apr 2021 17:29:42 -0400 In-Reply-To: Cc: "netmod@ietf.org" , "draft-ietf-netmod-geo-location.all@ietf.org" To: "Rob Wilton (rwilton)" References: <55915FD1-7563-4058-96D8-AC4ED9A37957@chopps.org> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-geo-location-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 21:29:49 -0000 --Apple-Mail=_6CEE5495-A558-4EBD-84B4-985EDF056F9A Content-Type: multipart/alternative; boundary="Apple-Mail=_1FEA35A2-6E2C-460B-A709-910267D2F8A4" --Apple-Mail=_1FEA35A2-6E2C-460B-A709-910267D2F8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just posted this new version. > On Apr 13, 2021, at 6:08 AM, Rob Wilton (rwilton) = wrote: >=20 > Hi Chris, >=20 >> -----Original Message----- >> From: Christian Hopps > >> Sent: 13 April 2021 03:38 >> To: Rob Wilton (rwilton) > >> Cc: Christian Hopps >; = netmod@ietf.org ; draft-ietf- >> netmod-geo-location.all@ietf.org = >> Subject: Re: AD review of draft-ietf-netmod-geo-location-07 >>=20 >>=20 >>=20 >>> On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) >> wrote: >>>=20 >>> Hi Chris, >>>=20 >>> Apologies for the delayed AD review of this document. >>>=20 >>> I found that this document to be interesting, enlightening, and well >> written, so thank you. >>>=20 >>>=20 >>> I only have a few minor comments, the rest are grammatical nits. = Some I >> spotted manually; the rest are from a beta version of a grammar tool = that >> I am playing with. >>>=20 >>> Minor comments/questions: >>>=20 >>> 1. >>> In the YANG module, the pattern statements have 3 ranges of = characters, >>> but the description only indicates two ranges. Is there a reason = that >>> the following pattern doesn't work? >>> pattern '[ -@\[-~]*'; >>=20 >> =46rom an old email on the list: "These 3 ranges seem to make pyang = happy. I >> don't know why I need to break up the second range into 2 adjacent = ranges >> like that to make pyang not complain, but complain it does if I just = use: >> '[ -@\[-~]*'" > [RW] >=20 > Okay. >=20 >=20 >>=20 >>> 2. >>> I note that the YANG module allows just a lat, or a long, or a = height >>> to be specified, rather than requiring at least a pair of lat/long = or >>> x/y coordinates. I think that this is fine (and keeps the model >>> flexible), but wanted to check that this is the intentional. >>=20 >>> 3. >>> I also note that that grouping doesn't require that any coordinates = be >>> specified at all. I presume that this is intentional, it makes = sense >>> to me (e.g., if it is intended to be optional). >>=20 >> My answer to a thread on the list asking for removal of some of the >> mandatory designations which cause problems: >>=20 >> "The intention was for a location node to be required if the > location> container was present. Apparently this will only work if >> "container geo-lcoation" is a presence container. I'm not even sure = that's >> all that smart of a requirement (e.g., maybe someone just wants to >> indicate the reference-frame for an object). I'll remove the = mandatory >> from location." > [RW] >=20 > Okay. >=20 >=20 >>=20 >>=20 >>> 4. In the YANG module, >>> "v-east is the rate of change (i.e., speed) perpendicular >>> to truth-north as defined by the geodetic-system."; >>>=20 >>> As a nit, this doesn't actually define whether a positive v-east >>> value is in the East or West direction. I appreciate that this is >>> obvious, but for the other two components in the vector, it is >>> unambiguously specified. >>=20 >> How about: >>=20 >> "v-east is the rate of change (i.e., speed) = perpendicular >> to the right of truth-north as defined by >> the geodetic-system."; > [RW] >=20 > LGTM. >=20 >=20 >>=20 >>=20 >>>=20 >>> 5. >>> In Security Considerations: >>>=20 >>> Since the grouping defined in this module identifies locations, >>> authors using this grouping SHOULD consider any privacy issues that >>> may arise when the data is readable. >>>=20 >>> Perhaps, expand this paragraph to give an example, e.g., revealing >>> the physical location of a device, or data center. >>=20 >> How about: >>=20 >> "Since the grouping defined in this module identifies locations, >> authors using this grouping SHOULD consider any privacy issues >> that may arise when the data is readable (e.g., customer device >> locations, etc)." > [RW] >=20 > LGTM. >=20 >=20 >>=20 >>=20 >>>=20 >>> The rest are just grammar nits: >>>=20 >>>=20 >>> In addition to identifying the astronomical body we also need to >>> define the meaning of the coordinates >>> =3D> >>> In addition to identifying the astronomical body, we also need to >>> define the meaning of the coordinates >>=20 >> fixed >>=20 >>>=20 >>> In addition to the "geodetic-datum" value we allow refining the >>> coordinate and height accuracy using "coord-accuracy" and "height- >>> accuracy" respectively. >>> =3D> >>> In addition to the "geodetic-datum" value, we allow refinement of = the >>> coordinate and height accuracy using "coord-accuracy" and "height- >>> accuracy" respectively. >>=20 >> fixed >>=20 >>> This is the location on or relative to the astronomical object. It >>> is specified using 2 or 3 coordinates values. >>> =3D> >>> This is the location on, or relative to, the astronomical object. = It >>> is specified using 2 or 3 coordinates values. >>=20 >> fixed >>=20 >>> The intent of the grouping being defined here is to identify >>> where something is located, and generally this is expected to be >>> somewhere on or relative to Earth (or another astronomical body). >>> =3D> >>> The intent of the grouping being defined here is to identify >>> where something is located, and generally this is expected to be >>> somewhere on, or relative to, Earth (or another astronomical body). >>=20 >> fixed >>=20 >>> At >>> least two options are available to YANG models that wish to use = this >>> grouping with objects that are changing location frequently in non- >>> simple ways, they can add additional motion data to their model >>> directly, or if the application allows it can require more frequent >>> queries to keep the location data current. >>> =3D> >>> At >>> least two options are available to YANG models that wish to use = this >>> grouping with objects that are changing location frequently in non- >>> simple ways. They can add additional motion data to their model >>> directly. Or, if the application allows, it can require more = frequent >>> queries to keep the location data current. >>=20 >> fixed >>=20 >>> When coord-accuracy is specified it overrides the geodetic-datum = implied >>> accuracy. >>> =3D> >>> When coord-accuracy is specified, it overrides the geodetic-datum >> implied >>> accuracy. >>=20 >> fixed >>=20 >>>=20 >>> When specified it overrides the geodetic-datum implied default. >>> =3D> >>> When specified, it overrides the geodetic-datum implied default. >>=20 >> fixed >>=20 >>> indicated by the reference-frame value. >>> =3D> >>> indicated by the reference-frame. >>=20 >> fixed >>=20 >>> For a formula to convert these values to speed and heading see >>> this modules defining document RFC XXXX."; >>> =3D> >>> For a formula to convert these values to speed and heading see >>> RFC XXXX."; >>=20 >> fixed >>=20 >>> You have "truth-north" and "truth north" and "true-north". Should >>> these all be "true north"? >>=20 >> fixed >>=20 >>>=20 >>> YANG grouping using decimal64 values rather than strings. For the >>> relative height cases the application doing the transformation is >>> expected to have the data available to transform the relative = height >>> into an absolute height which can then be expressed using the YANG >>> grouping. >>> =3D> >>> YANG grouping using decimal64 values rather than strings. For the >>> relative height cases, the application doing the transformation is >>> expected to have the data available to transform the relative = height >>> into an absolute height, which can then be expressed using the YANG >>> grouping. >>=20 >> fixed >>=20 >>> Grammar Warnings (generated by a tool): >>> Draft Text: >>> Indeed it is easy to imagine a network or device located on The = Moon, on >> Mars, on Enceladus (the moon of Saturn) or even a comet (e.g., >> 67p/churyumov-gerasimenko). >>>=20 >>> Warning: Did you forget a comma after a conjunctive/linking adverb? >>> Suggested change: "Indeed," >>=20 >> fixed >>=20 >>>=20 >>> Draft Text: >>> This document defines a "geo-location" YANG grouping that allows for = all >> of the above data to be captured. >>>=20 >>> Warning: Consider using all the. >>> Suggested change: "all the" >>=20 >> fixed >>=20 >>> Draft Text: >>> When specified these values override the defaults implied by the >> "geodetic-datum" value. >>>=20 >>> Warning: "When" at the beginning of a sentence usually requires a = 2nd >> clause. Maybe a comma, question or exclamation mark is missing, or = the >> sentence is incomplete and should be joined with the following = sentence. >>> Suggested change: "When specified, " >>=20 >> fixed >>=20 >>> Draft Text: >>> In both choices the exact meanings of all of the values are defined = by >> the "geodetic-datum" value in the [xref]. >>>=20 >>> Warning: Consider using all the. >>> Suggested change: "all the" >>=20 >> fixed >>=20 >>> Draft Text: >>> During the development of this module, the question of whether it = would >> support data such as orientation arose. >>> Warning: Wordiness: Consider shortening this phrase. >>> Suggested change: "whether" >>=20 >> ? > [RW] >=20 > Ignore. >=20 >=20 >>=20 >>>=20 >>> Draft Text: >>> For test "A.1.2.1" the YANG geo location object either includes a = CRS >> ("reference-frame") or has a default defined ([xref]). >>>=20 >>> Warning: This word is normally spelled as one. >>> Suggested change: "geolocation" >>=20 >> unchanged. >>=20 >>> Draft Text: >>> Many systems make use of geo-location data, and so it's important to = be >> able describe this data using this geo-location object defined in = this >> document. >>>=20 >>> Warning: The preposition 'to' is required in front of the verb >> 'describe'. >>> Suggested change: "able to describe" >>=20 >> Removed this paragraph it's unneeded and not very clear. >>=20 >>>=20 >>> Draft Text: >>> For accuracy it has a single "u" parameter for specifying = uncertainty. >>> Warning: The comma is probably missing here: accuracy, it. >>> Suggested change: "accuracy, it" >>=20 >> fixed >>=20 >>> Draft Text: >>> This is used by many application (e.g., Google Maps API). >>>=20 >>> Warning: Possible agreement error. The noun application seems to be >> countable; consider using: many applications. >>> Suggested change: "many applications" >>=20 >> fixed >>=20 >>> Draft Text: >>> Thus GML "gml:pos" values can be mapped directly to the YANG = grouping, >> with the caveat that some loss of precision (in the extremes) may = occur >> due to the YANG grouping using decimal64 values rather than doubles. >>>=20 >>> Warning: Did you forget a comma after a conjunctive/linking adverb? >>> Suggested change: "Thus," >>=20 >> fixed >>=20 >>> Draft Text: >>> Furthermore "gml:validTime" can either be an Instantaneous measure >> ("gml:TimeInstant") or a time period ("gml:TimePeriod"). >>> Warning: Did you forget a comma after a conjunctive/linking adverb? >>> Suggested change: "Furthermore," >>=20 >> fixed >>=20 >>> Draft Text: >>> As with the "kml:altitudeMode" value, the YANG grouping supports the >> ignore case but not the relative case. >>>=20 >>> Warning: After 'the', do not use a verb. Make sure that the = spelling of >> 'ignore' is correct. If 'ignore' is the first word in a compound >> adjective, use a hyphen between the two words. Note: This error = message >> can occur if you use a verb as a noun, and the word is not a noun in >> standard English. >>=20 >> I think it just wants me to hyphenate "ignore-case". "ignore" is an >> adjective here "case" is the noun. *shrug*, I think it reads fine the = way >> it is for a technical document. > [RW] >=20 > Yes, please just ignore. The tool isn't perfect. >=20 >=20 >=20 >>=20 >>> Draft Text: >>> Thus the YANG grouping and KML values can be directly mapped in both >> directions (when using a supported altitude mode) with the caveat = that >> some loss of precision (in the extremes) may occur due to the YANG >> grouping using decimal64 values rather than strings. >>> Warning: Did you forget a comma after a conjunctive/linking adverb? >>> Suggested change: "Thus," >>=20 >> fixed >>=20 >>> Draft Text: >>> The allocation policy for this registry is First Come First Served, >> [xref] as the intent is simply to avoid duplicate values. >>>=20 >>> Warning: It seems that a comma is missing. >>> Suggested change: "Come," >>=20 >> fixed >>=20 >>> Draft Text: >>> All of the data nodes defined in this YANG module are >> writable/creatable/deletable (i.e., "config true", which is the = default). >>> Warning: Consider using all the. >>> Suggested change: "All the" >>=20 >> fixed >>=20 >>> Draft Text: >>> These are the subtrees and data nodes and their >> sensitivity/vulnerability: >>> None of the writable/creatable/deletable data nodes in the YANG = module >> defined in this document are by themselves considered more sensitive = or >> vulnerable then standard configuration. >>>=20 >>> Warning: Did you mean than? >>> Suggested change: "than" >>=20 >> fixed >>=20 >>> Draft Text: >>> Some of the readable data nodes in this YANG module may be = considered >> sensitive or vulnerable in some network environments. >>> Warning: If the text is a generality, 'of the' is not necessary. >>> Suggested change: "Some" >>=20 >> I think it's correct to leave this, but I could be misunderstanding = the >> advice. > [RW] >=20 > I think that either is probably fine/correct. >=20 >=20 >>=20 >>> Draft Text: >>> Below is a the YANG tree for the fictitious module that uses the = geo- >> location grouping. >>>=20 >>> Warning: Maybe you need to remove one determiner so that only a or = the >> is left. >>> Suggested change: "a" >>=20 >> fixed with "the" only. >>=20 >>>=20 >>> Draft Text: >>> We would also like to thank Peter Lothberg for the motivation as = well as >> help in defining a broadly useful geographic location object, and = Acee >> Lindem and Qin Wu for their work on a geographic location object that = led >> to this documents creation. >>>=20 >>> Warning: Possible typo: apostrophe is missing. Did you mean = documents' >> or document's? >>> Suggested change: "documents'" >>=20 >> fixed. >>=20 >> Nice tool! > [RW] >=20 > Thanks. >=20 > It needs a bit more time and work, but the hope is that it can be an = easy webtool that can be used by authors to help check the = grammar/spelling in their drafts. I don't want it to be an id-nits = style gatekeeper tool, because as you have seen, some of the = warnings/suggestions are somewhat arbitrary. Also, the real credit goes = to an open source grammar tool (dev.languagetool.org = ) that is doing all the heavy lifting. >=20 > Thanks, > Rob >=20 >=20 >>=20 >> Thanks, >> Chris. >>=20 >>=20 >>>=20 >>> Regards, >>> Rob --Apple-Mail=_1FEA35A2-6E2C-460B-A709-910267D2F8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = posted this new version.

On Apr 13, 2021, at 6:08 AM, = Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Chris,

-----Original Message-----
From: Christian Hopps <chopps@chopps.org>
Sent: 13 April 2021 = 03:38
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>; netmod@ietf.org; = draft-ietf-
netmod-geo-location.all@ietf.org
Subject: = Re: AD review of draft-ietf-netmod-geo-location-07



On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) <rwilton@cisco.com>
wrote:

Hi Chris,

Apologies= for the delayed AD review of this document.

I found that this document to be interesting, enlightening, = and well
written, so thank you.


I only have a few minor comments, the rest are grammatical = nits. Some I
spotted manually; the rest are = from a beta version of a grammar tool that
I am playing = with.

Minor comments/questions:

1.
In the YANG module, the pattern statements have 3 ranges of = characters,
but the description only indicates two ranges. =  Is there a reason that
the following pattern doesn't = work?
pattern '[ -@\[-~]*';

=46rom an old email on the list: "These 3 ranges seem to make = pyang happy. I
don't know why I need to break up the = second range into 2 adjacent ranges
like that to make = pyang not complain, but complain it does if I just use:
'[ = -@\[-~]*'"
[RW] 

Okay. 



2.
I note = that the YANG module allows just a lat, or a long, or a height
to be specified, rather than requiring at least a pair of = lat/long or
x/y coordinates.  I think that this is = fine (and keeps the model
flexible), but wanted to check = that this is the intentional.

3.
I also = note that that grouping doesn't require that any coordinates be
specified at all.  I presume that this is intentional, = it makes sense
to me (e.g., if it is intended to be = optional).

My answer to a = thread on the list asking for removal of some of the
mandatory designations which cause problems:

"The intention was for a location node to be required if the = <geo-
location> container was present. Apparently = this will only work if
"container geo-lcoation" is a = presence container. I'm not even sure that's
all that = smart of a requirement (e.g., maybe someone just wants to
indicate the reference-frame for an object). I'll remove the = mandatory
from location."
[RW] 

Okay.



4. In the = YANG module,
"v-east is the rate of change (i.e., speed) = perpendicular
to truth-north as defined by the = geodetic-system.";

As a nit, this doesn't = actually define whether a positive v-east
value is in the = East or West direction.  I appreciate that this is
obvious, but for the other two components in the vector, it = is
unambiguously specified.

How about:

          &nb= sp;  "v-east is the rate of change (i.e., speed) = perpendicular
          &nb= sp;   to the right of truth-north as defined by
          &nb= sp;   the geodetic-system.";
[RW] 

LGTM.




5.
In Security Considerations:

 Since the grouping defined in this module identifies = locations,
 authors using this grouping SHOULD = consider any privacy issues that
 may arise when the = data is readable.

Perhaps, expand this = paragraph to give an example, e.g., revealing
the physical = location of a device, or data center.

How about:

"Since the grouping = defined in this module identifies locations,
authors using = this grouping SHOULD consider any privacy issues
that may = arise when the data is readable (e.g., customer device
locations, etc)."
[RW] 

LGTM.




The rest are just grammar nits:


 In addition to identifying the = astronomical body we also need to
 define the meaning = of the coordinates
=3D>
 In addition = to identifying the astronomical body, we also need to
 define the meaning of the coordinates

fixed


 In = addition to the "geodetic-datum" value we allow refining the
 coordinate and height accuracy using "coord-accuracy" = and "height-
 accuracy" respectively.
=3D>
 In addition to the = "geodetic-datum" value, we allow refinement of the
 coordinate and height accuracy using "coord-accuracy" = and "height-
 accuracy" respectively.

fixed

 This is the = location on or relative to the astronomical object.  It
 is specified using 2 or 3 coordinates values.
=3D>
 This is the location on, or = relative to, the astronomical object.  It
 is = specified using 2 or 3 coordinates values.

fixed

 The intent of the grouping being defined here is to = identify
 where something is located, and generally = this is expected to be
 somewhere on or relative to = Earth (or another astronomical body).
=3D>
 The intent of the grouping being defined here is to = identify
 where something is located, and generally = this is expected to be
 somewhere on, or relative to, = Earth (or another astronomical body).

fixed

 At
 least two options are available = to YANG models that wish to use this
 grouping with = objects that are changing location frequently in non-
 simple ways, they can add additional motion data to = their model
 directly, or if the application allows = it can require more frequent
 queries to keep the = location data current.
=3D>
 At
 least two options are available to YANG models that = wish to use this
 grouping with objects that are = changing location frequently in non-
 simple ways. =  They can add additional motion data to their model
 directly.  Or, if the application allows, it can = require more frequent
 queries to keep the location = data current.

fixed

When = coord-accuracy is specified it overrides the geodetic-datum implied
accuracy.
=3D>
When = coord-accuracy is specified, it overrides the geodetic-datum
implied
accuracy.

fixed


When specified it overrides the geodetic-datum implied = default.
=3D>
When specified, it = overrides the geodetic-datum implied default.

fixed

indicated by the = reference-frame value.
=3D>
indicated by = the reference-frame.

fixed

For a = formula to convert these values to speed and heading see
this modules defining document RFC XXXX.";
=3D>
For a formula to convert these values = to speed and heading see
RFC XXXX.";

fixed

You have "truth-north" = and "truth north" and "true-north".  Should
these all = be "true north"?

fixed


 YANG grouping using decimal64 values rather than = strings.  For the
 relative height cases the = application doing the transformation is
 expected to = have the data available to transform the relative height
 into an absolute height which can then be expressed = using the YANG
 grouping.
=3D>
 YANG grouping using decimal64 values rather than = strings.  For the
 relative height cases, the = application doing the transformation is
 expected to = have the data available to transform the relative height
 into an absolute height, which can then be expressed = using the YANG
 grouping.

fixed

Grammar Warnings = (generated by a tool):
Draft Text:
Indeed it = is easy to imagine a network or device located on The Moon, on
Mars, on Enceladus (the moon of Saturn) or even = a comet (e.g.,
67p/churyumov-gerasimenko).

Warning: =  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Indeed,"

fixed


Draft = Text:
This document defines a "geo-location" YANG grouping = that allows for all
of the above data to be = captured.

Warning:  Consider using all the.
Suggested = change:  "all the"

fixed
Draft = Text:
When specified these values override the defaults = implied by the
"geodetic-datum" value.

Warning: =  "When" at the beginning of a sentence usually requires a 2nd
clause. Maybe a comma, question or exclamation = mark is missing, or the
sentence is incomplete and should = be joined with the following sentence.
Suggested change: "When specified, "

fixed

Draft Text:
In both choices the exact meanings of all of the values are = defined by
the "geodetic-datum" value in the = [xref].

Warning:  Consider using all the.
Suggested = change:  "all the"

fixed
Draft = Text:
During the development of this module, the question = of whether it would
support data such as = orientation arose.
Warning:  Wordiness: Consider shortening this phrase.
Suggested change:  "whether"

?
[RW] 

Ignore.




Draft Text:
For = test "A.1.2.1" the YANG geo location object either includes a CRS
("reference-frame") or has a default defined = ([xref]).

Warning:  This word is normally spelled as one.
Suggested change:  "geolocation"

unchanged.

Draft Text:
Many systems make use of geo-location data, and so it's = important to be
able describe this data using = this geo-location object defined in this
document.

Warning: =  The preposition 'to' is required in front of the verb
'describe'.
Suggested change:  "able to describe"

Removed this paragraph it's = unneeded and not very clear.


Draft Text:
For = accuracy it has a single "u" parameter for specifying uncertainty.
Warning:  The comma is probably missing here: accuracy, = it.
Suggested change:  "accuracy, it"

fixed

Draft Text:
This is used by many application (e.g., Google Maps API).

Warning:  Possible agreement error. The = noun application seems to be
countable; = consider using: many applications.
Suggested change:  "many applications"

fixed

Draft Text:
Thus GML "gml:pos" values can be mapped directly to the YANG = grouping,
with the caveat that some loss of = precision (in the extremes) may occur
due to the YANG = grouping using decimal64 values rather than doubles.

Warning: =  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Thus,"

fixed

Draft Text:
Furthermore "gml:validTime" can = either be an Instantaneous measure
("gml:TimeInstant") or a time period = ("gml:TimePeriod").
Warning:  Did you forget a comma after a = conjunctive/linking adverb?
Suggested change: =  "Furthermore,"

fixed

Draft = Text:
As with the "kml:altitudeMode" value, the YANG = grouping supports the
ignore case but not the = relative case.

Warning:  After 'the', do not use a verb. Make sure that = the spelling of
'ignore' is correct. If = 'ignore' is the first word in a compound
adjective, use a = hyphen between the two words. Note: This error message
can = occur if you use a verb as a noun, and the word is not a noun in
standard English.

I think it = just wants me to hyphenate "ignore-case". "ignore" is an
adjective here "case" is the noun. *shrug*, I think it reads = fine the way
it is for a technical document.
[RW] 

Yes, please = just ignore.  The tool isn't perfect.




Draft Text:
Thus the YANG = grouping and KML values can be directly mapped in both
directions (when using a supported altitude = mode) with the caveat that
some loss of precision (in the = extremes) may occur due to the YANG
grouping using = decimal64 values rather than strings.
Warning:  Did you forget a comma after a = conjunctive/linking adverb?
Suggested change: =  "Thus,"

fixed

Draft = Text:
The allocation policy for this registry is First = Come First Served,
[xref] as the intent is = simply to avoid duplicate values.

Warning:  It seems that a comma is = missing.
Suggested change:  "Come,"

fixed

Draft Text:
All of the data nodes defined in this YANG module are
writable/creatable/deletable (i.e., "config = true", which is the default).
Warning:  Consider using all the.
Suggested = change:  "All the"

fixed
Draft = Text:
These are the subtrees and data nodes and their
sensitivity/vulnerability:
None of the = writable/creatable/deletable data nodes in the YANG module
defined in this document are by themselves = considered more sensitive or
vulnerable then standard = configuration.

Warning:  Did you mean than?
Suggested = change:  "than"

fixed

Draft = Text:
Some of the readable data nodes in this YANG module = may be considered
sensitive or vulnerable in = some network environments.
Warning:  If the text is a generality, 'of the' is not = necessary.
Suggested change:  "Some"

I think it's correct to leave = this, but I could be misunderstanding the
advice.
[RW] 

I think that = either is probably fine/correct.



Draft Text:
Below is a the YANG = tree for the fictitious module that uses the geo-
location grouping.

Warning:  Maybe you need to = remove one determiner so that only a or the
is = left.
Suggested = change:  "a"

fixed with = "the" only.


Draft Text:
We would also like = to thank Peter Lothberg for the motivation as well as
help in defining a broadly useful geographic = location object, and Acee
Lindem and Qin Wu for their work = on a geographic location object that led
to this documents = creation.

Warning:  Possible typo: apostrophe is missing. Did you = mean documents'
or document's?
Suggested change: =  "documents'"

fixed.

Nice tool!
[RW] 

Thanks.

It needs a bit more time and work, but the hope is that it = can be an easy webtool that can be used by authors to help check the = grammar/spelling in their drafts.  I don't want it to be an id-nits = style gatekeeper tool, because as you have seen, some of the = warnings/suggestions are somewhat arbitrary.  Also, the real credit = goes to an open source grammar tool (dev.languagetool.org) that is = doing all the heavy lifting.

Thanks,
Rob



Thanks,
Chris.



Regards,
Rob

= --Apple-Mail=_1FEA35A2-6E2C-460B-A709-910267D2F8A4-- --Apple-Mail=_6CEE5495-A558-4EBD-84B4-985EDF056F9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmB6AcYACgkQLh2DDte4 MCWk5A/8DttJDgtWHZBuQJCjAy6kVpW8lgL08dQk5ptsLM8NoJBPNKZI19icZg8W 7mdW8Wp0R/cw8vBS0AYCZMLGmvM863M5KLGzdWcRuxKfc1h3rVaVS9t9n66HHumX AX/5I33cjlJB4YYj/9gLE4F2JiIRmhNbrTV9vq8PYCfEzctG6QnBaKflPZ7NZGWM W1HCfXhjxO9QH4G53wf+PCDfWIHxXlev4k/LFBkgzq7AEbVx1ythkgo7WzIQK1iu +bFx6TnKLlokrcv5OXsnEbgVNu7ozZv1NZb1zUE6uqVNpDzSKDhzO78iI8Rh6Ld3 FMRINsspW8PUsWh2B0Kx4PulLC+Vlvbb4PVNt2ywveBp/+rK14IURX7wEWSGKdhr M3781ku7IN9CGKC78AAwKs023WjclmhNpR4Ww5URmMfBD7fNRoNsTE7EteUOXjyp YlS4VA58/7ZKvw3p2xlWL6V9OdCcF4YAkx0wRtPIjGZkD4MdA6b+g5dSVp8HUuOl bsQjgZHmw4qcuoN9LOdxyiSl9nNpTlBT2IpXVnnWXVZSn3wYWAvB6SbYbFgqaxoj fe9F6j2AcScDbeHhtRhhnqf0JI9CSqpfUGOZ8R2VE6oxfP9YX8Hx16ji0uatNrCY XeECpGvyqye5124U7PX+i7CZmU5qdYd4hr28ZUwEWTf3LvlQ5PY= =i8C5 -----END PGP SIGNATURE----- --Apple-Mail=_6CEE5495-A558-4EBD-84B4-985EDF056F9A-- From nobody Mon Apr 19 01:52:31 2021 Return-Path: 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 BEE643A0F0C; Mon, 19 Apr 2021 01:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.017 X-Spam-Level: X-Spam-Status: No, score=-10.017 tagged_above=-999 required=5 tests=[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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Dyqf4VKP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=M3aHwRZn 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 qnFsMWoNAZOP; Mon, 19 Apr 2021 01:52:23 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8C83A2A4D; Mon, 19 Apr 2021 01:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60291; q=dns/txt; s=iport; t=1618822302; x=1620031902; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C/x/0umAXg4Kf2pbvvoZ7UwaOsZhZIbRIjR/rN1Eed0=; b=Dyqf4VKP5HUII/rdxVCZGaCQBv4qbZhYKjway9SX3Roaf63/qsaPOWgt gQ8fknBUi8a7D0r8H0y2ltmKkyb+zCeeQ3eaeyNdVvli/cOn1UCbnEXa7 2liYYi2+ZpD7jimvSfjGkNKdDF8rUKm+CTG3AP2gg0Y6jnTubngYGWyNK E=; IronPort-PHdr: =?us-ascii?q?A9a23=3ASWbnbBEZDqFCVOKPHag+E51GftQY04WcBSYc9?= =?us-ascii?q?4YnhrRSc6+q45XlOgnF6O5wiEPSNa3Q6/Vck/GQtLrvCiQM4peE5XYFdpEEF?= =?us-ascii?q?xoIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFbSpWWq9ngVA?= =?us-ascii?q?BqsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3w?= =?us-ascii?q?RzM8RN1?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AWTcL1avKxG/Bn8dv5QIL9alv7skCJIcji2?= =?us-ascii?q?hD6mlwRA09T+WxrOrrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOgLU5FYyJGC?= =?us-ascii?q?3ronGhIo0n14vtxDX8Bzbzn9Qy6Y5JSII7MtH5CDFB4vrSyAOzH888hPyO96?= =?us-ascii?q?61jenTpk0dMj1CQYsI1XYfNi+wFEpqSA5aQb8wE5SB7sRKzgDQB0g/RMK9G3?= =?us-ascii?q?UDQqz/t8TG/aiWLyIuKjwGzE21jT2u4KPnCBTw5Hcjeh5G3LtKyxm/ryXX/a?= =?us-ascii?q?Om2svLryP092iW1JhOncuk990rPr3xtuEwChHBzjmlf55gXbrqhkF1nMiK5E?= =?us-ascii?q?wxmNfB5zcMVv4DkU/5RW2+rRvz1wSI6l9HgBWOpS768BneiPf0Sz4gB81KiZ?= =?us-ascii?q?gxSGql12MboNp+3KhXtljp0aZ/MBLakCzxo/jOWh16/3DE2UYKrO8Jg3RTFb?= =?us-ascii?q?YZcb9axLZvhX99LZFoJlOf1KkXVM1VSO3M7vdfdl2XK1rDuHN0/dCqVnMvWj?= =?us-ascii?q?+bX0kroKWuonhrtUE863Fd6N0Un38G+p54YYJD/f74PqNhk6wLZtMKbJh6GP?= =?us-ascii?q?wKTaKMey/waCOJFFjXDUXsFakBNX6IgYXw+q8J6Oajf4FN65cuhpLbUhd9uX?= =?us-ascii?q?Qpc0zjTe2Ctac7sCzlcSGYZ3DA28te7592tvnXX7zwKxCOT1gojo+uuPMaDs?= =?us-ascii?q?rHW+uiOZ5fDvP5RFGeXbph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6jafZ?= =?us-ascii?q?/oVf3QOAdhflm6LmoIXTD1KskFxFusQGXEjB/YXG6ofkT++Jl3AbXL5uR78v?= =?us-ascii?q?lKCqR89iwuzXip7MCCLjNP9oYselFlHb/hmqSn4W+s/WjJ6G1tMgFHDllc5a?= =?us-ascii?q?jhV38in35OD2rENZI4//mPc2Fb23WKYjVlSdnNLQJZr1Nrvb6sI4eI3iAkAd?= =?us-ascii?q?K/Omech38ezUj6Fqs0q+mm34PIa5k4BpEpVOhNDg3NDQVyghsvgnxEchU4Sk?= =?us-ascii?q?jWES7Oha2pgIcPPvzWc8BxjW6QUJZpgEOakX/ZhMk0AlMHQjalUKes8HcTbg?= =?us-ascii?q?sRomc0zogyr/6rny21JW42neIiWWc8GFi/MfZhFwSKZIJdh7bxXhp/JF363g?= =?us-ascii?q?CyulUUZnfg8VkUiyjHKyCZEMu7X2Z1izR/zrvg9k9yeyGmW39ILlp+sYF7CA?= =?us-ascii?q?39yyxO+OeWe6u+1HaQYFMewucbdCrIeycWPxkG/aHF6DeF3DmFDnko3ZMoI6?= =?us-ascii?q?jUC6kiaaja3je3JJSPjrxuJY4YwL91cNTvuPQMS+SRZkucKy75Efog32Wu1z?= =?us-ascii?q?0YETgxrHkvivXz3hL5qGC+wX4kGPLXZFBrXasSLd3Z72/qQZ+zod9EpMNwue?= =?us-ascii?q?u7KWPqbNGajanRcj5YMxvW5XesUPtAk+EjgYsi8L9oW5XLWzrB039KmB04Mc?= =?us-ascii?q?fvjUsbBKB2+qrININjd9EbEhgpsmYBhZCKNg8mowb2CugxcRU2g3jXM8iA7r?= =?us-ascii?q?DIpbAsa3fx7DfYKB2a6WlQ7v3FVyyM2foGEKo2O31Rc1V553J4/u+OHregRz?= =?us-ascii?q?mCZqVG5h69PXC8erMGF/TAFrUUsxpg49aH2+WQbDH13QjMvT19ZqJCmlzXNf?= =?us-ascii?q?+aEUaJA6pP9df/JFGHxq2t68S3hC3sSTS6Z18D7Lc1PHA4f4BGkH06kIYz0i?= =?us-ascii?q?KuUaT5rUIujktG7Vhc5yvQ85nj5H2eAFpPPgLYiIhHRDVfMnCHisLe7OiTvU?= =?us-ascii?q?6NlwRtyN3ED0dfftZHBtgWQMz2Nk5VWLotgII=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUBgCmQ31g/5BdJa1QChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFSgSMwIy4Hd1o2MQuIAAOFOYhwA48oihWBQoERA1QLAQE?= =?us-ascii?q?BDQEBJA4CBAEBhFACgXQCJTgTAgMBAQwBAQUBAQECAQYEcROFIwglDYZEAQE?= =?us-ascii?q?BBBoTEwEBNwELBAIBCA4DBAEBIQEGBzIUCQgBAQQOBQiCaoF+VwMvAQNJnkQ?= =?us-ascii?q?Cih93gTSBAYIEAQEGhSoYghMJgTqCeIQJhlQnHIFJQoETQ4JfPoJgBIEpAQc?= =?us-ascii?q?LAQccNAiDD4IrgVgGDFoGAjwCJAEDFAQyCAUeNToHRQEZBQYBAQENGUmQNwK?= =?us-ascii?q?LRoNSiSuRYgqDDIlohk2MeoNPin+WNKEOkmUECw4VhDMCBAIEBQIOAQEGgSM?= =?us-ascii?q?eKiM5MHBwFTuCaQlHFwIOiVqERQwWg06FFIVJczgCBgoBAQMJfIsDAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.82,233,1613433600"; d="scan'208,217";a="617114261" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Apr 2021 08:51:41 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 13J8pf93013855 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 19 Apr 2021 08:51:41 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 19 Apr 2021 03:51:41 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 19 Apr 2021 03:51:40 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 19 Apr 2021 03:51:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hQG2EAdq2l28X+lReLfoDXyn1uj9le0zf9zaX/sq/Fizd8UoJ8kXfjpHTFzhsHYak1IqDvn4I9+kErb2mHWIoOb30KHk0pEpf1n475Tt7W08YH4vokjb+pr5S6LRBz7Vivx9LOkmf8+ZLvNudGFwjC/46lk09o1rJ2d0wPFPCcrDYxX5a1KQ1Gi7ew7UbGKp72Bqn8+yvaQTxSMv6ZaUHBpLm01iwwU68t8xI9LHpXAX54y6S/LhqFsrrJDIuYqCgJHkkQ/6ZWqy5QcxnNYzGfBg3334Oc3BLGzrpGISZRQwfBY7nD76HIXd+CwZoflt15xC3oT4dyP1VUOyOX1bPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2UcgtYr4/ozsawnXEYyR18zVPSCerkTxRoXHh0ySQTk=; b=Y/9uszSvzG7x7TIEZ955AjHPiv9Pz0qHM6OMCtD/yhN6pYS23LJ+vZainKjJqwmpbUjGuRKHgp7yV8DTK9JNYxXlw784WWAdwcHDrf0KkkfFnaOxwRnd5VaN+0tVhFGl+w9Ia54xRMng8id67PhjaEiZgmdlLRE+nz1zIiW2Ul9hxWwgaoHA5iEY33wP15t0jayMqMCCiqC8XkjcQc1y0TPuOxrkDcQF5OU059s4kPNNZCAPPgQmTzPlLwO0UpEMurIrv41NqafBlbTHNoQEL+TwtC7d1rUZLytcT2yts3d7uWfXPEy6ihnNEP+O8DRgj1v+98Xiv1lm1Rf594fMww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2UcgtYr4/ozsawnXEYyR18zVPSCerkTxRoXHh0ySQTk=; b=M3aHwRZnzzzgT4H/H7YLRiscSXH2Lp2clnUE1kwGVy1ZUPZPPMx25UFhwqd46sk0AHO6iU2kM+l65/ZnYxOPksKYGyoI2BWQ4+oN0k/Gn/FUDsJmsAOWDTj2m9dpUGTg1vm/jcOJzGGHqnc3amD4KXPxUatF8jyjVJUwv8LhGZg= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4581.namprd11.prod.outlook.com (2603:10b6:208:26c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18; Mon, 19 Apr 2021 08:51:37 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::217d:4810:6cea:ef72]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::217d:4810:6cea:ef72%6]) with mapi id 15.20.4042.024; Mon, 19 Apr 2021 08:51:36 +0000 From: "Rob Wilton (rwilton)" To: Christian Hopps CC: "netmod@ietf.org" , "draft-ietf-netmod-geo-location.all@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-geo-location-07 Thread-Index: AdcTkShqN1Smhf9ATFKg3L8WBycm5QcfOVmAAA4md6AAsD1LAAB8XPag Date: Mon, 19 Apr 2021 08:51:36 +0000 Message-ID: References: <55915FD1-7563-4058-96D8-AC4ED9A37957@chopps.org> <1FBEE860-9624-45D2-9297-63A3913898FF@chopps.org> In-Reply-To: <1FBEE860-9624-45D2-9297-63A3913898FF@chopps.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4942c577-527f-4a69-a782-08d903105759 x-ms-traffictypediagnostic: MN2PR11MB4581: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WeRsQwDLfI0LJzvzMgnjMdw0aPySiYbP08Z+sONyZOorQEpyEXzP60aZxRlvO/uM4fnorGAyI4NbgM4fgp1en3tWrjvZ1qsDilX3Di9MeRAjDQJEnOLTYicTI9oC7ds+7HceKyT5MF1gxPh7JbzYarKyoE/LOo8RLXNHjrM2uk/Vuuh35ailA/cgdKJ9hwEijTMmEwbNWzeVlE6fTOGW/oMyJVnKL5eJwJ1rnC6HXO0a3KZDpD/9fNcqUCh9IHqp+heEi5G4UVPq6A2cKgO3cf+568rgkY3/i9K79ySnquiJhfD6YUWuFFaJYAePRc9/UBddKLpA8XYlEgjhLMJhpQA69ZIb2psqWb0ttTSPbxaEjNUIGrtOsi0EZAkXKr68Jd9HEuMfOkl1lG99jpCG+Is2XcvIbungZb89gloxNmd76Ff2F+0MpylxlKfYSJh/a2kH4pYbZOE5rlDFHlN1sWeLSZIu0vnqi73lUw4dGp6ES5E6MuJlJFhhjyqizTUVziZcYWz8TX881qNJi72Ne3fV6n4TvwF/LGNyoHkdwlpyrB6ikTuf8fb5ITka2utRjY5HiPzd2RAg3l1Y9gC5b2TCnphfuCDPCsTHHzPUcibuSut0AgacdyapIjaUV01Tf0/LQU31+MO1NF7M/fbuf9oksV28WOlVG1b1sl5ax3o5ZPfjRb6uweDSSZ0MT2+7 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(39860400002)(136003)(366004)(346002)(66446008)(38100700002)(66476007)(122000001)(478600001)(64756008)(55016002)(33656002)(66556008)(6506007)(8676002)(8936002)(30864003)(7696005)(9686003)(53546011)(166002)(54906003)(5660300002)(316002)(86362001)(71200400001)(2906002)(83380400001)(9326002)(4326008)(6916009)(66946007)(186003)(52536014)(76116006)(26005)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?kJJWVsvseY/FTWMQPVv1Ys8TMHrFfFzyIIXrysfOrmAw1GyUNZBjm6OeMpuL?= =?us-ascii?Q?e1sFwbGwGtnNrXtxCHwKgogExdG6L0kNlVNxhNAzFhLJjdEirMzqmnGSmEMS?= =?us-ascii?Q?BVOUNpQ4xnBbv6SrXJ1xvo2LV9u/kukcwQ11Sge1JULt04CO7vriMkjQQ9A7?= =?us-ascii?Q?2IrnBJ94IPilYVoR71hBKrRw9w/SnS1qBeTBgFkFYYZVftzxGizJuETrbZPS?= =?us-ascii?Q?4g5A55S0UCVVTofuUX6GaCs47v1XG2luaVajU6H4n8TNJG/9Ff0hqbrEokf6?= =?us-ascii?Q?YEE1JeidDPqoRA+sRgmz1iEp2pRLfabQ1byPRrN6NErwohkZ3N8KUpTTPbJK?= =?us-ascii?Q?6YK9TK0od8lpejHWjeSx6wqKsFJ4nuem290e+/oRcTBj+YKhVUnsrf89tMoS?= =?us-ascii?Q?WJiJMyGW9vGuF/lgMnU6zNSYM+N+cRt8LENwngWdDULrXodcJyq2WPcTUhlF?= =?us-ascii?Q?tECedLUt79zySQEqE32P4pn6vv6Aa+GwY9NWb1fip+ZkOAUxu4F9tNJhIwBi?= =?us-ascii?Q?huOJzlJOxYlbFMATfLbM2MRytHmM0PJEMUOQxVo6zHweFoRsnPm2FDnRpfgc?= =?us-ascii?Q?ps35rUBa7Zy0F9U57G9pOZtZYHue4aME8J9GbzJgtyGxsSpIZBbV1Ci3CQ9M?= =?us-ascii?Q?tDl6LEwfJmNYU4Ue/cs/llTGg1qithbAoP8hhaIy4z64NMJ0YZcjXXieLK78?= =?us-ascii?Q?eazAP8yicS7Y51V8NWnljM8ODnZNSdVm0a9yhcPJoQ4IWPBHFj+v48IuRisp?= =?us-ascii?Q?OMQyvZZFxN1aCapn+9qteX1LH2V0E64jLyklZP3LK7Bee2DRMHoI76gJ6ysZ?= =?us-ascii?Q?nB6AARqco2PoN4zfPmMi6pvixhy4S3tslKhCCNBrzK6ydL/qp1G5GEMoTLkO?= =?us-ascii?Q?wwdVCPlYHJSzs+ToMXomn5uHStlChBtfmZpvaUYcIKQ5FPU8ywa/8mkePk+/?= =?us-ascii?Q?pULvt0JLgtqzrCUVxAmrJ7pBqjWEkz/9dIb/4M+u90Dy/+vjKfVjI1PhVS1S?= =?us-ascii?Q?mFVSizkWNSVwskNH5hkOs1BGhRFZ6qF513lQvi9xD6+ltaJb5sgLGRY8sXSf?= =?us-ascii?Q?En34ilR124odm7jMrBlZkBJEcUJIsdPQ0+fUQukQtz6IDk/fbeHO71Q4S0Zz?= =?us-ascii?Q?1s1ghXDbh72RNhxXDhtalvVvPs7+cB9Ycbkij9tIC7/qYdX3yaKsiIuW6E4m?= =?us-ascii?Q?vt2ik6SLsXjDysc+Zb0wF5ZEN35VQLGtnfH3KgYuWWa5D0QDbhj2ylHjiV1s?= =?us-ascii?Q?FDlJGNwMwPvpiG4lhqaMQOCgn4lqIZ32A1qT0wiF+hF7/kXI3kwdTslHA/kj?= =?us-ascii?Q?5WP1cTBAoUJzCnIIbxaDBBP8?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43663F7D9BCE02D10F2D5837B5499MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4942c577-527f-4a69-a782-08d903105759 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2021 08:51:36.8040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H38GRF8tJx42AKzN47mK3kV+U45bFGi1saAgUeJBsvnR9XNlzRTuikogtY5qDNUlSbnmVux7I7eCPbCuDr5VSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4581 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-geo-location-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 08:52:30 -0000 --_000_MN2PR11MB43663F7D9BCE02D10F2D5837B5499MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, Thank you and the WG for your work on this document. I've requested IETF L= C. Regards, Rob From: Christian Hopps Sent: 16 April 2021 22:30 To: Rob Wilton (rwilton) Cc: netmod@ietf.org; draft-ietf-netmod-geo-location.all@ietf.org Subject: Re: AD review of draft-ietf-netmod-geo-location-07 Just posted this new version. On Apr 13, 2021, at 6:08 AM, Rob Wilton (rwilton) > wrote: Hi Chris, -----Original Message----- From: Christian Hopps > Sent: 13 April 2021 03:38 To: Rob Wilton (rwilton) > Cc: Christian Hopps >; netmod@i= etf.org; draft-ietf- netmod-geo-location.all@ietf.org Subject: Re: AD review of draft-ietf-netmod-geo-location-07 On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) > wrote: Hi Chris, Apologies for the delayed AD review of this document. I found that this document to be interesting, enlightening, and well written, so thank you. I only have a few minor comments, the rest are grammatical nits. Some I spotted manually; the rest are from a beta version of a grammar tool that I am playing with. Minor comments/questions: 1. In the YANG module, the pattern statements have 3 ranges of characters, but the description only indicates two ranges. Is there a reason that the following pattern doesn't work? pattern '[ -@\[-~]*'; >From an old email on the list: "These 3 ranges seem to make pyang happy. I don't know why I need to break up the second range into 2 adjacent ranges like that to make pyang not complain, but complain it does if I just use: '[ -@\[-~]*'" [RW] Okay. 2. I note that the YANG module allows just a lat, or a long, or a height to be specified, rather than requiring at least a pair of lat/long or x/y coordinates. I think that this is fine (and keeps the model flexible), but wanted to check that this is the intentional. 3. I also note that that grouping doesn't require that any coordinates be specified at all. I presume that this is intentional, it makes sense to me (e.g., if it is intended to be optional). My answer to a thread on the list asking for removal of some of the mandatory designations which cause problems: "The intention was for a location node to be required if the container was present. Apparently this will only work if "container geo-lcoation" is a presence container. I'm not even sure that's all that smart of a requirement (e.g., maybe someone just wants to indicate the reference-frame for an object). I'll remove the mandatory from location." [RW] Okay. 4. In the YANG module, "v-east is the rate of change (i.e., speed) perpendicular to truth-north as defined by the geodetic-system."; As a nit, this doesn't actually define whether a positive v-east value is in the East or West direction. I appreciate that this is obvious, but for the other two components in the vector, it is unambiguously specified. How about: "v-east is the rate of change (i.e., speed) perpendicular to the right of truth-north as defined by the geodetic-system."; [RW] LGTM. 5. In Security Considerations: Since the grouping defined in this module identifies locations, authors using this grouping SHOULD consider any privacy issues that may arise when the data is readable. Perhaps, expand this paragraph to give an example, e.g., revealing the physical location of a device, or data center. How about: "Since the grouping defined in this module identifies locations, authors using this grouping SHOULD consider any privacy issues that may arise when the data is readable (e.g., customer device locations, etc)." [RW] LGTM. The rest are just grammar nits: In addition to identifying the astronomical body we also need to define the meaning of the coordinates =3D> In addition to identifying the astronomical body, we also need to define the meaning of the coordinates fixed In addition to the "geodetic-datum" value we allow refining the coordinate and height accuracy using "coord-accuracy" and "height- accuracy" respectively. =3D> In addition to the "geodetic-datum" value, we allow refinement of the coordinate and height accuracy using "coord-accuracy" and "height- accuracy" respectively. fixed This is the location on or relative to the astronomical object. It is specified using 2 or 3 coordinates values. =3D> This is the location on, or relative to, the astronomical object. It is specified using 2 or 3 coordinates values. fixed The intent of the grouping being defined here is to identify where something is located, and generally this is expected to be somewhere on or relative to Earth (or another astronomical body). =3D> The intent of the grouping being defined here is to identify where something is located, and generally this is expected to be somewhere on, or relative to, Earth (or another astronomical body). fixed At least two options are available to YANG models that wish to use this grouping with objects that are changing location frequently in non- simple ways, they can add additional motion data to their model directly, or if the application allows it can require more frequent queries to keep the location data current. =3D> At least two options are available to YANG models that wish to use this grouping with objects that are changing location frequently in non- simple ways. They can add additional motion data to their model directly. Or, if the application allows, it can require more frequent queries to keep the location data current. fixed When coord-accuracy is specified it overrides the geodetic-datum implied accuracy. =3D> When coord-accuracy is specified, it overrides the geodetic-datum implied accuracy. fixed When specified it overrides the geodetic-datum implied default. =3D> When specified, it overrides the geodetic-datum implied default. fixed indicated by the reference-frame value. =3D> indicated by the reference-frame. fixed For a formula to convert these values to speed and heading see this modules defining document RFC XXXX."; =3D> For a formula to convert these values to speed and heading see RFC XXXX."; fixed You have "truth-north" and "truth north" and "true-north". Should these all be "true north"? fixed YANG grouping using decimal64 values rather than strings. For the relative height cases the application doing the transformation is expected to have the data available to transform the relative height into an absolute height which can then be expressed using the YANG grouping. =3D> YANG grouping using decimal64 values rather than strings. For the relative height cases, the application doing the transformation is expected to have the data available to transform the relative height into an absolute height, which can then be expressed using the YANG grouping. fixed Grammar Warnings (generated by a tool): Draft Text: Indeed it is easy to imagine a network or device located on The Moon, on Mars, on Enceladus (the moon of Saturn) or even a comet (e.g., 67p/churyumov-gerasimenko). Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Indeed," fixed Draft Text: This document defines a "geo-location" YANG grouping that allows for all of the above data to be captured. Warning: Consider using all the. Suggested change: "all the" fixed Draft Text: When specified these values override the defaults implied by the "geodetic-datum" value. Warning: "When" at the beginning of a sentence usually requires a 2nd clause. Maybe a comma, question or exclamation mark is missing, or the sentence is incomplete and should be joined with the following sentence. Suggested change: "When specified, " fixed Draft Text: In both choices the exact meanings of all of the values are defined by the "geodetic-datum" value in the [xref]. Warning: Consider using all the. Suggested change: "all the" fixed Draft Text: During the development of this module, the question of whether it would support data such as orientation arose. Warning: Wordiness: Consider shortening this phrase. Suggested change: "whether" ? [RW] Ignore. Draft Text: For test "A.1.2.1" the YANG geo location object either includes a CRS ("reference-frame") or has a default defined ([xref]). Warning: This word is normally spelled as one. Suggested change: "geolocation" unchanged. Draft Text: Many systems make use of geo-location data, and so it's important to be able describe this data using this geo-location object defined in this document. Warning: The preposition 'to' is required in front of the verb 'describe'. Suggested change: "able to describe" Removed this paragraph it's unneeded and not very clear. Draft Text: For accuracy it has a single "u" parameter for specifying uncertainty. Warning: The comma is probably missing here: accuracy, it. Suggested change: "accuracy, it" fixed Draft Text: This is used by many application (e.g., Google Maps API). Warning: Possible agreement error. The noun application seems to be countable; consider using: many applications. Suggested change: "many applications" fixed Draft Text: Thus GML "gml:pos" values can be mapped directly to the YANG grouping, with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than doubles. Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Thus," fixed Draft Text: Furthermore "gml:validTime" can either be an Instantaneous measure ("gml:TimeInstant") or a time period ("gml:TimePeriod"). Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Furthermore," fixed Draft Text: As with the "kml:altitudeMode" value, the YANG grouping supports the ignore case but not the relative case. Warning: After 'the', do not use a verb. Make sure that the spelling of 'ignore' is correct. If 'ignore' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. I think it just wants me to hyphenate "ignore-case". "ignore" is an adjective here "case" is the noun. *shrug*, I think it reads fine the way it is for a technical document. [RW] Yes, please just ignore. The tool isn't perfect. Draft Text: Thus the YANG grouping and KML values can be directly mapped in both directions (when using a supported altitude mode) with the caveat that some loss of precision (in the extremes) may occur due to the YANG grouping using decimal64 values rather than strings. Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Thus," fixed Draft Text: The allocation policy for this registry is First Come First Served, [xref] as the intent is simply to avoid duplicate values. Warning: It seems that a comma is missing. Suggested change: "Come," fixed Draft Text: All of the data nodes defined in this YANG module are writable/creatable/deletable (i.e., "config true", which is the default). Warning: Consider using all the. Suggested change: "All the" fixed Draft Text: These are the subtrees and data nodes and their sensitivity/vulnerability: None of the writable/creatable/deletable data nodes in the YANG module defined in this document are by themselves considered more sensitive or vulnerable then standard configuration. Warning: Did you mean than? Suggested change: "than" fixed Draft Text: Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. Warning: If the text is a generality, 'of the' is not necessary. Suggested change: "Some" I think it's correct to leave this, but I could be misunderstanding the advice. [RW] I think that either is probably fine/correct. Draft Text: Below is a the YANG tree for the fictitious module that uses the geo- location grouping. Warning: Maybe you need to remove one determiner so that only a or the is left. Suggested change: "a" fixed with "the" only. Draft Text: We would also like to thank Peter Lothberg for the motivation as well as help in defining a broadly useful geographic location object, and Acee Lindem and Qin Wu for their work on a geographic location object that led to this documents creation. Warning: Possible typo: apostrophe is missing. Did you mean documents' or document's? Suggested change: "documents'" fixed. Nice tool! [RW] Thanks. It needs a bit more time and work, but the hope is that it can be an easy w= ebtool that can be used by authors to help check the grammar/spelling in th= eir drafts. I don't want it to be an id-nits style gatekeeper tool, becaus= e as you have seen, some of the warnings/suggestions are somewhat arbitrary= . Also, the real credit goes to an open source grammar tool (dev.languaget= ool.org) that is doing all the heavy lifting. Thanks, Rob Thanks, Chris. Regards, Rob --_000_MN2PR11MB43663F7D9BCE02D10F2D5837B5499MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,=

&nbs= p;

Thank you= and the WG for your work on this document.  I’ve requested IETF= LC.

&nbs= p;

Regards,<= o:p>

Rob<= /o:p>

&nbs= p;

&nbs= p;

From: Christian Hopps <chopps@chopps.org>
Sent: 16 April 2021 22:30
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: netmod@ietf.org; draft-ietf-netmod-geo-location.all@ietf.org
Subject: Re: AD review of draft-ietf-netmod-geo-location-07

 

Just posted this new version.



On Apr 13, 2021, at 6:08 AM, Rob Wilton (rwilton) &l= t;rwilton@cisco.com> wrote:

 

Hi Chris,


-----Original Message-----
From: Christian Hopps <chopps@chopp= s.org>
Sent: 13 April 2021 03:38
To: Rob Wilton (rwilton) <rwilton@c= isco.com>
Cc: Christian Hopps <chopps@chopps.= org>; netmod@ietf.org; draft-ietf-
netmod-geo-location.all= @ietf.org
Subject: Re: AD review of draft-ietf-netmod-geo-location-07




On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) &= lt;rwilton@cisco.com>

wrote:


Hi Chris,

Apologies for the delayed AD review of this document.

I found that this document to be interesting, enlightening, and well

written, so thank you.



I only have a few minor comments, the rest are grammatical nits. Some I

spotted manually; the rest are from a beta version= of a grammar tool that
I am playing with.


Minor comments/questions:

1.
In the YANG module, the pattern statements have 3 ranges of characters,
but the description only indicates two ranges.  Is there a reason that=
the following pattern doesn't work?
pattern '[ -@\[-~]*';


>From an old email on the list: "These 3 ranges seem to make pyang happ= y. I
don't know why I need to break up the second range into 2 adjacent ranges like that to make pyang not complain, but complain it does if I just use: '[ -@\[-~]*'"

[RW] 

Okay. 





2.
I note that the YANG module allows just a lat, or a long, or a height
to be specified, rather than requiring at least a pair of lat/long or
x/y coordinates.  I think that this is fine (and keeps the model
flexible), but wanted to check that this is the intentional.



3.
I also note that that grouping doesn't require that any coordinates be
specified at all.  I presume that this is intentional, it makes sense<= br> to me (e.g., if it is intended to be optional).


My answer to a thread on the list asking for removal of some of the
mandatory designations which cause problems:

"The intention was for a location node to be required if the <geo-<= br> location> container was present. Apparently this will only work if
"container geo-lcoation" is a presence container. I'm not even su= re that's
all that smart of a requirement (e.g., maybe someone just wants to
indicate the reference-frame for an object). I'll remove the mandatory
from location."

[RW] 

Okay.






4. In the YANG module,
"v-east is the rate of change (i.e., speed) perpendicular
to truth-north as defined by the geodetic-system.";

As a nit, this doesn't actually define whether a positive v-east
value is in the East or West direction.  I appreciate that this is
obvious, but for the other two components in the vector, it is
unambiguously specified.


How about:

            &nb= sp;"v-east is the rate of change (i.e., speed) perpendicular
            &nb= sp; to the right of truth-north as defined by
            &nb= sp; the geodetic-system.";

[RW] 

LGTM.







5.
In Security Considerations:

 Since the grouping defined in this module identifies locations,
 authors using this grouping SHOULD consider any privacy issues that  may arise when the data is readable.

Perhaps, expand this paragraph to give an example, e.g., revealing
the physical location of a device, or data center.


How about:

"Since the grouping defined in this module identifies locations,
authors using this grouping SHOULD consider any privacy issues
that may arise when the data is readable (e.g., customer device
locations, etc)."

[RW] 

LGTM.







The rest are just grammar nits:


 In addition to identifying the astronomical body we also need to
 define the meaning of the coordinates
=3D>
 In addition to identifying the astronomical body, we also need to
 define the meaning of the coordinates


fixed



 In addition to the "geodetic-datum" value we allow refining= the
 coordinate and height accuracy using "coord-accuracy" and &= quot;height-
 accuracy" respectively.
=3D>
 In addition to the "geodetic-datum" value, we allow refinem= ent of the
 coordinate and height accuracy using "coord-accuracy" and &= quot;height-
 accuracy" respectively.


fixed


 This is the location on or relative to the a= stronomical object.  It
 is specified using 2 or 3 coordinates values.
=3D>
 This is the location on, or relative to, the astronomical object. &nb= sp;It
 is specified using 2 or 3 coordinates values.


fixed


 The intent of the grouping being defined her= e is to identify
 where something is located, and generally this is expected to be
 somewhere on or relative to Earth (or another astronomical body).
=3D>
 The intent of the grouping being defined here is to identify
 where something is located, and generally this is expected to be
 somewhere on, or relative to, Earth (or another astronomical body).


fixed


 At
 least two options are available to YANG models that wish to use this<= br>  grouping with objects that are changing location frequently in non-  simple ways, they can add additional motion data to their model
 directly, or if the application allows it can require more frequent  queries to keep the location data current.
=3D>
 At
 least two options are available to YANG models that wish to use this<= br>  grouping with objects that are changing location frequently in non-  simple ways.  They can add additional motion data to their model=
 directly.  Or, if the application allows, it can require more fr= equent
 queries to keep the location data current.


fixed


When coord-accuracy is specified it overrides the = geodetic-datum implied
accuracy.
=3D>
When coord-accuracy is specified, it overrides the geodetic-datum

implied

accuracy.


fixed



When specified it overrides the geodetic-datum implied default.
=3D>
When specified, it overrides the geodetic-datum implied default.=


fixed


indicated by the reference-frame value.
=3D>
indicated by the reference-frame.


fixed


For a formula to convert these values to speed and= heading see
this modules defining document RFC XXXX.";
=3D>
For a formula to convert these values to speed and heading see
RFC XXXX.";


fixed


You have "truth-north" and "truth n= orth" and "true-north".  Should
these all be "true north"?


fixed



 YANG grouping using decimal64 values rather than strings.  For t= he
 relative height cases the application doing the transformation is
 expected to have the data available to transform the relative height<= br>  into an absolute height which can then be expressed using the YANG  grouping.
=3D>
 YANG grouping using decimal64 values rather than strings.  For t= he
 relative height cases, the application doing the transformation is  expected to have the data available to transform the relative height<= br>  into an absolute height, which can then be expressed using the YANG  grouping.


fixed


Grammar Warnings (generated by a tool):
Draft Text:
Indeed it is easy to imagine a network or device located on The Moon, on

Mars, on Enceladus (the moon of Saturn) or even a = comet (e.g.,
67p/churyumov-gerasimenko).


Warning:  Did you forget a comma after a conjunctive/linking adverb? Suggested change:  "Indeed,"


fixed



Draft Text:
This document defines a "geo-location" YANG grouping that allows = for all

of the above data to be captured.


Warning:  Consider using all the.
Suggested change:  "all the"


fixed


Draft Text:
When specified these values override the defaults implied by the=

"geodetic-datum" value.


Warning:  "When" at the beginning of a sentence usually requ= ires a 2nd

clause. Maybe a comma, question or exclamation mar= k is missing, or the
sentence is incomplete and should be joined with the following sentence.

Suggested change: "When specified, "


fixed


Draft Text:
In both choices the exact meanings of all of the values are defined by=

the "geodetic-datum" value in the [xref]= .


Warning:  Consider using all the.
Suggested change:  "all the"


fixed


Draft Text:
During the development of this module, the question of whether it would

support data such as orientation arose.

Warning:  Wordiness: Consider shortening this= phrase.
Suggested change:  "whether"


?

[RW] 

Ignore.






Draft Text:
For test "A.1.2.1" the YANG geo location object either includes a= CRS

("reference-frame") or has a default def= ined ([xref]).


Warning:  This word is normally spelled as one.
Suggested change:  "geolocation"


unchanged.


Draft Text:
Many systems make use of geo-location data, and so it's important to be

able describe this data using this geo-location ob= ject defined in this
document.


Warning:  The preposition 'to' is required in front of the verb

'describe'.

Suggested change:  "able to describe&quo= t;


Removed this paragraph it's unneeded and not very clear.



Draft Text:
For accuracy it has a single "u" parameter for specifying uncerta= inty.
Warning:  The comma is probably missing here: accuracy, it.
Suggested change:  "accuracy, it"


fixed


Draft Text:
This is used by many application (e.g., Google Maps API).

Warning:  Possible agreement error. The noun application seems to be

countable; consider using: many applications.

Suggested change:  "many applications&qu= ot;


fixed


Draft Text:
Thus GML "gml:pos" values can be mapped directly to the YANG grou= ping,

with the caveat that some loss of precision (in th= e extremes) may occur
due to the YANG grouping using decimal64 values rather than doubles.


Warning:  Did you forget a comma after a conjunctive/linking adverb? Suggested change:  "Thus,"


fixed


Draft Text:
Furthermore "gml:validTime" can either be an Instantaneous measur= e

("gml:TimeInstant") or a time period (&q= uot;gml:TimePeriod").

Warning:  Did you forget a comma after a conj= unctive/linking adverb?
Suggested change:  "Furthermore,"


fixed


Draft Text:
As with the "kml:altitudeMode" value, the YANG grouping supports = the

ignore case but not the relative case.


Warning:  After 'the', do not use a verb. Make sure that the spelling = of

'ignore' is correct. If 'ignore' is the first word= in a compound
adjective, use a hyphen between the two words. Note: This error message
can occur if you use a verb as a noun, and the word is not a noun in
standard English.

I think it just wants me to hyphenate "ignore-case". "ignore= " is an
adjective here "case" is the noun. *shrug*, I think it reads fine= the way
it is for a technical document.

[RW] 

Yes, please just ignore.  The tool isn't perfect.






Draft Text:
Thus the YANG grouping and KML values can be directly mapped in both

directions (when using a supported altitude mode) = with the caveat that
some loss of precision (in the extremes) may occur due to the YANG
grouping using decimal64 values rather than strings.

Warning:  Did you forget a comma after a conj= unctive/linking adverb?
Suggested change:  "Thus,"


fixed


Draft Text:
The allocation policy for this registry is First Come First Served,

[xref] as the intent is simply to avoid duplicate = values.


Warning:  It seems that a comma is missing.
Suggested change:  "Come,"


fixed


Draft Text:
All of the data nodes defined in this YANG module are

writable/creatable/deletable (i.e., "config t= rue", which is the default).

Warning:  Consider using all the.
Suggested change:  "All the"


fixed


Draft Text:
These are the subtrees and data nodes and their

sensitivity/vulnerability:

None of the writable/creatable/deletable data node= s in the YANG module

defined in this document are by themselves conside= red more sensitive or
vulnerable then standard configuration.


Warning:  Did you mean than?
Suggested change:  "than"


fixed


Draft Text:
Some of the readable data nodes in this YANG module may be considered<= /o:p>

sensitive or vulnerable in some network environmen= ts.

Warning:  If the text is a generality, 'of th= e' is not necessary.
Suggested change:  "Some"


I think it's correct to leave this, but I could be misunderstanding the
advice.

[RW] 

I think that either is probably fine/correct.





Draft Text:
Below is a the YANG tree for the fictitious module that uses the geo-<= /o:p>

location grouping.


Warning:  Maybe you need to remove one determiner so that only a or th= e

is left.

Suggested change:  "a"


fixed with "the" only.



Draft Text:
We would also like to thank Peter Lothberg for the motivation as well as

help in defining a broadly useful geographic locat= ion object, and Acee
Lindem and Qin Wu for their work on a geographic location object that led to this documents creation.


Warning:  Possible typo: apostrophe is missing. Did you mean documents= '

or document's?

Suggested change:  "documents'"


fixed.

Nice tool!

[RW] 

Thanks.

It needs a bit more time and work, but the hope is that it can be an easy w= ebtool that can be used by authors to help check the grammar/spelling in th= eir drafts.  I don't want it to be an id-nits style gatekeeper tool, b= ecause as you have seen, some of the warnings/suggestions are somewhat arbitrary.  Also, the real credit g= oes to an open source grammar tool (dev.languagetool.org) that is doing all the heavy lifting.

Thanks,
Rob




Thanks,
Chris.




Regards,
Rob

 

--_000_MN2PR11MB43663F7D9BCE02D10F2D5837B5499MN2PR11MB4366namp_-- From nobody Mon Apr 19 07:06:01 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1313A3473; Mon, 19 Apr 2021 07:05:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk CC: Kent Watsen , draft-ietf-netmod-geo-location@ietf.org, kent+ietf@watsen.net, netmod-chairs@ietf.org, netmod@ietf.org, rwilton@cisco.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161884114915.5121.5751188439778970063@ietfa.amsl.com> Date: Mon, 19 Apr 2021 07:05:49 -0700 Archived-At: Subject: [netmod] Last Call: (A YANG Grouping for Geographic Locations) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 14:05:55 -0000 The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Grouping for Geographic Locations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-05-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a generic geographical location object YANG grouping. The geographical location grouping is intended to be used in YANG models for specifying a location on or in reference to Earth or any other astronomical object. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 19 13:14:39 2021 Return-Path: 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 39D653A421C; Mon, 19 Apr 2021 13:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 O_yrIwyptykB; Mon, 19 Apr 2021 13:14:28 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 DB1893A4220; Mon, 19 Apr 2021 13:14:24 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 101-20020a9d0d6e0000b02902816815ff62so27877840oti.9; Mon, 19 Apr 2021 13:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CSnFsvqpu6rtPHwI6xWYa0kptZtpJaxEQTtwLgTLdb8=; b=vfcDS/5yiimEZDrA32GdkFaGKnpnacpOL8wLKrfkgn1OXfe8Bkw6JoTX2poNf/Rph1 Bd3cZXKnhr0/tQXs6Wd/xsdSwE3FZpbbVe8aF61MJLNRLF2rjcYShWEUcinKvdw6IqaD XrY+jxIz1UubAhFv8YeBWtbcG+rplbBr6YlrkRDy1E5S0Lt8k6K/SANmZEKjAuFIfRfu Ce0SYi00GvnlIl9+cqqv8jfrZGAT/ZXVLderPzAUUExfuzyPnF0J6Q06l54d88K4ER9+ 5vBK0Pf6QL/2jclSUdPzuUk3XOcIV1EX6VudH+lvWYJu5xUcd6eJNVQRydeiRKgVVoF8 4UAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CSnFsvqpu6rtPHwI6xWYa0kptZtpJaxEQTtwLgTLdb8=; b=TVa1u9W3b0Y01h8Vf5oIh9HqLbEEMAsRuADrJu1V4VZNE4lPiG6CxZd2i+FeCIWz5A zBgFsUAfT+HOu1ROYenTPWpR7oaUo9MUQh5qLY6+FantC2yhxpDgE0rN0b66LUqdzgHE e6iI/O4p8eu0kfHTdDCVRpuk6W+zpW9Ek+PCTny1Dtz3ons+EZKP+mb3nDsv+5TS2CQJ HXocdYdNnTSwmk1t2VV1sdX/tOqA9cYEYKeNFvMhS6W/DokWd4RMhrPzrjBB+JRXkSI0 NOL08nouByNP4y+XeHofuLaRnoOWCCGbx0Xk2IkGr63f28oSXGCDyogtftAOxPNfobru 99yA== X-Gm-Message-State: AOAM532vXmzmzf95I4BnFAW5mXmyCfwvtKcNpOfldoDSmjY7zUc00ZU5 zU+EguG2Ysm6VVKOioXbvdh+JQzZKHQAnvv8aGT7JBt9Dqq6zA== X-Google-Smtp-Source: ABdhPJw0uR6vfutDd+SWsqa3eeZTyq101osLedNLsrUSP1RulLasRLIxipntlJoAwOJJTaQaEIQ52Uw2R6ynoeHh5tE= X-Received: by 2002:a9d:70d0:: with SMTP id w16mr7425722otj.191.1618863262641; Mon, 19 Apr 2021 13:14:22 -0700 (PDT) MIME-Version: 1.0 References: <161884114915.5121.5751188439778970063@ietfa.amsl.com> In-Reply-To: <161884114915.5121.5751188439778970063@ietfa.amsl.com> From: Erik Kline Date: Mon, 19 Apr 2021 13:14:11 -0700 Message-ID: To: last-call@ietf.org, draft-ietf-netmod-geo-location@ietf.org Cc: netmod-chairs@ietf.org, kent+ietf@watsen.net, netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000b5b31105c058f95c" Archived-At: Subject: Re: [netmod] Last Call: (A YANG Grouping for Geographic Locations) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 20:14:33 -0000 --000000000000b5b31105c058f95c Content-Type: text/plain; charset="UTF-8" Are the vector components expected to be accessed by name in applications, or is it possible some applications might have to handle a 3-tuple of doubles? I only ask this super-nitty question because in my (admittedly limited) experience, ENU order (or NED for that matter) was more familiar since it forms a coordinate system that aligns with the right hand rule. NEU->ENU conversion is obviously trivial. I was just thinking of possible errors where the members of the vector aren't accessed by name but by position. -ek On Mon, Apr 19, 2021 at 7:07 AM The IESG wrote: > > The IESG has received a request from the Network Modeling WG (netmod) to > consider the following document: - 'A YANG Grouping for Geographic > Locations' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-05-03. Exceptionally, comments > may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document defines a generic geographical location object YANG > grouping. The geographical location grouping is intended to be used > in YANG models for specifying a location on or in reference to Earth > or any other astronomical object. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --000000000000b5b31105c058f95c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<no hats>

Are the vector components expected= to be accessed by name in applications, or is it possible some application= s might have to handle a 3-tuple of doubles?

I= only ask this super-nitty question because in my (admittedly limited) expe= rience, ENU order (or NED for that matter) was more familiar since it forms= a coordinate system that aligns with the right hand rule.

NEU->ENU conversion is obviously trivial.=C2=A0 I was just thin= king of possible errors where the members of the vector aren't accessed= by name but by position.

-ek

On Mon, Apr 19,= 2021 at 7:07 AM The IESG <ie= sg-secretary@ietf.org> wrote:

The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Grouping for Geographic Loca= tions'
=C2=A0 <draft-ietf-netmod-geo-location-08.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final=
comments on this action. Please send substantive comments to the
last-call@ietf.org<= /a> mailing lists by 2021-05-03. Exceptionally, comments may
be sent to iesg@ietf.org= instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document defines a generic geographical location object Y= ANG
=C2=A0 =C2=A0grouping.=C2=A0 The geographical location grouping is intended= to be used
=C2=A0 =C2=A0in YANG models for specifying a location on or in reference to= Earth
=C2=A0 =C2=A0or any other astronomical object.




The file can be obtained via
https://datatracker.ietf.org/doc/dra= ft-ietf-netmod-geo-location/



No IPR declarations have been submitted directly on this I-D.





_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--000000000000b5b31105c058f95c-- From nobody Tue Apr 20 07:22:54 2021 Return-Path: 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 4BD423A25BB for ; Tue, 20 Apr 2021 07:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 p5OHSlXLPkll for ; Tue, 20 Apr 2021 07:22:48 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2123.outbound.protection.outlook.com [40.107.236.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580423A25B8 for ; Tue, 20 Apr 2021 07:22:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j/bsSnZ/il6xt09vOIjUJ9gsxRoVYPSr4U2Alir7xwi+cKjByv5GY9nPJiKcMiKSAM/HpkdLEbUB3oaHclc69gGUNtCyN6zXwkgK4YgaUu8m8XTIRWd3awMps18iRO73ruUDqxC/uwKUkMX5NW7BdZRC1N2isaflpVgZP5U9LcQ8/QDFUXwqgOrpKnU0hF/057OHdEEuYlGhcI1E1orNg/l7rppLxTokQ/IyICIvWU4yUbWY+wOnMCgZBmbeSSUgdddu/C9a77BmyRvodq4an/eWD0qi7YVX+npWGX82WaBMa70qGa0gYUJvO3fKewDC5AgPQKcembiGcKBBSMQ/ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1fHed8p5FA6O19uLGKw7eeXnziUz7l2OeRMgKSclzfI=; b=j4mmymhfacKjb9ip3R93vPw5X4ze6PbPLdqzz12jqPBVMuY1UODI2ZD3KwBCtdTj5URVSakgb4Nzw+CZtwKpJUjhJJ9MVCTZyIKnO5agEV0zhjqp8lcTjDRMGayMKatBcj+8viT3Mu2qRQ+bobRdjsBk1v819A/OVc+ee4gGCWa776M4O2tnRyJQXlQeGVuRs8SCF3h39OIwOcm30c/Xt5L/m5mx52H/nU3Jf149Puer9voSWXrAuaxJNeTHxbfD5xhhM31sTd7bCd2BmtZgyNdprAz9+kXsHiRAWSxHPrdzRqD/1/eB9Ftx4+kTSpGm6QMA868W8FRmWCZwD9ndWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1fHed8p5FA6O19uLGKw7eeXnziUz7l2OeRMgKSclzfI=; b=qg0g95nA7TmENbAT5Ezr4jtnDQH1evjM8u60rHh3ODq8aBhua06xdu5ieyE2qx/oeSVrelXaV/2dFPDGD9ArfvmT9eDN4gMkkxTuNArvplGJSHra610p8NrIw2aiM2c3eNDklaFW5vS4G4w1zoY4HdVz38iTIBGO7y2E/Yk5iZE= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4090.namprd08.prod.outlook.com (2603:10b6:5:85::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.24; Tue, 20 Apr 2021 14:22:43 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4042.024; Tue, 20 Apr 2021 14:22:43 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-04-20 Thread-Index: Adc18GtNSyxQF9rZR9a5URD6fRKKkw== Date: Tue, 20 Apr 2021 14:22:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b45a492-86e4-4dd4-2bfa-08d90407c357 x-ms-traffictypediagnostic: DM6PR08MB4090: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P2ij8Njil4UfLMtq/6VHvrES7fS8x0UBp0Z9B2YYcRpvpkKje49okjT0vfEaH5dxyDofWbL7pEb1Aj+sbmstKOtPEdGVY5AeIZOPUAX4dRwGufqhAYABVzGOHRewcIAJbt12rWCkbm1+7Pjf9pvNCi6qyyI3iUV2+pAd5dal0aGhmEDAIUdl767i0CE5DKtdLwJeDwsbECQPWOAqC9X9wi0AdjDydJZrpbZTWZWud8M5TCHVpKl+Y8YB+bG0n0SGwivK8omN9MBsqzO/sZ4GzFkbf9T9o54mYGfHsrbJaYQbFphgdEUqwWReCEf6MZENl60sxgmrvvoG4lcBtIe2U/FaIjWI04gkiab/qhIdrpOWSl+JSJ4CNUtoiug1RNAiKulTd71DNjUTjIez4X1oH4B5pY0b4+gF2wrgMfDF+Toi9Hl6aiLHrqjZFESYC0U05jt9goSw5wwddRlGPquHu+4COsfJKuouKlgWKdggjtzykc6fHb8cTxDRS9fpjtRdqlPF0tBDOpDEPBCPfUNz0/HhPb9+/XS4frKg90jzmRhYiK89dj9WXl5C/jE7hguJk3eBDU9WP74zpjrhgwB4Jy3jmy7X1P2SS3dmc46rD+JgNrLc/TPT0yUjEG3hms4l0BB2UM+ZIF3sYVEcq7cqOCjgFEgbVyvSk6P7UXoq1oEEYLxlWs6Bvx+L0gdphWr6 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(376002)(346002)(136003)(396003)(966005)(316002)(5660300002)(478600001)(66476007)(66556008)(83380400001)(66946007)(64756008)(26005)(8676002)(7696005)(76116006)(66446008)(122000001)(186003)(86362001)(6506007)(2906002)(16799955002)(52536014)(8936002)(71200400001)(55016002)(6916009)(33656002)(38100700002)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?v2NUf4KoRfQS2Wp89PL/b65wQG2/ungNBcr/Storjyy1MU+izt84clKm+iAn?= =?us-ascii?Q?u8JptHLaJaIBC3+k580YZXHnkLGf+djgZpJMcN06WP9PQQ0MpDTTjxXLad8I?= =?us-ascii?Q?i1BZY33YAYatOpRNI4JELwH7Tc12J3yFFYIQMmGyRTy+jBfbFoMEtbK8UDCj?= =?us-ascii?Q?zbO5IlyTpizIJTeiQtgwVJI/pW6g3qUIuYo6n45g+E8YCEnb8rdudSkdd6YF?= =?us-ascii?Q?cR7GyYvHJxza4RECN86z7/xEO94LRJb5LywwBsp639t7sSLlEONG6aVrWeTu?= =?us-ascii?Q?2RLRCU6xGnKiQmlBerzUk3ID4YoYLb7+g1e7AR2SdixBJvqM+Sbsgfx0XQT3?= =?us-ascii?Q?KXRdNFfo5S25+gizVJHTLH9Lg44Lx69/zeHISUg7gSE9x9LgSykT7GuRjRgh?= =?us-ascii?Q?tIl303Pb/gnG/Scl2l/Um+tTFPSIi+6XAxE7ielMJgxVwlzTR8IPpg/kSHLe?= =?us-ascii?Q?aJ/GrxUgAEOFhvubgVfwQ9YLaO/DvS60v+HqTkkHPhCrbCIOaRRVObetPtci?= =?us-ascii?Q?VuNHaIDQIUBRHsKla674hq7VE5ihc74HyTFMYgfmT3R81fWBr6i8OvQAOurz?= =?us-ascii?Q?kWolGugoTlEqxurasCw9NPh59OsH4ZAqWhywC0B1xuFh8NzFEeei2DJL6w/x?= =?us-ascii?Q?B7YfRn+0G7eppfLhVwtNwDtVHDpzVhI3wyKsD6+uTBaWsl/jPTHYiKU70G+z?= =?us-ascii?Q?6faiFgcC4UeVLe+IjYh3qL9b/5Iwfn8dwEc8a2vByakd2fk9xgWtvmD7iwuQ?= =?us-ascii?Q?+CVnELDjQuA2mTrjJiYz2N/nuRpR3gmHRod6OrA0CCK8l6zWvNE4X23Fe1y8?= =?us-ascii?Q?5vhTDRfokSd/Zk0Tk8eDT2Dw4nQEBLe3nNMMNleg4HFMsVv1omhp3R+bsxxs?= =?us-ascii?Q?aEb6Czts0x/PMzJB9BIuuoCk1Igc4PkL4tNU6TCOQtMJ4KRULbPBZr2xS5e6?= =?us-ascii?Q?nxTnhEiTwN9ikMLpLMr0iTPq4MbmAYAB8ifUu5Y9NBQS+mZNz7dfYWQpT5p6?= =?us-ascii?Q?vJJnTJuWUiuOU9dkdNHkJC41S2IjDE05kt4V1o+/e0D6PSHkhiU6m1NKxb5p?= =?us-ascii?Q?35x2B8tgkyZm7/KuobKl8UYlMsuLlyWk0RKMYhpZhmPs9ksuqPvuaKzktDDo?= =?us-ascii?Q?xHF+BH0aG8HbtjO30FGdjB/W6A4De8pB4dpU+3G0Z9l6GIhibsP9y5ChXhIr?= =?us-ascii?Q?x0gAYPmzhKgphuTOPT4IfNFS+16vInJOa874Ycy7vislKOoANgKdla2vErfM?= =?us-ascii?Q?rgVnKdbhPRpmxop9hx7JrxSw7u0KbHED9/ZjsfFggC1o7FRrsUWGFeatS6AS?= =?us-ascii?Q?NSPgQ0tTjg6hcBakaTzbitLs?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084351499B34EE32748E9579B489DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b45a492-86e4-4dd4-2bfa-08d90407c357 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2021 14:22:43.6449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yGEOuMn49KSGavFvYwFv/dPQ31EMY0avedRh166dI5Ljx0X0zUfhNdnI2jTWRpLZqCvtbk/eSUgIM6SCr8/bKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4090 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-20 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 14:22:53 -0000 --_000_DM6PR08MB5084351499B34EE32748E9579B489DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-04-20 Activity in the past week that we should discuss: - Andy's & Juergen's replies to minutes re state rules - Rob's updated options for state BL -> Address Juergen's comment on mandatory in state on the mailing list JS -> Bring decision about state back to the WG (i.e. clarifying state vs c= onfig any further than 7950 already does will be out of scope for our work) For next week: - finish up review/completion of IETF issues - drive to completion on github issues (exact text) to bring 2 drafts (Modu= le Versioning and YANG Semver) to "WG LC ready" ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB5084351499B34EE32748E9579B489DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-04-20

 

Activity in the past week that we should discuss:

- Andy's & Juergen's replies to minutes re state= rules

- Rob's updated options for state

 

BL -> Address Juergen's comment on mandatory in s= tate on the mailing list

JS -> Bring decision about state back to the WG (= i.e. clarifying state vs config any further than 7950 already does will be = out of scope for our work)

 

For next week:

- finish up review/completion of IETF issues

- drive to completion on github issues (exact text) = to bring 2 drafts (Module Versioning and YANG Semver) to "WG LC ready&= quot;

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

--_000_DM6PR08MB5084351499B34EE32748E9579B489DM6PR08MB5084namp_-- From nobody Tue Apr 20 07:29:15 2021 Return-Path: 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 272BE3A25F7 for ; Tue, 20 Apr 2021 07:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 gbMv0hTQKN03 for ; Tue, 20 Apr 2021 07:29:10 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2133.outbound.protection.outlook.com [40.107.243.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2D43A25F3 for ; Tue, 20 Apr 2021 07:29:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W85BUVWWKAVs7fl6KSg8QcTClKBGdD0uQJZw0PlVJVMyKPV+F1Q+eOyEA85jkSOT9OGm80pNW6DACxZSVwfZUhEwct6ZpFJp28Q5s3XdqFftpiUEswl4fcvl0RcxSiohHPgYEkD8Q/Qot/ogqspG9Z6/vsEOISuPpDB5uh5M8MOraVoOrEJJE67op9IsEj2m90kcCyyHaQfh/wucjSgnEgJqgaviVJ3v3eD03NP0mi/tWCTyINvCHmM2xT4ib+Pfqoh3il4ZQ8RqeRUQZp1wLzqer+PeQBZxeknfJAy/Lm81bm6N3C/JC1BUOQREDUBAgS3cGfRPmkpTzA8IJ67Uzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x8mLQGfy8WfX4S/HEheolohzDQK+THEBjoIOKAxaAcw=; b=cPM6UJ9ugOZIutJiYKWzY4ZhShilZlFzmlLhXtSpFKTnV9dyjdNZMiZCDzinzr9RaMGEXxi7A9iY061OteFknIBpdNwr//YXVLOAwyG/ZKk3aXRCZOdkCN9KVbzRkoXKtTHMVgfUWVoAD4yBipwb9Htm1BauWkOS+gh/H+xR6osTl4Qv+tQPT1VEHqurm8bG+aw/qZ2EMzni/Jf4JQxdxuL9qOvMPBiyDvP2PNl+LLUOK9gFU8gWrd1ChGMq8eWBOpWArlVDQgGSRyImh0oZv9yqvm7HpReei741AnXvJaJLyxC1sFgzHv1oqba+FUMm+s5jFqZWemfY1kaeHLiqNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x8mLQGfy8WfX4S/HEheolohzDQK+THEBjoIOKAxaAcw=; b=RoxeVXK5oxpPSsKFf+zvjo4m3MjPBXGmyeP90C5PhfmRCzv8tmOzhukU63J9iqeNBE6sH50OgWeuv6oqxljRpRy+ig+nUsmLhr8n4696buVYwFOce6MhbUSRIPJ+/mLJI03OXj6AMIsW9sw3ljlR1sYgjxuIcc0ynFNXFPyCZt4= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5402.namprd08.prod.outlook.com (2603:10b6:5:f9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Tue, 20 Apr 2021 14:29:06 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4042.024; Tue, 20 Apr 2021 14:29:06 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG versioning -> specific/different rules for "state" out of scope Thread-Index: Adc18YP3sNozhBawSLeLOsCGhorAlQ== Date: Tue, 20 Apr 2021 14:29:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a93d8fdf-00eb-4cb7-35eb-08d90408a765 x-ms-traffictypediagnostic: DM6PR08MB5402: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w86py+3+CZaVyOtd9LWb1sVY9XUjUwzNdN5oEmzoICCFqS1R+UmxmfD/pnx8jNG05camqCbDYD32GvkHw6dQiMiJPMmU2DDZPjzFb8IzA1lQ2GFcxYvypK8MVU46Zke4RyPy0XN38OUfr2H1oI08USqlJ3D+eR2pbXIGqaPR38DLKxm2n1qUysVkDzK2jWf/dhdvwAojVDOuPIFekuK/QAl/CZll9auK2ZJgIAIAcw4ohLC0qtR3szcBbAgY4ekQkrK6zayCyfhOqz8SAeNNRB0V6aLPAmZg+aqW6FNh4yhPTyo8tjmG7OQ1cTUBJTC6WXgOWEgHjErjtL/kerF6oPJcxX8KLumMJJJWBn3t7Y65WKm9IOw1lYHnfTrcHUjgmqcLCD4kelxMgFwGuYscCo9nVtHD6IyHr17dOR1fI67dk8uvNjN0FaQbJfiow/rotm2LTl6oiZcAgXqCGeCX9xazOyTDYpmS67aoeHkQM/9Ma50Z0d0Y/9ujMRsSFGe0JqQYPhIZJ3+3r4EnpHhZjUD/vMZkVT0nXgTREacJf1uw2lBIpM+JU1XaFPa2dxrcbSX/eo7TPcx90Ff7Cmx3AytWf3py1RjSXhz4mHRXyZ4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(346002)(366004)(136003)(376002)(396003)(186003)(26005)(76116006)(52536014)(4744005)(2906002)(478600001)(8936002)(83380400001)(6506007)(33656002)(86362001)(122000001)(6916009)(66446008)(316002)(8676002)(7696005)(55016002)(9686003)(64756008)(66476007)(66946007)(66556008)(38100700002)(5660300002)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?GM62GqsyENt3riuTAXj6O3vR4luetldpwGefTCsVPxHVPGt6DPONd7k88O/O?= =?us-ascii?Q?18zx6LBaS1HMlv4cGRQRe5GdtYcaJFbTm8TF3P4H2Md5W0PepDJx6HY3cXLE?= =?us-ascii?Q?oBxMGZCY+tElXnXnlwljnjRy9DJWzcEkTYYwAKaPTXCCHlH6p2DStq8u+zgI?= =?us-ascii?Q?+jrJir9WkKv9C0F32qo7hO25NwJ1x1ZjKnKWqvW12d8F3hv79/QEnw9g4ld1?= =?us-ascii?Q?EXq6fAAdaHSTAyL6EAnU6cZILss/jut56vDgDqcp9T8Eo9vqd6oZyejWuF12?= =?us-ascii?Q?EnUQ8wpQd6FYyEeaJt9HafQf+D6Lr25aA90srCNcGd1mSeFss2RMFGCFXugB?= =?us-ascii?Q?TjJZhsnOG72/Uuz1N2uShZLT8LZb66PCAmweY0grJ9cqAXkL5u/MCsb5YMua?= =?us-ascii?Q?kRNITAdab3eeRvCoQfM6Ifhg1Qs+PPjsDZ/6cze9nwi/oQj2hqIYRFCcMmVG?= =?us-ascii?Q?hkvSOubGBw2se91a1z/SooHWVHQhgnhLe5zU17/JIJz87Izdwb4l6Rn8Ruir?= =?us-ascii?Q?0J3gWCYVGt9RgarTLBWr1gBFx7DbBYYgCQFLbq7R6zKfMfN6H/QlSKigoBQA?= =?us-ascii?Q?k4l9Z2Yqmpdn2jmamYoAk0W4x45wkbHWx+jvuq6Ci/63Q/jkMgHul+sC2ZDP?= =?us-ascii?Q?IM9qgREEzJvlpuo4ECdwi+Up/BysIm7L9b63WaNomylUvT4edAjVavdig3ih?= =?us-ascii?Q?J330loEGhKHEGXcWrSA5ABHzNyhLMeCLaQd0CcCtSV1Vxiy03X1kM10Xh/cS?= =?us-ascii?Q?56n+ZpI5QfCyYMgL+KNG6r3JX+ZIUFBek2Anbfutchuos0q/ydr3Z69YUxUl?= =?us-ascii?Q?0cvNKg85iOmx+DMtj8cds1LlVXK8x2yfrmV0r9MlNq9yKbGt/tccv9fUPxye?= =?us-ascii?Q?/y3PoRgykWZWavZwCA5dAIb8kW9pVR8Lm5gKXqUU5Ee1B1FXMWRbVZJmIv3N?= =?us-ascii?Q?mMrBrvXKZWhfKgmOyK2sC43R0/+hN29jqTsuSewS1H3G5Uz7Oa9hvToViN6X?= =?us-ascii?Q?l4gtSwEcjYa0bZsiDDq/HkyfKHc/B3G109b2ku6gnqzotu/aXXUpRan4kZfb?= =?us-ascii?Q?J0RhsXMXNgTqYRQhAGw6rUtRkDHUBfLFx09yHYIPdZNHMCnY+fUDhaWRG89s?= =?us-ascii?Q?jX+FIDqjlfYMyln1deEizyoBsuZAUlYAZk6YfB0VcBRtWTxXoAAohOeYgtem?= =?us-ascii?Q?+V+zQg5svIJJo6x6GnuZj8EL+oFra7L9o/BuiERK7JTfRyboIGFXWAIbaefO?= =?us-ascii?Q?bdM860Zmthe+glIRvGUQmbkQL1gAhYIbipPcOLEIuTubCBGxpPxByj1/O78o?= =?us-ascii?Q?fRJP76gXwH12srbT8470xBi8?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB50846750CAD6F8320FD59B6A9B489DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a93d8fdf-00eb-4cb7-35eb-08d90408a765 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2021 14:29:06.2864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TezaeCvFea7k3DPi5wQ23MwOvULXt2mlYSuSGVOTYe3DikWV0IDgjnGOp+Chfi1BpXdQMOcySvz1a7qwk8iACg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5402 Archived-At: Subject: [netmod] YANG versioning -> specific/different rules for "state" out of scope X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 14:29:13 -0000 --_000_DM6PR08MB50846750CAD6F8320FD59B6A9B489DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, After some feedback on the WG mailing list and further discussions on the w= eekly versioning calls, we are proposing that any clarification (above what= 7950 describes) of how changes to "config false" nodes may or may not diff= er from "config true" nodes is out of scope for our versioning work. We wo= n't specifically call out and address state (config false). Any discussions of state vs config for module changes would occur in the co= ntext of RFC 7950 (and possibly clarifying what the 7950 text means if/as n= eeded), and in the context of "YANG NEXT". We'll remove the recently added section about state (config false) from the= next module versioning draft. Jason --_000_DM6PR08MB50846750CAD6F8320FD59B6A9B489DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

After some feedback on the WG m= ailing list and further discussions on the weekly versioning calls, we are = proposing that any clarification (above what 7950 describes) of how changes= to "config false" nodes may or may not differ from "config true" nodes is out of scope for our vers= ioning work.  We won't specifically call out and address state (config= false).

 

Any discussions of state vs con= fig for module changes would occur in the context of RFC 7950 (and possibly= clarifying what the 7950 text means if/as needed), and in the context of &= quot;YANG NEXT".

 

We'll remove the recently added= section about state (config false) from the next module versioning draft.<= o:p>

 

Jason

 

 

--_000_DM6PR08MB50846750CAD6F8320FD59B6A9B489DM6PR08MB5084namp_-- From nobody Tue Apr 20 08:35:42 2021 Return-Path: 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 54F7B3A2846 for ; Tue, 20 Apr 2021 08:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=ericsson.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 LBgwqrvZUc3l for ; Tue, 20 Apr 2021 08:35:36 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130088.outbound.protection.outlook.com [40.107.13.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E7A3A2844 for ; Tue, 20 Apr 2021 08:35:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VRJpwsMEE7QYcbfKnPtC6WZKKrFXbdLd0A1HtlC+myCN29pf6GUFrjESoMV+iyeHnISzzE7DorZ4xKhDGWwk5FhBT/f4KYzTOjmubqiL4xBSVn4PmpU+GWacmRWZIa+4UDl1TvpJKfiuEqqwII+50Jc3CDHzaGGnkQeYJr0OL7y5ZQhhG332Ufig0YbbA274eEp4z6ZeRSX5zoYCJ52n5ecgpqZT8ZQsQAN+OvQvBdww+qh1otUe4+uJ10rr2evcY/x5qZRvqlihxWKg/7+4MU/T9z3NWnkBIV9fHUuDSTkxwsO1dsxgCQ8vzqBhdbadVu8x0fv2nyF3y65exv/f4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7jERI/ohvK+Z/KTM9cyV/xP+WR63l1FwgHTCSaf/ZgE=; b=gV6Xe4vfyUYjQ1Nc3ZtU8ImJseaOX8B3Ql53cemRns9rQUf+5R7Xu2Q9JEhlhQGv64Wo+P8TSi6p8D7Ipz0oUcXzgDvSZQ9JsfPuSi5/MG+Np6QYp3q6HpiAehJNQ7fax+H6oN+qJHQaUj/IHv0F/FvrBppZNg5f1oVs+EEnhDWaXEsXj0HTxJG1gsmnb+0x0A46FENPLU1cagsJcRbeclMlhzIOG8QWoFlGXKzTSskIRfu8W926ISUh8bMS+Czf7AM6qZ9kFZg0Zb+wfR+GB88v+V7J0/ORSUFR5LetISr8BmC1D27xtgC0Pb1ygivJLPgeyhYNOKu629gxaRYndw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7jERI/ohvK+Z/KTM9cyV/xP+WR63l1FwgHTCSaf/ZgE=; b=J0Q+lpYi6HR4Tzw6dNCGW75aXE8skGa/5mKMO5lregxXGC67fmhFEMyiBoiuoOQZrYUH/pmATIL2qkhP0rXWXML8+My919QYdREe+iC2DCDbekvNcLa8lQ5eN9KvMApzD4LHUFqtUiT7TXUURuCF0qePXoHTJRg2vzqVCJj2EYc= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8246.eurprd07.prod.outlook.com (2603:10a6:20b:325::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.6; Tue, 20 Apr 2021 15:35:29 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e%7]) with mapi id 15.20.4042.016; Tue, 20 Apr 2021 15:35:29 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Juergen Schoenwaelder CC: "Sterne, Jason (Nokia - CA/Ottawa)" , Andy Bierman , "netmod@ietf.org" Thread-Topic: Compatibility of config=false data Thread-Index: Adc1+nRtif5YsBpWTgmEUWyshSkyCw== Date: Tue, 20 Apr 2021 15:35:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.248.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f9d0d6a-b046-43da-85e4-08d90411ed31 x-ms-traffictypediagnostic: AM8PR07MB8246: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BJr5yZQXFBzJizRhnNOQ1MJknbf+A/PWrXmMCt8KDOvFgEFpgpyUmhhGTjE6RMm3BbuD/9S4bT1dhMA6gruA3Rl/u67oPN8BZZG3gOvhriSGhTun9OuxsURF//VVqer+w80JvwpOj3IUcebjTqtTHhg1qy5O8rDsjfp0j3K9PS2jlEnMij97LGBOH2o5e5WRZvBi7noa1IsM+KcJk+5oTa/1JeStvg1/C/0BDU4FrGsCexIWHRCuAr80ADe+dnkyNPv6eB4Gqrygh7QB5n1ICE3P9aiuUWIUtXyKj5Mxea4xbUjU9EBJO8tXBgAEeA9Sbi9zkdFh5w1sVctM6oYQbmBErfGEI4Re9IzqhdfMecFf8bFvYSkL0GANshOk7p4AZ3JaFhp+VQvHRlgm5ZIKpcJ6Z09KRx3g+FP1nLq3yyTQ84F2oUGK1LqWDS0HKi+SQjPICtwMcdqNPOEY4jRfvnr0Z3/55kiKM/UqS94jSYROPf2evYnmltAYDGQxAH96unGppGRC8kt3taH+AFDYOclkIxYmxRuz5OivGOjikdEHT4uGze2MLRndgQScE6tuThgf+oUJUQUALbniV0BiKx9BmwcXT1QlhFcyRmpSiRbcm+S82LKmKwXDGeHZHhxj6tcDguYThKBDTWOydgDBJAp8sxhh3kv0YZbxdVZ1RtvQuuGoaAySc+c2pQnzwsaP x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(376002)(39860400002)(136003)(54906003)(33656002)(316002)(5660300002)(7696005)(52536014)(478600001)(8936002)(6506007)(38100700002)(71200400001)(55016002)(2906002)(53546011)(76116006)(9686003)(26005)(4326008)(966005)(86362001)(8676002)(66446008)(6916009)(66556008)(3480700007)(64756008)(122000001)(66476007)(66946007)(186003)(66616009)(83380400001)(99936003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?clpmJ8s7FYPHxCc17sz/RAIOz7Z2IhwB+Lndhe1WvR1erWO3E2wZamb4ti?= =?iso-8859-1?Q?U1icnXxaQvgGl0huTOgqqcZ2iQd+U7YYad6ZV2eC2FlJeRdeRVOHiTa3c/?= =?iso-8859-1?Q?g0Y2UDpFt6wbSJbe5iECyDYw12nW3D8RVVeQ1ilybpWy9A/x294fB+xcGZ?= =?iso-8859-1?Q?N7NqBqe/5KnRyYsPZgB/D0/hewq5OXVdyrNLSnAkEhhgR8PbKINQK/KSDE?= =?iso-8859-1?Q?bOfcvkQCffPyi9oVeNHX0zX5gkQ+FU0G2wD8s2mp/cr+AhDJ5PQdfP7Cko?= =?iso-8859-1?Q?KBI3PmzWy1p8a3uP9ONH8i2S7f/xi47NJvfVEdspNS2004HeXwuW0nUYSL?= =?iso-8859-1?Q?9rkiO+IEGkfIqMf4IIhj+LR1ESDiImY96sFTJeQCa1jUn8DXOs08OmA8o/?= =?iso-8859-1?Q?aVfYQodnmFyLeZ64tXcO9c1X/iVdmxfPPEiDVJs8F6QMQimWkHxkP9U2fs?= =?iso-8859-1?Q?5ZG7n5wBkwY73T7SyuRVRCTA5llCkcVJIW45IgOt9Ix4V1B6tRQBGzhkbI?= =?iso-8859-1?Q?YN2EZCJjP0y4OBFh90J8bKgIk2/vwFL9HnrgJ6qCnC4einh9J4cWW/PvvN?= =?iso-8859-1?Q?OjeoQteDDKmhJih1vSL4M07nW9K7+myJzz5G+vaXuvlHaHQ0blH4U+SieF?= =?iso-8859-1?Q?MSDul0WS48y+6jvT3KQeZoMnJ/r5rFLx/D2kYKx1h4/LywHr/56aTZf5Q+?= =?iso-8859-1?Q?Rl+6cR6TshfrbFIhuduBFAeCGw6cWyM23KEqG9qykJSlTRQnpmpL2IaDKY?= =?iso-8859-1?Q?cfvjxf7gIwWpAGKNdAkonsVxktIo0zWzfZ2LEvQBB4w36gJ6PIaolVM/qJ?= =?iso-8859-1?Q?Wxr1HM1kcwTVY6UdTpKRCDth3EImkVz9DMoMnkDu4EVeGK3l5QOo37dQWG?= =?iso-8859-1?Q?oIRS7kIItQ5l4G2VXqvqlucc9tyPWhLq0EU3J+z2xCoxQU8JQyvPZNoeMR?= =?iso-8859-1?Q?ooVXPyMCvkaj4/GZLUuljVJy54Pqa7EicGmRi9vK/BIF5Pu6WQqdD8f6Fo?= =?iso-8859-1?Q?jRQI/tIOSkjh6vvXpvAOwC2cHAVCs9mpYPQxBjhte/z4QwduIqYk1bTSs6?= =?iso-8859-1?Q?ap587j/TDTJkGAZJPeYeZ1CVcl4SNOuUdJinv91SpecgHiIHVryewyXgQ8?= =?iso-8859-1?Q?fu8OjGm1HkYj9c8F5xng7kTlZ6yM83hJX9UYJUv4JkWTqx+5aCpYNT545L?= =?iso-8859-1?Q?re/MIqkJiYwzn1s4VEJEBfWWrCVcUTaKx2VjlVbB1h3md/AXBCno0UzYbB?= =?iso-8859-1?Q?4x/s38pVFv32hZSnzTRRg+bOICXdrDbzQ+zKAMir5+jTT/wsAOOg3JFlV0?= =?iso-8859-1?Q?GTzdcy/NAon9nuWAHGENwe3XteD47IAuWDtNEWCaY1nh998c3MhnB1dYQp?= =?iso-8859-1?Q?w6OAZjiyH/?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05D3_01D7360B.8D26F640" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f9d0d6a-b046-43da-85e4-08d90411ed31 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2021 15:35:28.9548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DSAyUknDuL2wrhKcan6JUBjoK9gT2L/m4KdD1EQz79uDpUrod3fu3SXf0qmHmtnX3T3SoCiH27Ma5Mt4MEOSfKnryNtf650yOcPaDSOqoVI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8246 Archived-At: Subject: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 15:35:41 -0000 ------=_NextPart_000_05D3_01D7360B.8D26F640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Juergen, https://tools.ietf.org/html/rfc7950#section-7.6.5 states:=20 If "mandatory" is "true", the behavior of the constraint depends on the type of the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1): o If no such ancestor exists in the schema tree, the leaf MUST exist. o Otherwise, if this ancestor is a case node, the leaf MUST exist if any node from the case exists in the data tree. o Otherwise, the leaf MUST exist if the ancestor node exists in the data tree. Let's take the simplest example a top level leaf. If it is = mandatory=3Dtrue -> the leaf MUST exist. The above statements do not differentiate between config=3Dtrue or config=3Dfalse leaves.=20 If the leaf exists, for me, it is trivial that the reply to a = get/get-data operation MUST return it. (assuming it is not filtered out) Anything else would be counter-intuitive and IMHO contradict RFC 7950. Do you agree?=20 If not, could you please describe what does a mandatory=3Dtrue statement = mean for a config=3Dfalse leaf in your interpretation? ------------------------------------------------------------------- IMHO we never stated that=20 Regards Balazs -----Original Message----- From: Juergen Schoenwaelder =20 Sent: 2021. =E1prilis 14., szerda 17:08 To: Bal=E1zs Lengyel Cc: Sterne, Jason (Nokia - CA/Ottawa) ; Andy = Bierman ; netmod@ietf.org Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 On Wed, Apr 14, 2021 at 01:55:04PM +0000, Bal=E1zs Lengyel wrote: > * On the other hand, changing a state leaf from mandatory false to true means always including the leaf in a response. Where do you get this from? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_05D3_01D7360B.8D26F640 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQyMDE1MzUyN1owIwYJKoZIhvcNAQkEMRYEFK3rvLBAGoiA UivCh0Phh1bjFXaIMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEgy RcE6Cead5GluF9xT+zvtqrx5JU3MRHH6uKe42QysWVX6VLXFU/7fS5ewi2hnGQE07bfgS5kJzNSt WHCyBOGcWXf/Fm7Mk+mz0fhSi3LiIPOiyZF4ZJh/XBP+8i/mnkS7t5pjLrBtHipZLj0k9JXnayTv 9v7kwqheJe6cMURUD/eaJrvKbcMsOQwKN+dX1Jqd4Ooe2GFSIMfHZ2qZaGkqCMnAqK2iSVCi1t1m sqNYAd4eXdGNOlp/aECGp1j8N2OSLRrziVWJAi7J3xOtOG3lzcng4k8yVue1ajbDtZXyM3xe5A5h DE9lQc7KOapLcDaS6ZK+MSb9Rv+twEsudmIAAAAAAAA= ------=_NextPart_000_05D3_01D7360B.8D26F640-- From nobody Tue Apr 20 09:26:43 2021 Return-Path: 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 B373E3A29E0 for ; Tue, 20 Apr 2021 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.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 ZXyE2Drg6Lni for ; Tue, 20 Apr 2021 09:26:36 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2084.outbound.protection.outlook.com [40.107.20.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D230D3A29D9 for ; Tue, 20 Apr 2021 09:26:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z29bSrLwZs/QYvSOCBzfo+EqIYx0xcj2O83Q7mkEdTuQofWtrYKBMei1pFBDFCjn2dhiR1TTlL88FixJZQJz9bL/IF+GloSOPQpSKYk3gVJ35UZ3iDjpKurpTjb60qABgd8YIeCN3Vn6eMquEkQoQJfM67WDmJgb5MaOW1QJEEkL8lfdZcbRVyA3c8KQRgxYsDrpGBjZGKOg60mvss0IeSVmbDfCkeLl8auvbIDEnO+uQciunlbtbt++1Mzr073CrzMo+rEhJ87aCkxzJBGICITC09MK0+FTe5i7/J/qnPEj9tskyd4E1Rw5JDkXKx/VMdRNzcb0BFm2HoiIblXwBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CeF/5U2NPPYT43hmJ/nB6jxspL1LJtlA6OFdWKOrftE=; b=lmplSAxSf7e+LAcZdVrpP189NmWUy2fkvpe31Vyf94N6zblR7kJnBr/ddY7Eu7aeksyUnsCfoM39koOrh5N/eu+NYYiyO8rQ+8ZoZRR2JTaIiPI7Cj9kkRrzhXL9vkeEZ0NrG5sj6HAvBhZcMvhkSVKIFsy5oMDWSu0+eaqkzRag8sn46Ljrwry5H5uGZ0BrNOqxxa5NFxT/qETM2lj6KSjg5W4HDbL0QdWZh67p4qbL8vlit6ilApH4ocLBgC4Gnb1tG9j7PdHCZ6v7L71LPk5aKXZJgNE8FrNzZFWcwdrANtc/Rln7BdcqxGDwYDPBioUscizbXhKMAGpW1RxPbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CeF/5U2NPPYT43hmJ/nB6jxspL1LJtlA6OFdWKOrftE=; b=n2de7GK92lHGYmVosDpUfneSq32sOEpAbalkNreuQktcpbW7mFjAlz7xCzzulQ6mQ+UOct5sXJIzQmQqaSaiJVfuQdU54+t+RPZI4U0p/fP5WTKwz54sW9KaWFYMPvfbJyw2X9Ar3nRxCNhhm74Nm4YI/7Hf6EqXIKzk35vM51U= Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0050.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:61::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.20; Tue, 20 Apr 2021 16:26:32 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.024; Tue, 20 Apr 2021 16:26:32 +0000 Date: Tue, 20 Apr 2021 18:26:31 +0200 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel Cc: "Sterne, Jason (Nokia - CA/Ottawa)" , Andy Bierman , "netmod@ietf.org" Message-ID: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "Sterne, Jason (Nokia - CA/Ottawa)" , Andy Bierman , "netmod@ietf.org" References: Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM3PR05CA0092.eurprd05.prod.outlook.com (2603:10a6:207:1::18) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM3PR05CA0092.eurprd05.prod.outlook.com (2603:10a6:207:1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18 via Frontend Transport; Tue, 20 Apr 2021 16:26:32 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5b45ddb8-8a28-4f77-ca91-08d904190f2f X-MS-TrafficTypeDiagnostic: AM4P190MB0050: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: e9ewhlrBW4iirP4YS/qtsMXUS0OKUPZ0jrqWlxSWzuv3DwrU1OMykOdY3abYT/evg1SYQkJxrIucoHr0YUJ5GbUC2te8g8gMjq8I6sCFMDDc7atynoijb8raPnAamvzCT/vdCG22cfbD/QfFMAKjD3V10gsPKRqBytyM29Tz7sGv2QXUykNgJJNFgAlzJ0WKQPPT+/JcoUI61j4WEMiLOcnumR0cDfUifa5/0DRDqJjwH6mTk0F2WXm4fJsuDogZpg5loPQ4DkT4jnX7/TYwGufzgPvUTlb32ugWnmLBQWqMElCBSF7aFfhlYXgqfoSvAKIoQG2NFTCZ4aAZr2BRvyZzerhNy2mm/7y0tx47DhVEYxygYW/Yy5arkLEZ6z0NbaZhM77K9O7ECBoSwiQboZEAj+MM+/G00Ajucd4KkVgwynw0FBBONyxTodx4jGv6RqZooXjL4V3K2tKP6RMewcV0e2a4jsKfHlTQf/rX8BO/vs/69Kk3pMlT8cEklDuqhshT7xqOj8x/aU/lWa+r/2RagKm/larvYYgTVIU5panjd6AVPlFP4dSzXM9/Dc2TNpfpnUtc3w1/C4KGnw/gxo1dHAqNyn6Jtjd6Ol/s+ZbQj+jUmWtGZEIFFieKdA4tTOJpDns/tSZXsb0y+kloi5LoCnXanjl0KDPHdcEa/EZtenr66o45yWqrgWmOSxxJTb4mAKaTMP3g5MvprsnoZVn8qIyrio6lCzBqg+43tM8= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(39850400004)(136003)(396003)(366004)(376002)(786003)(3450700001)(6916009)(956004)(2906002)(54906003)(966005)(66476007)(316002)(26005)(478600001)(6486002)(186003)(38100700002)(16526019)(6496006)(8676002)(3480700007)(1076003)(66946007)(83380400001)(86362001)(53546011)(8936002)(5660300002)(38350700002)(66556008)(4326008)(52116002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?Hbr9LcpzGSIGSZF3qs/skRHgAOqrjVRB68FEFYjprYEQN3D0BDqzlKFxft?= =?iso-8859-1?Q?kOfSM00Kh3LVp97bFtkZ0WbvrDJGjy9s0o7tO5DwyDQZMAjRfNSr2vLUp0?= =?iso-8859-1?Q?EDbdi0x2nLiLYTPEOJHyIxl84/WpC4MfsRea1DiZk51dWx/IEArRGiaXpA?= =?iso-8859-1?Q?ETEsP8VPK8MYXjwiJQhDndLXwqXelhnVZ/GKtt+efvFtj4a4AMdjWBlJx0?= =?iso-8859-1?Q?skowdnmBnQG1JnQhc+HGy7dIoJp4K1uBjehjzOMrf8FKzcHwt/lwm3pGmV?= =?iso-8859-1?Q?ii8shHpmxIsQTFu1alCtuSWqYhy3yA0QXyAcv0yBjn5eiKCjYjWGhdZn30?= =?iso-8859-1?Q?IIJ7D3MpENhNj4HAEvZtaYhJDkTgnjys1Na4CPUdd9IZlob7Ci7YIAmXtG?= =?iso-8859-1?Q?A/gAGQ3ryba9SDfqIUu2Vki9Wu1A89YDtjK13EVGQEgpaRymhBceyrIc/1?= =?iso-8859-1?Q?Glwh12fuADgfGRsNlpOKzX3IPdJfO+dgz5ZiBDZb13b7pa63Ap3GFdFTZZ?= =?iso-8859-1?Q?UCB7jbRkGvHF0cIv22Kg+34n8bsE6SkbUOkWqdNUfD548+E8ddESo0ryke?= =?iso-8859-1?Q?wfxzOYxlp7pej3IGL4EHVHGdhIeyU1JRQCWUCFRljXCUZVm3hzeDLm/ufb?= =?iso-8859-1?Q?elEbV1dleoiJJJORXLYqHOQwmLCAeJESBral8K6DKvYfs8sNIno/CsYM4e?= =?iso-8859-1?Q?wkRBQO0An4kzLK6kSP7VndjxxTKI+vP0/N17IrNi/v7lCcjSmkder7uZMm?= =?iso-8859-1?Q?ITg36uNFKuehMQQ6Fp5LeYXNxZ9sNWEDydoeeL8/KKenSLxupWdhDW72kO?= =?iso-8859-1?Q?voZy1gICp92gm9LljwFJG5KX+alqnwIIROwk9a2RNKiQsm/12Vkj8OIuy+?= =?iso-8859-1?Q?vUsXWLfV4oqTf7BH9dP4S8I/e6vJGosur8p4vWoJeLQrUbITELWwMgm6GN?= =?iso-8859-1?Q?dXdPRBWeTOruUnj55GC3YjqMew8t2b3SA5OWvBKL00ixBGZKw4vmE28jxi?= =?iso-8859-1?Q?zUpzMcIi5/YcFCmKLQatzS+84wqtBZpmkJkjiwlWZT0S2MiJINFef4Pzs0?= =?iso-8859-1?Q?JCP6FzfwvxrXsr09wbXMHKO9wPrHGGF/GNmV06Z1JBF/9vepFf3S8S4gGy?= =?iso-8859-1?Q?zbgs0LfRy4uN77BrwLMo3URIkjdpxtBB/5eHp9QJTJ58i508xdDvnxSuZ4?= =?iso-8859-1?Q?P7ub69LJqdCNE1bQQkaw1Zw/DmTLmjikXeVDqGRKZ+LuRJ+qpfEjia+DLn?= =?iso-8859-1?Q?O0iQLLQU0qkehb/lnXfpB8r+lLIpSaZi4BSBdlYCgr1H8Q9pfuOmTVPENC?= =?iso-8859-1?Q?4xSVgyaPD+ItjLk34kpmlvnRuJvn3JyjpgHF2REIfvVRhgfs11gzS2zYkV?= =?iso-8859-1?Q?kjanFUZmzM?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 5b45ddb8-8a28-4f77-ca91-08d904190f2f X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2021 16:26:32.6254 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DGidfFoPvNPwL0thLO44doBkUXbwmkKcR8348g/NGCZMFE9WxLP0VWSDiU6Df1gvjhi50gICsc14s0m5Rbz4IUV1RfdcUsToBy4MDGr+pEA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0050 Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 16:26:42 -0000 My understanding is that a returns the leafs that exist and that are not filtered. /js On Tue, Apr 20, 2021 at 03:35:28PM +0000, Balzs Lengyel wrote: > Hello Juergen, > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: > > If "mandatory" is "true", the behavior of the constraint depends on > the type of the leaf's closest ancestor node in the schema tree that > is not a non-presence container (see Section 7.5.1): > o If no such ancestor exists in the schema tree, the leaf MUST > exist. > o Otherwise, if this ancestor is a case node, the leaf MUST exist if > any node from the case exists in the data tree. > o Otherwise, the leaf MUST exist if the ancestor node exists in the > data tree. > > Let's take the simplest example a top level leaf. If it is mandatory=true -> > the leaf MUST exist. The above statements do not differentiate between > config=true or config=false leaves. > > If the leaf exists, for me, it is trivial that the reply to a get/get-data > operation MUST return it. (assuming it is not filtered out) > Anything else would be counter-intuitive and IMHO contradict RFC 7950. > > Do you agree? > If not, could you please describe what does a mandatory=true statement mean > for a config=false leaf in your interpretation? > > ------------------------------------------------------------------- > IMHO we never stated that > > > Regards Balazs > > -----Original Message----- > From: Juergen Schoenwaelder > Sent: 2021. prilis 14., szerda 17:08 > To: Balzs Lengyel > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; Andy Bierman > ; netmod@ietf.org > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Balzs Lengyel wrote: > > > * On the other hand, changing a state leaf from mandatory false to > true means always including the leaf in a response. > > Where do you get this from? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 28-0d304a28a3dae2f9&q=1&e=81180de4-8958-40ba-aeb8-c689e3da33e8&u=https%3A%2F > %2Fwww.jacobs-university.de%2F> -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 20 11:21:14 2021 Return-Path: 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 F13593A0C4C for ; Tue, 20 Apr 2021 11:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 jwOfiuzzmv4l for ; Tue, 20 Apr 2021 11:21:08 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 D361C3A0C40 for ; Tue, 20 Apr 2021 11:21:07 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u25so6355644ljg.7 for ; Tue, 20 Apr 2021 11:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zXDZbOBPCkZs7NryZbZC1DZ8YG2WiISL1yv0i9WKywU=; b=bQ+zRTvJPSRMrN0XgwN/l7PMUFLxND4I6mUcSPvBrYqP3tT7lHdNFkM8VuXR60sYg4 v4au5Hbtb8V81mlRcwUFB3xOkjng+bQv2nyrwQ/Ap0lNU8Ir5wLg2kkgz9tYW3vv93wQ AsiHcsPP+uVyfvuFh74QmNfs8z0tVpn+oIZAZpRvBdIVPDzrmTDaWUyFX7gWi6CKd6NF K/FLWbVRf4oON0n6JR/OP0qn2VrVkTDBuuyHRGR1tvXQhsIFbCiUmG4tK168PpGWHJu4 p3yzQ0UXtOqGuenZKXlG196OAf+10SXYp6S7Nz6SZUBfBYSm20gjpEBt5PRhBtn+T4Iz QwCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zXDZbOBPCkZs7NryZbZC1DZ8YG2WiISL1yv0i9WKywU=; b=an+S/HeZmjxfev2R6KIu/JCc4LCuPkkwx86wYfF+JveIRkPNxsiQN+X8fgunqGQ+u2 cV142zCW0tYBxGmaM+VCeqVcMwqfns2R7s9ab+jmFou/eduCDgW4HYEDmbtGANgHqrO3 MzbvZ7Hdwb1q0WUDVV/WC8nNjkmyp/2AP89id5gdhqEPAUBoywEsnvPW2oRiswqdO0du lrdr/DapJxBSUgxKKm+k8kE0Wbi+5QQQ8Ilu0rXocejCrNvIcbLdUx9jSUXTdMtFLH8F 1y2R4EkLf3SzmccDxU6exQ6UZpsSI12PRR6umH0fe1qLTuiwFW47CJW3iLhdNw3Olo8y Y1Jg== X-Gm-Message-State: AOAM533dS/GQkmTnHSfYpOviW8bKVbbrppuRqq2loj1xQG7rtLCsVpkW WuWvsxNzVGA7OHpMebfRnuOipbamep6dGsMTRQDTBA== X-Google-Smtp-Source: ABdhPJzHV2kQgd1QP32iad0zfau5rT5wpZjrj6QwNyclBpAM5rouPBuUi6D99bHenM7CHxNjZI9FX9gCMgVHrLMR6cE= X-Received: by 2002:a2e:bc24:: with SMTP id b36mr6615913ljf.91.1618942860627; Tue, 20 Apr 2021 11:21:00 -0700 (PDT) MIME-Version: 1.0 References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> In-Reply-To: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Tue, 20 Apr 2021 11:20:49 -0700 Message-ID: To: Juergen Schoenwaelder , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "Sterne, Jason (Nokia - CA/Ottawa)" , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001ea30405c06b82aa" Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 18:21:13 -0000 --0000000000001ea30405c06b82aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > My understanding is that a returns the leafs that exist and that > are not filtered. > > Yes -- this is what clients expect. It is not clear that real client apps rely too much on YANG validation of the config=3Dfalse nodes in . The validation of server provided monitoring data was not a focus of YANG. It may not be valid to assume every sentence that applies to config=3Dtrue also applies to config=3Dfalse. Even the NMDA RFC ignores YANG validation of config=3Dfalse nodes. There is a paragraph that says it SHOULD be done, but it really refers to how operational values of config=3Dtrue MAY not pass validation. /js > Andy > > On Tue, Apr 20, 2021 at 03:35:28PM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Juergen, > > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: > > > > If "mandatory" is "true", the behavior of the constraint depends on > > the type of the leaf's closest ancestor node in the schema tree that > > is not a non-presence container (see Section 7.5.1): > > o If no such ancestor exists in the schema tree, the leaf MUST > > exist. > > o Otherwise, if this ancestor is a case node, the leaf MUST exist i= f > > any node from the case exists in the data tree. > > o Otherwise, the leaf MUST exist if the ancestor node exists in the > > data tree. > > > > Let's take the simplest example a top level leaf. If it is > mandatory=3Dtrue -> > > the leaf MUST exist. The above statements do not differentiate between > > config=3Dtrue or config=3Dfalse leaves. > > > > If the leaf exists, for me, it is trivial that the reply to a > get/get-data > > operation MUST return it. (assuming it is not filtered out) > > Anything else would be counter-intuitive and IMHO contradict RFC 7950. > > > > Do you agree? > > If not, could you please describe what does a mandatory=3Dtrue statemen= t > mean > > for a config=3Dfalse leaf in your interpretation? > > > > ------------------------------------------------------------------- > > IMHO we never stated that > > > > > > Regards Balazs > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 2021. =C3=A1prilis 14., szerda 17:08 > > To: Bal=C3=A1zs Lengyel > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; Andy > Bierman > > ; netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Bal=C3=A1zs Lengyel wrote: > > > > > * On the other hand, changing a state leaf from mandatory false to > > true means always including the leaf in a response. > > > > Where do you get this from? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > < > https://protect2.fireeye.com/v1/url?k=3D9e758f86-c1eeb764-9e75cf1d-86073b= 36ea > > > 28-0d304a28a3dae2f9&q=3D1&e=3D81180de4-8958-40ba-aeb8-c689e3da33e8&u=3Dht= tps%3A%2F > > %2Fwww.jacobs-university.de%2F> > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --0000000000001ea30405c06b82aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 20, 2021 at 9:26 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
My understanding is that a <get>= ; returns the leafs that exist and that
are not filtered.


Yes -- this is what clients expect.
It is not clear that real client apps rely too much on YANG validat= ion of
the config=3Dfalse nodes in <operational>.

The validation of server provided monitoring data was not a= focus of YANG.
It may not be valid to assume every sentence that= applies to config=3Dtrue
also applies to config=3Dfalse.

Even the NMDA RFC ignores YANG validation of config=3Dfal= se nodes.
There is a paragraph that says it SHOULD be done, but i= t really refers
to how operational values of config=3Dtrue MAY no= t pass validation.


/js

Andy
=C2=A0

On Tue, Apr 20, 2021 at 03:35:28PM +0000, Bal=C3=A1zs Lengyel wrote:
> Hello Juergen,
> https://tools.ietf.org/html/rfc7950#section-7.= 6.5 states:
>
> If "mandatory" is "true", the behavior of the cons= traint depends on
>=C2=A0 =C2=A0 the type of the leaf's closest ancestor node in the s= chema tree that
>=C2=A0 =C2=A0 is not a non-presence container (see Section 7.5.1):
>=C2=A0 =C2=A0 o=C2=A0 If no such ancestor exists in the schema tree, th= e leaf MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0exist.
>=C2=A0 =C2=A0 o=C2=A0 Otherwise, if this ancestor is a case node, the l= eaf MUST exist if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0any node from the case exists in the data tr= ee.
>=C2=A0 =C2=A0 o=C2=A0 Otherwise, the leaf MUST exist if the ancestor no= de exists in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data tree.
>
> Let's take the simplest example a top level leaf. If it is mandato= ry=3Dtrue ->
> the leaf MUST exist. The above statements do not differentiate between=
> config=3Dtrue or config=3Dfalse leaves.
>
> If the leaf exists, for me, it is trivial that the reply to a get/get-= data
> operation MUST return it.=C2=A0 (assuming it is not filtered out)
> Anything else would be counter-intuitive and IMHO contradict RFC 7950.=
>
> Do you agree?
> If not, could you please describe what does a mandatory=3Dtrue stateme= nt mean
> for a config=3Dfalse leaf in your interpretation?
>
> ------------------------------------------------------------------- > IMHO we never stated that
>
>
> Regards Balazs
>
> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Sent: 2021. =C3=A1prilis 14., szerda 17:08
> To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
> Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; Andy Bierma= n
> <andy@yumaw= orks.com>; netm= od@ietf.org
> Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13=
>
> On Wed, Apr 14, 2021 at 01:55:04PM +0000, Bal=C3=A1zs Lengyel wrote: >
> > *=C2=A0 =C2=A0On the other hand, changing a state leaf from manda= tory false to
> true means always including the leaf in a <get> response.
>
> Where do you get this from?
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103
> <https://protec= t2.fireeye.com/v1/url?k=3D9e758f86-c1eeb764-9e75cf1d-86073b36ea
> 28-0d304a28a3dae2f9&q=3D1&e=3D81180de4-8958-40ba-aeb8-c689e3da= 33e8&u=3Dhttps%3A%2F
> %2Fwww.jacobs-university.de%2F>



--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>
--0000000000001ea30405c06b82aa-- From nobody Wed Apr 21 01:45:12 2021 Return-Path: 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 9BE483A1BB9 for ; Wed, 21 Apr 2021 01:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=ericsson.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 hzkpeUNTdRFh for ; Wed, 21 Apr 2021 01:45:06 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2070.outbound.protection.outlook.com [40.107.21.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59803A1BB7 for ; Wed, 21 Apr 2021 01:45:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a0CQ5MWWrVCgGDo+yeJBGWoi5mP2Ln7zt8Hsgv8wJx97P2IIruydCt/Bdkgmw01UBIT3WI7XdvmnHL31fdwmNx3aeXHHGIcGURexbvlX2+4djAfQfT5dQeWm0FB2BR1aA/9KJImdd/DI/vjzgfGL6OAnlvisloEoBceAbATbZJNJP57VV3XvRjbskPfMhUia0zimmOUY7XvAx6PaLJmm4g7UQrHUf6iTKKB7yKEJmKU2vWg0svR5QIky6JgnqsG5/4ImlB8myyRCidGLxFRmVsC2V+FKMue6I7Zm8WhLOr/xbGoipQR73dvEGxUluKv2oOV4KIniPx7agkDUiic1GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zX9gJdjI+zQTvxBMfKnobc16Q7xZUaaD/2zNnupWFvg=; b=EPCYRnif1uaTWfSH05+jChaqRxREgr32d0Au8TZsreIZG+9K2yt/8w4ACghNtViQmc+trM9If6p5vS8CBdmtahV1xNe1ppIXJ/BNKgfR7TIM8ZCzO/A3ge4JU3l8QwZMm6/5+1/Shz6ovhfPW14Mv8xi74OEkimGFUA32hPFe5ZAja4HgCprm42b4v0TTGCS6gf7T2TEUbSueHGigrPL2hNP/P9gBTJ15W6g/6SNtu6EYTYTxyLXbVER0sQQ/HzckafqOqKHu/jvD/z2M/5u5QnfqxmzZvBkwTLYLN8JpL1/ssbxhZX6TSBTnAdUS/K6zMQq7uPbLFtOZRA0zr7wtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zX9gJdjI+zQTvxBMfKnobc16Q7xZUaaD/2zNnupWFvg=; b=n+Bu5SuV5hdgQYSg9bLs07BhLNx/P9S1k4q0UJbOzA29vyxLELhGkueuj0YPLx33e7EendnYjCVV5hA2rGvmFSfIn34NTY1I810N/J5wnsUcTdfDIpD7HacpEy17nEWgIifuMh6eSDn8/6YiYXJnP8QSDVNfezr+H5LSMrJxh0k= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8294.eurprd07.prod.outlook.com (2603:10a6:20b:329::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Wed, 21 Apr 2021 08:45:02 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e%7]) with mapi id 15.20.4042.016; Wed, 21 Apr 2021 08:45:02 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Juergen Schoenwaelder , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Thread-Topic: Compatibility of config=false data Thread-Index: Adc1+nRtif5YsBpWTgmEUWyshSkyCwAB3dmAAAP97IAAHfRO0A== Date: Wed, 21 Apr 2021 08:45:02 +0000 Message-ID: References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.248.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 174111f4-cd9b-4a67-30fe-08d904a1c153 x-ms-traffictypediagnostic: AM8PR07MB8294: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XNpWbRVxrXIxhUbpLtWRO7Rsj4grQ64FjRChpR7lNnp7cjlhqYoPeZQoXw4+ADc2M3GF5XZu5NG3/szOZAoKlaZ2tbb06Ykza5x6BW3M+BYgN2eF2Wwj2UYw94MIOtvSh0B7C/PCUGTpzgBzk591fBTHegJklWHbYoKcEHaJN02dpfsvNjO1oOVSJIG9iR3e7QVRDw5wIJAyH6RW2WW/Cni6bFficAt1o9/lph8zZiWzpYZXVQntDuQnEJg+anS0d91tY2v/EBCdGUnGJEcGUZyTf42ChR2BJA5iXshPPwObeGH44c7qzW6YjJCoch5bpkwQFiC3dcPp/eRjvPv/jqFJuNpvyfWZBIIuKSIlIy+R8m7OCFvQlmr0VIeJZJ4l12PSNyuuLOMCA6MmmK9WzwyxyKnKNPEu0gUcXsIfYz4JjrRWF5b7db3HUyeFBXxBvkFnPUT5yB7FxHEF2P89mPi+zIPh+OqEuvsIQFG+AVEqTcBkHxIVD5U55UioWZjBQ/VC5R6xgC8esjbjLlaHIfnGScndAxxYL9Ynm4zb9Ck387tvOJviHhPAdkHMHVwjsch7mZqVE1Qz2k3VEatrOnvbNSrmcdKfpHNN09DqhxD859bL19uPxaRov53FZ1xsvHUgi+l66Bt5fuOsA+2xbtS3X70PYcYcRUlCHE6jRg2pUonP1uPs6lb4lPWlJXxY x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(136003)(396003)(346002)(366004)(166002)(85202003)(66574015)(53546011)(6506007)(38100700002)(66616009)(52536014)(26005)(66446008)(122000001)(66946007)(66476007)(9686003)(99936003)(64756008)(66556008)(55016002)(33656002)(86362001)(478600001)(9326002)(8676002)(85182001)(7696005)(71200400001)(5660300002)(8936002)(3480700007)(2906002)(83380400001)(966005)(186003)(316002)(76116006)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SGZFUG1RNmFNdkcwY0hXWXg1anhscDV6bFYwZ0owbDdWZUVpeHgzMWFoNXFS?= =?utf-8?B?OUZWa0tqZ0EvYkhPNVZwRXBVQm9kZ3JWemVrUDRldDJXdXdyd2dUN3p6N0hm?= =?utf-8?B?YUVERUdPRGVDNFRsOGo4bk40VzgwanY0am9ldmUyNjJNTDdrWDFReTdGR29i?= =?utf-8?B?bElVdnVuejBxV1dPRnpCTW11LzZVVDBrc3NrY01aTlVpSXpBbHU2dE5zS1Vx?= =?utf-8?B?L1lhV2k5QTdDQmhBYUtoUXZSaWxEV21ja0kvRW1LQW0vVDhoaU5nK2NtMy9S?= =?utf-8?B?LzBXeUFTR3JEbVFEZE9jRmNYczY0M1YxNVRsdk16Y0l4NS9rc0R3NW1YZjdF?= =?utf-8?B?ZjhPdFFVSHVYalBXTkFGak1vS3lsK1pRci9Lc0ZDNWg0ZU92dXhiampHM2RP?= =?utf-8?B?Z0hEbWlVSTAvTlBoZlB6aUg2M3EyU3hoTm1SWDhpNU5PWllySnRPb1VrSUEv?= =?utf-8?B?Nkd4eVdGdkx0NnA5UEdaS3lhVzFDWDgrZGdmT2JBM012ZmEwSHNmVUM5UVRL?= =?utf-8?B?bWtEc3F0T00xTkJpSDR1WExHUXB5eWRUT3dKaEw4UTNnSWRoWmE5VG45OWVR?= =?utf-8?B?K3VWTzgwaTUrRVQydGwvcEFkWEpyUnhYbXpVRUd1WkwvS1JuUmJBN1d2VFhr?= =?utf-8?B?dGJ6MW1tRm5XQm13azJXMHVYS3pDSlRTbjExYXFVdld2V3dJTXV0SC9SZ2pL?= =?utf-8?B?am9MQVBmZ0Vac2szNDRVQXJsY0UwaTR2ZGlseEJCWXVBbXRObXIrQ01uQ3Vk?= =?utf-8?B?UGRyM29VZk9qaFgrTTI3RmEvK1MzdmJEejhOVDVWZmJuMTNFR1FuU1hZMzds?= =?utf-8?B?cXVxTlJSQUxoU1ViY3Q3OVRKTHJmOWd0a2hkazRwTGpmMjBsbDd2U2lzMTFH?= =?utf-8?B?eTBTSjU2bVlUS1RhYmNUT1ZIN1V3MENLVGNJd3p5ZFcyY0p6THNpNUlrOUYy?= =?utf-8?B?dEFEQ1RyaXRoN1JnVEdQcnp0amUwTWxTVnM4eHhDNDVjWDljaXBLWDJ4RmI1?= =?utf-8?B?QXZWeEovSXJaMUg1WEY4allRcGprVmJ0R24xdjFVbXVzTXZYa016am94c2xu?= =?utf-8?B?MkZSTGw4bDhBOFhjZm1Ncm1aZzUvalYvVjJLS1RTOWEvUjB1MUs4Kyt0VFdo?= =?utf-8?B?K2h1S2JGQUxhbkFFUnVzZndaWlFxNFhpOFI3alBxc2d6bUZVOGhSVURnalMw?= =?utf-8?B?amJQN3hZMkxhNDRSTi94QU5odVcwZGlFUjkrVFpGKzR0U0IzRGNyYzBzaCti?= =?utf-8?B?UDF0dDk1cUk0Zzkwd2VMelNwNjd4bXkzdjhZMGl2cnNRYzNhYTd3azU1d2Y0?= =?utf-8?B?aWJHWXA2MjNsWmcwR0VMTERKOVFtNkdYSWREV1NudWVjN1Z4bWdyNitzU2xJ?= =?utf-8?B?VXVpaEVTVzdjV2owUkZndUU3c01qamxvSkxJdksvam5MYWI3a2dvcllIbTJH?= =?utf-8?B?WkpFQ0p4OWl4cU5XTkwybXErUDRnR0h4WW9yUUJzUjM2V092SzJHQVFvelJh?= =?utf-8?B?NFNJeWk5c0RlbUc1aThMOWFUL0JER0Y3VER0Uk9QYzhsZVkza2dEMGcvVEdh?= =?utf-8?B?OERrU0kzMVlMSkIySkJrMGIwZ2VkSkpuSDM1RXRwajhCYml2eVVSR0hBSE03?= =?utf-8?B?b1RjNWYvS01iMnJ3SUlQbCtaSExkYWt2V3N4Ri9KZ3VneStvVytoTmUvUElR?= =?utf-8?B?VzF4VVQzNXdNMk42ZEZkQmF1dGEzV3RXRWN3WHRmQ0F1TWhXYU9Ia0x5cHlm?= =?utf-8?Q?S7BVUoPoPePuarJOFom7YBu56KzUeI5xU2l+5sk?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05E5_01D7369B.6142D680" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 174111f4-cd9b-4a67-30fe-08d904a1c153 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 08:45:02.8310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sDLT5/eiRX8RqwKvvi0hMAErzbRemI7V1Esr/lQN+OcWbAoCV80cLmE9jz0Gdfc5UVu4hzaua4RoJb6ZFnZt0XfsOD+0c9qY1Hb9jQ0VtkI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8294 Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 08:45:12 -0000 ------=_NextPart_000_05E5_01D7369B.6142D680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05E6_01D7369B.6142D680" ------=_NextPart_001_05E6_01D7369B.6142D680 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Andy, While NMDA states =E2=80=9Cit is possible that constraints MAY be = violated under some circumstances=E2=80=9D=20 * this was never declared for non-NMDA systems, so IMHO a client can = reasonably assume that if mandatory=3Dtrue for a config=3Dfalse node was = declared the reason is that it will always be present; otherwise it = should simply be mandatory=3Dfalse. * IMHO this allowance for the operational datastore is for = extra-ordinary situations. In the normal case as defined in the = NMDA-RFC=E2=80=9C SHOULD conform to any constraints = specified=E2=80=9D. =20 Regards Balazs =20 From: Andy Bierman =20 Sent: 2021. =C3=A1prilis 20., kedd 20:21 To: Juergen Schoenwaelder ; = Bal=C3=A1zs Lengyel ; Sterne, Jason (Nokia = - CA/Ottawa) ; Andy Bierman = ; netmod@ietf.org Subject: Re: Compatibility of config=3Dfalse data =20 =20 =20 On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder = > wrote: My understanding is that a returns the leafs that exist and that are not filtered. =20 Yes -- this is what clients expect. It is not clear that real client apps rely too much on YANG validation = of the config=3Dfalse nodes in . =20 The validation of server provided monitoring data was not a focus of = YANG. It may not be valid to assume every sentence that applies to = config=3Dtrue also applies to config=3Dfalse. =20 Even the NMDA RFC ignores YANG validation of config=3Dfalse nodes. There is a paragraph that says it SHOULD be done, but it really refers to how operational values of config=3Dtrue MAY not pass validation. =20 =20 /js =20 Andy =20 On Tue, Apr 20, 2021 at 03:35:28PM +0000, Bal=C3=A1zs Lengyel wrote: > Hello Juergen, > https://tools.ietf.org/html/rfc7950#section-7.6.5 states:=20 >=20 > If "mandatory" is "true", the behavior of the constraint depends on > the type of the leaf's closest ancestor node in the schema tree = that > is not a non-presence container (see Section 7.5.1): > o If no such ancestor exists in the schema tree, the leaf MUST > exist. > o Otherwise, if this ancestor is a case node, the leaf MUST exist = if > any node from the case exists in the data tree. > o Otherwise, the leaf MUST exist if the ancestor node exists in = the > data tree. >=20 > Let's take the simplest example a top level leaf. If it is = mandatory=3Dtrue -> > the leaf MUST exist. The above statements do not differentiate between > config=3Dtrue or config=3Dfalse leaves.=20 >=20 > If the leaf exists, for me, it is trivial that the reply to a = get/get-data > operation MUST return it. (assuming it is not filtered out) > Anything else would be counter-intuitive and IMHO contradict RFC 7950. >=20 > Do you agree?=20 > If not, could you please describe what does a mandatory=3Dtrue = statement mean > for a config=3Dfalse leaf in your interpretation? >=20 > ------------------------------------------------------------------- > IMHO we never stated that=20 >=20 >=20 > Regards Balazs >=20 > -----Original Message----- > From: Juergen Schoenwaelder >=20 > Sent: 2021. =C3=A1prilis 14., szerda 17:08 > To: Bal=C3=A1zs Lengyel > > Cc: Sterne, Jason (Nokia - CA/Ottawa) >; Andy Bierman > >; netmod@ietf.org = =20 > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 >=20 > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Bal=C3=A1zs Lengyel wrote: >=20 > > * On the other hand, changing a state leaf from mandatory false to > true means always including the leaf in a response. >=20 > Where do you get this from? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > = = 28-0d304a28a3dae2f9&q=3D1&e=3D81180de4-8958-40ba-aeb8-c689e3da33e8&u=3Dht= tps%3A%2F > %2Fwww.jacobs-university.de = %2F> --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 > ------=_NextPart_001_05E6_01D7369B.6142D680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Andy,

While NMDA states =E2=80=9Cit is possible that = constraints MAY be violated under some circumstances=E2=80=9D =

  • this was never declared for non-NMDA systems, so IMHO a client can = reasonably assume that if mandatory=3Dtrue for a config=3Dfalse node was = declared the reason is that it will always be present; otherwise it = should simply be mandatory=3Dfalse.
  • IMHO this allowance for the operational datastore is for = extra-ordinary situations. In the normal case as defined in the = NMDA-RFC=E2=80=9C<operational> SHOULD conform to any = constraints specified=E2=80=9D.

 

Regards = Balazs

 

From: Andy Bierman = <andy@yumaworks.com>
Sent: 2021. =C3=A1prilis 20., kedd = 20:21
To: Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de>; Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>; Sterne, Jason (Nokia - CA/Ottawa) = <jason.sterne@nokia.com>; Andy Bierman <andy@yumaworks.com>; = netmod@ietf.org
Subject: Re: Compatibility of config=3Dfalse = data

 

 

 

On = Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote:

My understanding is that a <get> = returns the leafs that exist and that
are not = filtered.

 

Yes -- this is what clients = expect.

It is not clear = that real client apps rely too much on YANG validation = of

the config=3Dfalse = nodes in <operational>.

 

The validation of server provided monitoring data was = not a focus of YANG.

It = may not be valid to assume every sentence that applies to = config=3Dtrue

also applies = to config=3Dfalse.

 

Even the NMDA RFC ignores YANG validation of = config=3Dfalse nodes.

There is a paragraph that says it SHOULD be done, but = it really refers

to how = operational values of config=3Dtrue MAY not pass = validation.

 

 

/js

 

Andy

 


On = Tue, Apr 20, 2021 at 03:35:28PM +0000, Bal=C3=A1zs Lengyel = wrote:
> Hello Juergen,
> https://tools.ietf.org/html/rfc7950#section-7.6.5 = states:
>
> If "mandatory" is "true", = the behavior of the constraint depends on
>    the type = of the leaf's closest ancestor node in the schema tree = that
>    is not a non-presence container (see Section = 7.5.1):
>    o  If no such ancestor exists in the = schema tree, the leaf MUST
>      =  exist.
>    o  Otherwise, if this ancestor is = a case node, the leaf MUST exist if
>      =  any node from the case exists in the data tree.
>  =   o  Otherwise, the leaf MUST exist if the ancestor node = exists in the
>       data tree.
> =
> Let's take the simplest example a top level leaf. If it is = mandatory=3Dtrue ->
> the leaf MUST exist. The above statements = do not differentiate between
> config=3Dtrue or config=3Dfalse = leaves.
>
> If the leaf exists, for me, it is trivial that = the reply to a get/get-data
> operation MUST return it.  = (assuming it is not filtered out)
> Anything else would be = counter-intuitive and IMHO contradict RFC 7950.
>
> Do you = agree?
> If not, could you please describe what does a = mandatory=3Dtrue statement mean
> for a config=3Dfalse leaf in = your interpretation?
>
> = -------------------------------------------------------------------
&g= t; IMHO we never stated that
>
>
> Regards = Balazs
>
> -----Original Message-----
> From: Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> = Sent: 2021. =C3=A1prilis 14., szerda 17:08
> To: Bal=C3=A1zs = Lengyel <balazs.lengyel@ericsson.com>
> Cc: = Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; Andy Bierman
> = <andy@yumaworks.com>; netmod@ietf.org
> Subject: Re: [netmod] YANG = Versioning Weekly Call Minutes - 2021-04-13
>
> On Wed, Apr = 14, 2021 at 01:55:04PM +0000, Bal=C3=A1zs Lengyel wrote:
> =
> > *   On the other hand, changing a state leaf = from mandatory false to
> true means always including the leaf in = a <get> response.
>
> Where do you get this = from?
>
> /js
>
> --
> Juergen = Schoenwaelder           Jacobs University = Bremen gGmbH
> Phone: +49 421 200 3587        =  Campus Ring 1 | 28759 Bremen | Germany
> Fax:  =  +49 421 200 3103
> <https://protect2.fireeye.com/v1/url?k=3D9e758f86-c1eeb7= 64-9e75cf1d-86073b36ea
> = 28-0d304a28a3dae2f9&q=3D1&e=3D81180de4-8958-40ba-aeb8-c689e3da33e= 8&u=3Dhttps%3A%2F
> %2Fwww.jacobs-university.de%2F>



--=
Juergen Schoenwaelder          =  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587  =        Campus Ring 1 | 28759 Bremen | = Germany
Fax:   +49 421 200 3103        =  <https://www.jacobs-university.de/>

------=_NextPart_001_05E6_01D7369B.6142D680-- ------=_NextPart_000_05E5_01D7369B.6142D680 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQyMTA4NDUwMVowIwYJKoZIhvcNAQkEMRYEFPeHptKhI4IP ncpy/wcgyMnb+FPnMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAFtH 3hiJSmhTj6Yvfmqdg5X1BrsDjTIqq+leY7AweJFlm/KksYpWxsP5Jvs8Ero64rRCoPJoXMpSX67v 6X1Nh6x65eq+N5sjz5l1VHh618FiVtolaN3SEncS00yWaax4GG/0BSWTL+H/XIPUPSTSlHO6TPqX zWpDPy+ybMRkQH2f4qwn4Duai2YlpBEyW2NfCAwZxZB/o1wkJCLaydL375FuPPqpPQyQ6p32xhyR m24B/T69brgBWEYatZeIb3s4S+flqA16l72gJwvJi9EW3b+XPAXx/pImPzLRDFx4lOtkjaP6z1kV gFJBjXzirRiWGEBaxnY/ovcsH5K3L+qVfJEAAAAAAAA= ------=_NextPart_000_05E5_01D7369B.6142D680-- From nobody Wed Apr 21 03:32:39 2021 Return-Path: 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 BFB483A1F6F for ; Wed, 21 Apr 2021 03:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=jacobsuniversity.onmicrosoft.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 AvBWPPcTPAcU for ; Wed, 21 Apr 2021 03:32:32 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D053A1F6C for ; Wed, 21 Apr 2021 03:32:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZM5mYM7RpCTG9Rh/0X8YB/F2LXZQ2xBUIbmdPLxjknLSUfNauvitxVx/PRBVpry4t9ba3tTCpb22RyKVtYg2uKLroM8lXQ3aFFwpZ1PCNi6ZhZW68Ybtnh2RaLpUZyGbE+EspeUkcKZBgiPBG0B+HhX0+vjSOuvziGbY5Tbup5tOYcLqEjzl7pT7ZpOR6l6ZQ+BuIMkq7VYRmweHZKqYQ64Dha8hK3NQQCmbaeHzP595c95VTSFcgraFSfBr7XpoM6JX7AoUGYNjoBHUAV+nZLPS/r63V711CK0X8fq7krmJLPRrhnvBWUsCfM1wqTRgyuvuZYfFNmo6G/FaGPW1bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NnTW0hfjENLdNooybeKjWcRlY6KW3PeCg182U++xYIc=; b=CYiPkVRdSd2Sgdeem7v8KpY/0AHhm2p+KOjHVkevy6mh5AlWBwn0yIuNXXYUrgvpMEWF1Je9wZa3+Jos0GQMck0OP8x7toVZDfvPZsgRA3giQST/6wSb3/FIn4pd4k4CE4C/DqjaZVan/1DWTsmIGfVSyf2rS1t51VfBF95J86WkYD8g4wex/cpPl1hvbSfsbwQ2AabTWRBClN5pBBP1tNWxOjgay0ep87dO5BFgktlK/GHInBzk4zCZEheW7aCuEWw0fJATG+QS6rcP1FvD4a3OIXq1Uq3c7cbNVqhvg1UtiJGxvWdZzaPUdRf5CwSyitBqvILCB4T45FnjyHpmvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NnTW0hfjENLdNooybeKjWcRlY6KW3PeCg182U++xYIc=; b=MjeGS1YPGRDcdpXe2JRvIiodNBpC1OzhJ+NgXoYVlqmxBYkGeNsX2HZmPvXB1KD07N9/dAAyRdWUwqlp/7STZ1/aWvCi5mEY+EyK9beYtEwNyybE2MSKhE4Kv8wsKvKzswBJCt+l22Phw8cysb4LjAnoDi9TyO0J/RDt1vnkyDM= Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0738.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Wed, 21 Apr 2021 10:32:29 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.024; Wed, 21 Apr 2021 10:32:29 +0000 Date: Wed, 21 Apr 2021 12:32:28 +0200 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel Cc: Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Message-ID: <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR08CA0001.eurprd08.prod.outlook.com (2603:10a6:208:d2::14) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR08CA0001.eurprd08.prod.outlook.com (2603:10a6:208:d2::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20 via Frontend Transport; Wed, 21 Apr 2021 10:32:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 76345732-6c68-4912-72b5-08d904b0c35d X-MS-TrafficTypeDiagnostic: AM0P190MB0738: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vIYQ48mMQHPF2dGGBPZqPPqKS2J3T38WXB33toihS6IeQQ4dmx0/gQvYq31l0nLkHSyrZKKZSIdAvPkUJW5nRNWQdp8pTppzAWfp4nLG8u4jnQAVdCJEDk/JooBhA3PjGA//19xblWSrVuIC8LtN47WBbAA9nIWkIAe188Xx6T1k+nLgQHd/gZZOy0ItF99zsniQzqfSinVCEYfej9dPPCXXk9arNjY0pju86eiFk9BO4UtH0YwBQAZAx9kQwAIKhvP202UgtHaVBieBwfs13VP6B4nG8MHSbCKuIk6bAiRirAeZqtKvryVpL3e6suQ6zTfeeUtvB2j0QRWL9R1R78za3g226yVST9VC11adrxD6IdQcOT4vK9lZz4HCa1lx3c+aJqgtsNBg3ZvWYxiZU9Hkt4sNNsLRC/lAiASY70nx0A+g1tPgZ1t8yP61kqH1yeiMQggcARu1mHhELZaK9aiS/OWRqJtXhIKY6NT9nKgSef6R+eBUI25HqYaJHAflsPIMIL/z+Pxo1fSlu2K0NM9iNm2UxmzePe/ZDyRYMudcDnaviHXSXaCchkR+IFaOIYL6PIjKgAYGWe12XB48xzQm+CZd3l12fpzJPQcTRgf0a9J/IDzPdJGhEP8C/xC5TJFut2dIq+E3NuHFava7LJzi4HbTVNlD8I6bXHycRLFNNwCxmMXdGlIQPrkXSIVVmOjZK70/uSodwzbUsEvM61rouSjZ0WSULlqUD8y4aIs= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(376002)(396003)(39850400004)(52116002)(38100700002)(956004)(66574015)(478600001)(186003)(6916009)(66556008)(786003)(3480700007)(66946007)(66476007)(6496006)(316002)(54906003)(83380400001)(5660300002)(6486002)(86362001)(4326008)(8676002)(1076003)(966005)(8936002)(3450700001)(38350700002)(26005)(16526019)(53546011)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?NTlwb3VCMWRjcENrNEVKUE1EM2FzMi94dDRGOFgwUzdYRFNZZnR1QnRjZ25i?= =?utf-8?B?eDgwZWw5elRDMnpqSVhLRnhUUFdXR1BqWjQzV0w0M3RPd3gyYVNFeDVNKzJy?= =?utf-8?B?dDMwZnhuN3BEZzh6enFvSW53ZWdCbXBvWE4rSzN4VE5rOW8rN2lZTm9RTVFV?= =?utf-8?B?TkNwRTM1VUtNdEVyYm95eVdCQzd3RXF3aGZqN1FZdTlRcC94QTNFcWx0M0Fj?= =?utf-8?B?dGk0dVgrTjRLRXEvbDdoQXI3VDhGbE9oV3k3aExGMzY3RTZBdUJEZEZuRG5j?= =?utf-8?B?THlYbEY3Vk94WnVZckh2R0tkNDNrMFRuSUx0QTRFNWJaYWdxUnBTc25LcXJI?= =?utf-8?B?MjVqNThDbGdIKzlrWGtXYlZ0V3F2T1NQcDlzV0JLcnd2Wmx4enNNZnl2T2xE?= =?utf-8?B?a0R3UHRXalQrazNxci83R0JnajhySm54czhzQlVOZDRsbGptNGRjdTFWRS9O?= =?utf-8?B?VTdEQmNPMHVEa0NqdDNrOWc4RVZGZVpmTHFKSEF4aHhtT1VFRVRtcUZsVTEx?= =?utf-8?B?Ym5nSmU2QWxjQkM1cENGUno0bG9saE9PMjRmeEducWRURHgybGR4bWRMenpP?= =?utf-8?B?R1RiamZYcWlsSEk4Yk5sWlM0YmtuTGRHcll5OVBWOHdhb0pKUHZzdWhMMVR2?= =?utf-8?B?clEyZDh2cTFyWjk2aFk0Wk16bzF2OWRpYnhZR0xFZWxlbTVSbnZWclJTb25U?= =?utf-8?B?dFVvdjF5WlQrditpMHFHK3hpQ1J2OHl0cmp6Vkx4T1N5WktWL3lCdkNiMHQv?= =?utf-8?B?U3FKZWVqMkVIdlZ1MGovNTZ0M0VKK1ZWZGoyTUZUYm1XMFIwTTlLdC84M3lP?= =?utf-8?B?dENHWHlLQ2treWpSSDJFZVl3UE5wSHQ2cUdzMU1rZFA1VHhBblFsRFFtNTBP?= =?utf-8?B?S05YZ2FsOFBINWtFL3R4WnpaeElFWWZyRm9FcU51T3NGY3hIVlEvU3cvcmNi?= =?utf-8?B?dnRaWTNjNGpmYVJrU3R5NEZxYlJ4ZDA1RG9oOHBucWYxU2FQOXlhUDMyVTRv?= =?utf-8?B?R3NTRWlmRkZPY1FMY1M0Z3NXWXhiUEswWVRrMXRiNkppN0l6WUpIcVUxOUNa?= =?utf-8?B?ckVsa1V4d2N3OEhrbUtZZ0pQQ1ZHa1Bibm1ONjZGaitBRmdTUGRFLzlBQ0g1?= =?utf-8?B?YkgxRUNFVGo4QkU0R2JldisybEZMcGd5M0tibXFWY09xNW8rK1g2QjBianZ6?= =?utf-8?B?c0FSb2ZvUG4yczBRVXR0S3FXT2hWYXFVaURabFlKQTQrby9SSHk3N2QxZmdv?= =?utf-8?B?KzBDY3QxN2g5bEJTTm4zVnRTM0RVZGFKWmVZd3VVdlIyd2UwRUpOeHRtMVBI?= =?utf-8?B?OG5SczlTYTJLVk1DVlg0VXg3a1VqWnlxdjFLa1NUODBzREhiOUVVSGtHNGlD?= =?utf-8?B?cFUxckhCdGlTbXRaWXJSV0RmaXd5bTQwY2Q2NWpxVndndjg3UDR6bGdZWGo3?= =?utf-8?B?aFJLbEFtTTlsMFFmWlFUblo4WjFQTkxIaVhqRDlVTktLbzZDRE5aR3JlV1d5?= =?utf-8?B?Vmd3WjBiQmJCQXVOMEhGR3c0Y1o3Tnd6SStiSjFDUUlLTzFQR2dZVU84MzJX?= =?utf-8?B?OUVoQmZZNVQ5eERyQnNvdDdFOFMxWEFTQnN2STZBelVRL2hzQ2FRTXZQRm1w?= =?utf-8?B?bExISFJyL0NrTkNia2pWUHR1NzJaaDMyTlhtYzhmMm5CT1dnaThDNWxsQmhT?= =?utf-8?B?dE9VRXo2QVN1V3hpR0NGTEJFdnQvZGMvOUlPZ3cyWlEvRmFHYXNUaE5WZ0Yw?= =?utf-8?Q?4kZZtlSlEmu7keswycpYU4+zHwNqAG+VID+Oxoi?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 76345732-6c68-4912-72b5-08d904b0c35d X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2021 10:32:28.9416 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9zCmxrrixo2zbk1rYcmfM5IU5EtaRa0I7znZqJLFZ861LnNQvyT5Xp0xMcE/fIgUAE2T8YMC7yuMiLR1uDTb1S2a1xesIboldvtf+1zYtTs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0738 Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 10:32:38 -0000 RFC 7950 section 8: Several YANG statements define constraints on valid data. These constraints are enforced in different ways, depending on what type of data the statement defines. o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. o If the constraint is defined on state data, it MUST be true in a valid state data tree. The main difference between configuration data and state data is that a server can keep the configuration data in a valid state by rejecting any changes that make the configuration data invalid. If, however, a server reports an invalid state data tree, then obviously the server did choose to do so and the clients may have to deal with it (which includes the option of the client to reject all state data since it is invalid, but that might not always be the best or most desirable option). If there is a mandatory state leaf that the server can't implement, what should the server do? The worst of all possible solutions is to report a fake leaf. This has happened quite a bit in the history of SNMP and this is really really bad. Instead of reporting fake values, it is far better to not report the leaf so that the deviation is clear. Ideally, the server formally declare the deviation and all is good. When the NMDA document was put together, the intention was to say that we want the state data to be as close as possible to the ground truth and we rather do not want systems to report fake leafs. /js On Wed, Apr 21, 2021 at 08:45:02AM +0000, Balázs Lengyel wrote: > Hello Andy, > > While NMDA states “it is possible that constraints MAY be violated under some circumstances” > > * this was never declared for non-NMDA systems, so IMHO a client can reasonably assume that if mandatory=true for a config=false node was declared the reason is that it will always be present; otherwise it should simply be mandatory=false. > * IMHO this allowance for the operational datastore is for extra-ordinary situations. In the normal case as defined in the NMDA-RFC“ SHOULD conform to any constraints specified”. > > > > Regards Balazs > > > > From: Andy Bierman > Sent: 2021. április 20., kedd 20:21 > To: Juergen Schoenwaelder ; Balázs Lengyel ; Sterne, Jason (Nokia - CA/Ottawa) ; Andy Bierman ; netmod@ietf.org > Subject: Re: Compatibility of config=false data > > > > > > > > On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder > wrote: > > My understanding is that a returns the leafs that exist and that > are not filtered. > > > > Yes -- this is what clients expect. > > It is not clear that real client apps rely too much on YANG validation of > > the config=false nodes in . > > > > The validation of server provided monitoring data was not a focus of YANG. > > It may not be valid to assume every sentence that applies to config=true > > also applies to config=false. > > > > Even the NMDA RFC ignores YANG validation of config=false nodes. > > There is a paragraph that says it SHOULD be done, but it really refers > > to how operational values of config=true MAY not pass validation. > > > > > > /js > > > > Andy > > > > > On Tue, Apr 20, 2021 at 03:35:28PM +0000, Balázs Lengyel wrote: > > Hello Juergen, > > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: > > > > If "mandatory" is "true", the behavior of the constraint depends on > > the type of the leaf's closest ancestor node in the schema tree that > > is not a non-presence container (see Section 7.5.1): > > o If no such ancestor exists in the schema tree, the leaf MUST > > exist. > > o Otherwise, if this ancestor is a case node, the leaf MUST exist if > > any node from the case exists in the data tree. > > o Otherwise, the leaf MUST exist if the ancestor node exists in the > > data tree. > > > > Let's take the simplest example a top level leaf. If it is mandatory=true -> > > the leaf MUST exist. The above statements do not differentiate between > > config=true or config=false leaves. > > > > If the leaf exists, for me, it is trivial that the reply to a get/get-data > > operation MUST return it. (assuming it is not filtered out) > > Anything else would be counter-intuitive and IMHO contradict RFC 7950. > > > > Do you agree? > > If not, could you please describe what does a mandatory=true statement mean > > for a config=false leaf in your interpretation? > > > > ------------------------------------------------------------------- > > IMHO we never stated that > > > > > > Regards Balazs > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > > Sent: 2021. április 14., szerda 17:08 > > To: Balázs Lengyel > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) >; Andy Bierman > > >; netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Balázs Lengyel wrote: > > > > > * On the other hand, changing a state leaf from mandatory false to > > true means always including the leaf in a response. > > > > Where do you get this from? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > 28-0d304a28a3dae2f9&q=1&e=81180de4-8958-40ba-aeb8-c689e3da33e8&u=https%3A%2F > > %2Fwww.jacobs-university.de %2F> > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 21 06:31:55 2021 Return-Path: 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 6A2FA3A27FD; Wed, 21 Apr 2021 06:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UYbrXzx2dTIm; Wed, 21 Apr 2021 06:31:44 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9271D3A27FC; Wed, 21 Apr 2021 06:31:44 -0700 (PDT) Received: from ja.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id D8D688269A; Wed, 21 Apr 2021 13:31:43 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A2EE0651-74F2-4673-B49A-477000C8827E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 09:31:42 -0400 In-Reply-To: Cc: last-call@ietf.org, draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org To: Erik Kline References: <161884114915.5121.5751188439778970063@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [netmod] Last Call: (A YANG Grouping for Geographic Locations) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 13:31:50 -0000 --Apple-Mail=_A2EE0651-74F2-4673-B49A-477000C8827E Content-Type: multipart/alternative; boundary="Apple-Mail=_05B5BCAA-DFA1-45F2-9970-7D876AFC653D" --Apple-Mail=_05B5BCAA-DFA1-45F2-9970-7D876AFC653D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 19, 2021, at 4:14 PM, Erik Kline wrote: >=20 > >=20 > Are the vector components expected to be accessed by name in = applications, or is it possible some applications might have to handle a = 3-tuple of doubles? By name only. Thanks, Chris. >=20 > I only ask this super-nitty question because in my (admittedly = limited) experience, ENU order (or NED for that matter) was more = familiar since it forms a coordinate system that aligns with the right = hand rule. >=20 > NEU->ENU conversion is obviously trivial. I was just thinking of = possible errors where the members of the vector aren't accessed by name = but by position. >=20 > -ek >=20 > On Mon, Apr 19, 2021 at 7:07 AM The IESG > wrote: >=20 > The IESG has received a request from the Network Modeling WG (netmod) = to > consider the following document: - 'A YANG Grouping for Geographic = Locations' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits = final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by = 2021-05-03. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either = case, please retain the beginning > of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document defines a generic geographical location object YANG > grouping. The geographical location grouping is intended to be = used > in YANG models for specifying a location on or in reference to = Earth > or any other astronomical object. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ = >=20 >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_05B5BCAA-DFA1-45F2-9970-7D876AFC653D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 19, 2021, at 4:14 PM, Erik Kline <ek.ietf@gmail.com> = wrote:

<no hats>

Are = the vector components expected to be accessed by name in applications, = or is it possible some applications might have to handle a 3-tuple of = doubles?

By name only.

Thanks,
Chris.


I only ask this super-nitty question because in my = (admittedly limited) experience, ENU order (or NED for that matter) was = more familiar since it forms a coordinate system that aligns with the = right hand rule.

NEU->ENU conversion is obviously trivial.  I was just = thinking of possible errors where the members of the vector aren't = accessed by name but by position.

-ek

On Mon, Apr = 19, 2021 at 7:07 AM The IESG <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the Network Modeling WG (netmod) = to
consider the following document: - 'A YANG Grouping for Geographic = Locations'
  <draft-ietf-netmod-geo-location-08.txt> as Proposed = Standard

The IESG plans to make a decision in the next few weeks, and solicits = final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-05-03. = Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the = beginning
of the Subject line to allow automated sorting.

Abstract


   This document defines a generic geographical location = object YANG
   grouping.  The geographical location grouping is = intended to be used
   in YANG models for specifying a location on or in reference = to Earth
   or any other astronomical object.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location= /



No IPR declarations have been submitted directly on this I-D.





_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_05B5BCAA-DFA1-45F2-9970-7D876AFC653D-- --Apple-Mail=_A2EE0651-74F2-4673-B49A-477000C8827E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmCAKT4ACgkQLh2DDte4 MCUq5w/9Hc7g0lSzqXiGbFCJHemEU05iMNFAb7Gx+v/m9yXjfVaCUov1qt/JE9Fx 6h7acfHsJ9hnX/XQPFbGXlXWzkbbET8aNL+Qgs1DAd2VVkhSCdVT0RG+2dxDR9p7 dA0TXDqdXbBV/FkIUeJ2QANO8fCi7e5jJX1k0eZLltvG2VrboCCm0JtJi8UW9r5+ YSoDvgMHRxE0ejAA9mtNEW3Zpwx4slmtZG6K72gDEcwWAKEJjY7IEwvNlOjKwece BA08lzq23qEqteVz6CDP7KPO9zdDPPVdtkga4O42uvukl93PUwBPLWo2rzpfLaWe amAwopJal5lNlfFcwiBu9ofOgyPsgV4cmoPdYhi/M/nUjPdz0hGwBFr20jcrFs0v 98H90zVoqLzKcYN1vDQ0lMrin7iQ0jWEjUn66lflxRirpI3YX/OIQ5IolNfD/zll 7d0xid0b70B5rE8LNZU+UmYwSHg8szDELnp0EKJZfUWE4GurXfvP+DrogBu5HuUW GrgCg+PfI++KMBY8HJ2zfYzzTszbBS3bfe/mUfAgyGr8wqGnupIjwYWD9naH+bjy mtvp/byT+GLsUi0FPnDtM8JU4yxrqWp1B9EKiGFO8cVugEZlNKW93ulBCTrb5tMh 9oyiIzURJC5GKzLBo+xSgH7jiXTTbYTYFmBF8A4/1boOvkUMN2Y= =4aAw -----END PGP SIGNATURE----- --Apple-Mail=_A2EE0651-74F2-4673-B49A-477000C8827E-- From nobody Wed Apr 21 07:48:19 2021 Return-Path: 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 D017D3A255F for ; Wed, 21 Apr 2021 07:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=ericsson.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 8AgXCyfPbY6d for ; Wed, 21 Apr 2021 07:48:11 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCD83A2AC0 for ; Wed, 21 Apr 2021 07:48:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fd9HCzyxMjGyPKNZ5xvDOv7ocBVmh4zBp4tVpLkTI/QhCTIXiCT9F/1dlsZLHYbd+VkbvRYMUMA+zSOAiyl2VqUEe4Ufe0dRP/91BqIKpWDdvFDNC91MpfUeCbDBH1UX/U+ZdP0bnseDsl/Nl0755u1b7VdSrMr+d4xoAxilbbsl0qDQuE7j/kyM+Zg5Ixvn+Ee6cYur4OQtlvNWutZJSy6k4UvFHBXv5ljUvOX5BdlMo1o7toPdWDyWLcvLNJQwN1lgan5bwJVDY/Y3Wx2uyrk2PQcR+bV54jQf1Hpk0eteb2erzMEIK55AIehVDDCJpSismtiUvTzl8qGt0GCZ2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0UsAnMhWC5ftJKtCyucQHN+iwC6jArXxOvbE4kUJs1c=; b=ffcHvEyeFZ1VHCk+fowK8tyDTSvPaj0hYHoyd466n8YxzWPRnHacBjLyC3QBejvtf7kHNvoYdxtnBI81Yy7Sg3JGEX54WKZqFWtfjfME6m0dprAJzo6xI6SdmUQqlo6eEQh3/q462NCIJuLQKYsaUIbfgx5/4Uvvkkm7xJeA/zWzEnSUDia7VyoukFGMSUSf8p5mwL+bsi3A5h+PTZcnDPCN6niIpnuIpRcl3UySw3FytZqUl7xcyUYlHDini/nBDLADEZ2WsaVyJh2OOBQw1M84qCdW69umHgAxe4IhaqnqxelWF+8Cv2WhIuwBLZ1TRmdt77QwYWy0yQbnpBcWhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0UsAnMhWC5ftJKtCyucQHN+iwC6jArXxOvbE4kUJs1c=; b=MUGApeB4zAQ6INTrKinJ8uuHAH/16YYmzGXHBcFyhkyMQWWCQWe0QhUsq8JdZiWMJ7Mpr8hleB4C9+DOQPKAK3RzlLQNVUs85yYTapLvfTX0DboyDftRjkdfocWgStadCn0XxT07Ohp/kmwjSjtC7+71MB4DtjToWc6KunX1LMU= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8293.eurprd07.prod.outlook.com (2603:10a6:20b:328::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Wed, 21 Apr 2021 14:48:05 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e%7]) with mapi id 15.20.4042.016; Wed, 21 Apr 2021 14:48:05 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Juergen Schoenwaelder CC: Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Thread-Topic: Compatibility of config=false data Thread-Index: Adc1+nRtif5YsBpWTgmEUWyshSkyCwAB3dmAAAP97IAAHfRO0AAD+uwAAAi1McA= Date: Wed, 21 Apr 2021 14:48:05 +0000 Message-ID: References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> In-Reply-To: <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.248.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a68c7968-cf4e-482c-28f5-08d904d478e4 x-ms-traffictypediagnostic: AM8PR07MB8293: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4S6xe8Z2Moc1T6ozp+owPbYkzxFDy789BT9Hemrn1VmA8JVSSZywra95JezngsoCE8JojUCnCkOi66FpHIoErXJPYJB03hksKo3usy0dy/jFrlvWqgCTsTkKbg9+2UJ+dCyq9D+RiAv0dgs5qats4o4I94vUQgjXwNBK1n2/OxVX4+4l0Z6BPjrfOipty7okL3ChrDDtSkADTcdBP1Mk/cs3lLO4pnsApa5/tXgakEtLd8aV0+B2pFDip2+cs8j7eSrh/6mJX4i2OeiQpj0OkMHLLsX+nJgrRx6upd1m6R8Cm8KaUjLHv+TowStS07vwg0kmrFQ9jH3ZXlIUq0YirxSAwFzJa27nBn6nJOJCTvDXp5jor6LwVfpR6yScqsoP+uHX4ANi9pEkE5qCdh4/ReLd57+CaFPYRYzfBl2/kxdg6pxwbt247N8okG+Qqo9lWnb/SkxjVVtqKI1GIoQ8uW0t6AQVqmw1kvyFqkFBUDo2Hp5k1w5IWosD2J2/dJsSdG58V5yZkLghU4eeKt0J6zthK4/KAgHA4gDepFZnvw2JvuShS/ApN1jCHvMJnaLAzTuj4Cfyh8OBdfYv6WWM51enSVRRSr6dzt9TgtDnQdRzYPBWchHRtjjMn/EIvbqKxKKKZ9ZanAdCRK/80krlyzED3swdkSqfw5tuS95/D3W9BSahmR8b01sJy92+3L5+ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(54906003)(316002)(86362001)(85182001)(66556008)(3480700007)(83380400001)(66574015)(186003)(9686003)(55016002)(99936003)(2906002)(26005)(8936002)(71200400001)(38100700002)(76116006)(4326008)(6916009)(966005)(66446008)(52536014)(64756008)(478600001)(33656002)(66946007)(85202003)(6506007)(122000001)(5660300002)(53546011)(66616009)(8676002)(66476007)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NlJ5V0VWWC9nZ2RBSE5JVTVsVFhSbkRZR2haWEJJakpTWWxSRXo0WEUzZ1Rq?= =?utf-8?B?UmMxbWdMS1AyeGNCNTZ4M211STBNTEZnRnNsdkpnekx5cGgwdHB3bXYvYXVZ?= =?utf-8?B?NFdha3Q2bWVBOGx1SDJ5Z2F5cXVnQlUxcmROcEl1Ymh2UWpZK2dzSE9IMUFs?= =?utf-8?B?RDZRM3NjNnVMenp3WW1zTmU2Q2NSWjQ0MGVZUXUzemx4NmdTWHNyS29OVGUw?= =?utf-8?B?SzB3KzFaaDMzdGltb2VwRmJPNzExdUdxZlg1bFFuai96YnlWMnhVbjBzcjNO?= =?utf-8?B?dW84MmZNR2luZDdVQkIzY3M0b05KbHZqaXBadEVPVEV1N2FDNEtKY2RMQlRq?= =?utf-8?B?YTB1aXhlUEVGWGY4djJqV1hxZWJOcitvTFErcWlhamM1Q2w0QzVJUXVMeHVL?= =?utf-8?B?c2E5TTRZZEhsZjFWb0RvaU1SbzQyWVNGSzlHazNxL253ajJGQnMrSFNYQncx?= =?utf-8?B?R3BxLzlPcys1TzdKQUltREpJRGd6VllIcG5XbVZlZzlKVnEwYi9FVTg3T2tP?= =?utf-8?B?ZVBIUVFpNC9maWpKTStKOUI2d0ZyeGgzN0FYM3ZNYTVuaXdteldYd3dPdWM0?= =?utf-8?B?aWRDaVlhY1RzNk0xL081bUZCaWZGdGFhOEticmd4YXBtSFNpN2VPRzlvdkpM?= =?utf-8?B?eWhjWDY0ckdWcndQTmlPOGh6UGZCS3dGaWYva3U4R3IxMmw0dzRSdko0Tjh5?= =?utf-8?B?N3pYUGZTOTV4UldLUkxsMWI4UDlKR1BUQU1FZkhudGRzRm95Z1JMYm80bzFR?= =?utf-8?B?NU51WDNiVUdEQTNGZEdwMkU0WUtrNHV6WGtjUDVzYkVZSk1qZEQxb2M0UGhP?= =?utf-8?B?R3NXb3BzYkFVUWpBcHpjWUhjZWpSb3M3Wm5QRHY2UG5IaktYOVBSMGY4R3ZF?= =?utf-8?B?SXd6RXFjMjVsYSt5Nytoc3RxbzhuZUt2ZnhSMWFsV2hqSWhpRGwxcVk1emJv?= =?utf-8?B?ckhaczVickNSendqK09RdHp4RnE0NW1PeXIrQ0U2OHdhelBpeU9lTWdVMFpU?= =?utf-8?B?MnYvK0dRNzJUcElubnptKzQxMG5XVGVsaGZLdG5PTzV1K3A4SFVneTY3Nnhz?= =?utf-8?B?WGEweDBicmU2K1Z6cVBJeEZHY204Umk1MXU5NXNUNkc0elprL2JNMGE5NFdC?= =?utf-8?B?cUdlbnM5eldMLzNrZE9EZ1NoblpSWlJnRnNPSHZuL2lBTEk4MDN1RDh2VDM0?= =?utf-8?B?OGxkcWFlVFhLam00UWMyb2VKYTNPSzBVUTFaNXRrSFpzZ0EzWkN0NDZOYVJB?= =?utf-8?B?V2xVYUlkRkxtK1NoTUd5SzA4bEg3MlMwMXREMWJKWlNwU3EvNW5wdUVKRjFi?= =?utf-8?B?SGhyY0FKQTFGUTRReDdMOTBGVVZzaVBmRURGRU1VL0tWTnp2N0JPdVZzTTlm?= =?utf-8?B?OFNMWnN0V3dJOFMrcmt2bTlvcURjdGNrNXZIQ0QyOWF0RE9KZGVFM2UyWjQ1?= =?utf-8?B?ZjRTTUJjZDFYSXprbjA0cmw3Q1ArWEwyT1BiOUhBZEVmdWpKTTk3VDJsUXlB?= =?utf-8?B?bjFDYVpYMEFkV3kyS0l3bDFaMlcrRUZtWU8zcXZnaXdSWE4rSnRicXhxVnpX?= =?utf-8?B?UWtXNGxHbGJhSFN6MWhnL3JmNk1LbGVpUnpVZjlIYzQ1MWZBWCtKRGJuT2d6?= =?utf-8?B?ZTA4WnJ0bk9PZVZXZjJpOFc0WnZSdlJibVNJY09ZeXlja2VXMDBOaGRTRzJV?= =?utf-8?B?bHErd3VMMnIvbnczSU5aeXVGbWVkMkZBcWIxVGtURjkrWHJ5TFNjL1BpS2xa?= =?utf-8?Q?vX/Rc/wxe8UEuXdAAnC1Cw0nzwtJErahtht54Yu?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0693_01D736CE.190C2C30" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a68c7968-cf4e-482c-28f5-08d904d478e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 14:48:05.6287 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QXJjAEUvtJYyX5sP7s0GMHlQsv9SWqcDucp/9ZEaAyeAP5haSu2MTkWUiPYcG6gcb72fzfCIcPZisZ/qtbJ5WJd8Z766Mt7bXTk+wu5kUZ8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8293 Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 14:48:18 -0000 ------=_NextPart_000_0693_01D736CE.190C2C30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Juergen, IMHO the server should in the order of preference: 1) ALWAYS report mandatory state data - this is the correct thing; it = should happen most of the times 2) Report real data in some of the cases and deviate the = mandatory=3Dtrue statement to mandatory=3Dfalse. - This means I deviate = from the real module, but at least I publish a contract I adhere to 3) Never report the data and deviate the schema node to not-supported . = - This means I strongly deviate from the real module, but at least I = publish a contract I adhere to 4) Not deviate the module as described above, but do not report data=20 5) Report fake data - I agree that this is the worst I consider 4) and 5) to violate the YANG standard. Regards Balazs -----Original Message----- From: Juergen Schoenwaelder =20 Sent: 2021. =C3=A1prilis 21., szerda 12:32 To: Bal=C3=A1zs Lengyel Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa) = ; netmod@ietf.org Subject: Re: Compatibility of config=3Dfalse data RFC 7950 section 8: Several YANG statements define constraints on valid data. These constraints are enforced in different ways, depending on what type of data the statement defines. o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. o If the constraint is defined on state data, it MUST be true in a valid state data tree. The main difference between configuration data and state data is that a = server can keep the configuration data in a valid state by rejecting any = changes that make the configuration data invalid. If, however, a server = reports an invalid state data tree, then obviously the server did choose = to do so and the clients may have to deal with it (which includes the = option of the client to reject all state data since it is invalid, but = that might not always be the best or most desirable option). If there is a mandatory state leaf that the server can't implement, what = should the server do? The worst of all possible solutions is to report a = fake leaf. This has happened quite a bit in the history of SNMP and this = is really really bad. Instead of reporting fake values, it is far better = to not report the leaf so that the deviation is clear. Ideally, the = server formally declare the deviation and all is good. When the NMDA document was put together, the intention was to say that = we want the state data to be as close as possible to the ground truth = and we rather do not want systems to report fake leafs. /js On Wed, Apr 21, 2021 at 08:45:02AM +0000, Bal=C3=A1zs Lengyel wrote: > Hello Andy, >=20 > While NMDA states =E2=80=9Cit is possible that constraints MAY be = violated under some circumstances=E2=80=9D=20 >=20 > * this was never declared for non-NMDA systems, so IMHO a client can = reasonably assume that if mandatory=3Dtrue for a config=3Dfalse node was = declared the reason is that it will always be present; otherwise it = should simply be mandatory=3Dfalse. > * IMHO this allowance for the operational datastore is for = extra-ordinary situations. In the normal case as defined in the = NMDA-RFC=E2=80=9C SHOULD conform to any constraints = specified=E2=80=9D. >=20 > =20 >=20 > Regards Balazs >=20 > =20 >=20 > From: Andy Bierman > Sent: 2021. =C3=A1prilis 20., kedd 20:21 > To: Juergen Schoenwaelder ;=20 > Bal=C3=A1zs Lengyel ; Sterne, Jason = (Nokia -=20 > CA/Ottawa) ; Andy Bierman=20 > ; netmod@ietf.org > Subject: Re: Compatibility of config=3Dfalse data >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder = > wrote: >=20 > My understanding is that a returns the leafs that exist and that = > are not filtered. >=20 > =20 >=20 > Yes -- this is what clients expect. >=20 > It is not clear that real client apps rely too much on YANG validation = > of >=20 > the config=3Dfalse nodes in . >=20 > =20 >=20 > The validation of server provided monitoring data was not a focus of = YANG. >=20 > It may not be valid to assume every sentence that applies to=20 > config=3Dtrue >=20 > also applies to config=3Dfalse. >=20 > =20 >=20 > Even the NMDA RFC ignores YANG validation of config=3Dfalse nodes. >=20 > There is a paragraph that says it SHOULD be done, but it really refers >=20 > to how operational values of config=3Dtrue MAY not pass validation. >=20 > =20 >=20 > =20 >=20 > /js >=20 > =20 >=20 > Andy >=20 > =20 >=20 >=20 > On Tue, Apr 20, 2021 at 03:35:28PM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Juergen, > > https://tools.ietf.org/html/rfc7950#section-7.6.5 states:=20 > >=20 > > If "mandatory" is "true", the behavior of the constraint depends on > > the type of the leaf's closest ancestor node in the schema tree = that > > is not a non-presence container (see Section 7.5.1): > > o If no such ancestor exists in the schema tree, the leaf MUST > > exist. > > o Otherwise, if this ancestor is a case node, the leaf MUST = exist if > > any node from the case exists in the data tree. > > o Otherwise, the leaf MUST exist if the ancestor node exists in = the > > data tree. > >=20 > > Let's take the simplest example a top level leaf. If it is=20 > > mandatory=3Dtrue -> the leaf MUST exist. The above statements do not = > > differentiate between config=3Dtrue or config=3Dfalse leaves. > >=20 > > If the leaf exists, for me, it is trivial that the reply to a=20 > > get/get-data operation MUST return it. (assuming it is not filtered = > > out) Anything else would be counter-intuitive and IMHO contradict = RFC 7950. > >=20 > > Do you agree?=20 > > If not, could you please describe what does a mandatory=3Dtrue=20 > > statement mean for a config=3Dfalse leaf in your interpretation? > >=20 > > ------------------------------------------------------------------- > > IMHO we never stated that > >=20 > >=20 > > Regards Balazs > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > > > Sent: 2021. =C3=A1prilis 14., szerda 17:08 > > To: Bal=C3=A1zs Lengyel > > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) > >; Andy Bierman > >; netmod@ietf.org=20 > > > > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes -=20 > > 2021-04-13 > >=20 > > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Bal=C3=A1zs Lengyel wrote: > >=20 > > > * On the other hand, changing a state leaf from mandatory false = to > > true means always including the leaf in a response. > >=20 > > Where do you get this from? > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > = > 073b36ea=20 > > = 28-0d304a28a3dae2f9&q=3D1&e=3D81180de4-8958-40ba-aeb8-c689e3da33e8&u=3Dht= t > > ps%3A%2F %2Fwww.jacobs-university.de=20 > > = > = d8a30ca42b-c249ef726e615faa&q=3D1&e=3Dbc74e019-40cf-4237-b824-ce71a0cdcb > > 90&u=3Dhttp%3A%2F%2F2fwww.jacobs-university.de%2F> %2F> >=20 >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 = > >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 = ------=_NextPart_000_0693_01D736CE.190C2C30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQyMTE0NDgwNFowIwYJKoZIhvcNAQkEMRYEFA32PeDTYIVg vLAxha3NCGAMIPKvMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAFje 03w9QsP/K65lflCit0Wx5MCfV3LeXsCS2Urq1ZUmHqPj1+9m8cZ1+LRLhByi24ekkFNDu7RPSkNR 3HMwX5qWRygdsCeh6/RHVBC45aSs6H4ZE05UOxlHXWNZt9IcF7gB8XhkWfcr9xvy0Mw0p9/OlNdK gEyk8hMqvhhHmbZduqYx4+7BChAmjLhO+ABmKH7kzz/VT+Otz1Kp6Hka16p8uvNaRMT/hBIyZdCr 4H7rt0SOaOWOPx49bftI3ffTb2mVD+4T0AhbVM+UyLGnwl8PZ4+wrp07xyKtyFdUyNSIDDoiQdik jQUs6jVGXzEAxyKNebhJuHg0ju+4IgpovRsAAAAAAAA= ------=_NextPart_000_0693_01D736CE.190C2C30-- From nobody Wed Apr 21 08:11:05 2021 Return-Path: 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 2D3CE3A2B83 for ; Wed, 21 Apr 2021 08:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 e7VhcMHGw1NB for ; Wed, 21 Apr 2021 08:10:58 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 85ACC3A2B82 for ; Wed, 21 Apr 2021 08:10:57 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id u25so9803682ljg.7 for ; Wed, 21 Apr 2021 08:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZdtDr+cRJ/m1YnTUv6ZAXC6F5LRHyj1FC+6laWeXClA=; b=c1puXwAGAHgjTSn3o0VxaJlLSVGt+qVGuWohJ8Ui0suiWEoMJGsHpTBXkddz0+B7Wa E/i184ltyN8fBzA0W9bUgM9nK8LVee8rDScN3WuokxwuA8JFotctbuz6HblZcHE68xtc l0oy4nf9fWivb4cliXg7alb4UyrsZkVKYkdJrmgix+75Z5NHRcsL6/F18YqV+xPKGgsI v87mlbz8qnUDlWUPxTBzNc/sHm9o1OCEhO60cc7ncMnFRjsj6KYqppGs0Rs7xizTAsNS P25yyDTr5FeNuwRxFuXUb4yh4GFsW2+kObiuUF1uXUvgKos1CrGLIbZCFMHpoEy134T8 Z2eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZdtDr+cRJ/m1YnTUv6ZAXC6F5LRHyj1FC+6laWeXClA=; b=MxmiMj+QKB4dYpjPpEq3IyycogmOjgRQgvLuUFCyu5zWHB0biipQrK2HQs3ni5A3LL jZSk8leB761WnQs/3CxKEDX4fcHZiN2ysjyKPf3lt1dFIc5lxd+9KoDGcBLq+hbYRv25 Cgtgw4s/sVYN5HnvYlEfNbXrO+zF5yynL9e5nBV7J3J7awMZj4OEBm/nwNC0cCDOLi2l xwioh0ufTsFx6J5O99P4tnCblxElI/mUBYcSGshJzZD6jH913ZPwu+xsyDGTzYmuqImm bRxZmSL4pkohxZTA3IvOTi4UWR1klmGEAIat0S19v7RJ2+sh3nbBD2k6YRZ11FTyDue4 Qg4Q== X-Gm-Message-State: AOAM531jNthxWopsgESSzUA4XGQyIfu0JK+OVSpSfGI9GV+tfZMcBsDg eHNBcaBRpEbZyEv/zU/R/U+zSpDsK003DAYXYanIXg== X-Google-Smtp-Source: ABdhPJzgXAARVpAyusZ4sJ/D2B74J4JALIGTj9WqC+LQMpogmtfHWbUURKSpyTc+IFf3OLzqnJOnzxUN0eWTh5Fox6k= X-Received: by 2002:a05:651c:2047:: with SMTP id t7mr19977481ljo.325.1619017850226; Wed, 21 Apr 2021 08:10:50 -0700 (PDT) MIME-Version: 1.0 References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Wed, 21 Apr 2021 08:10:39 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: Juergen Schoenwaelder , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d91b5905c07cf787" Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 15:11:03 -0000 --000000000000d91b5905c07cf787 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 21, 2021 at 7:48 AM Bal=C3=A1zs Lengyel wrote: > Hello Juergen, > IMHO the server should in the order of preference: > 1) ALWAYS report mandatory state data - this is the correct thing; it > should happen most of the times > 2) Report real data in some of the cases and deviate the mandatory=3Dtrue > statement to mandatory=3Dfalse. - This means I deviate from the real modu= le, > but at least I publish a contract I adhere to > 3) Never report the data and deviate the schema node to not-supported . - > This means I strongly deviate from the real module, but at least I publis= h > a contract I adhere to > 4) Not deviate the module as described above, but do not report data > 5) Report fake data - I agree that this is the worst > > IMO mandatory-stmt has no meaning for config=3Dfalse. In fact, validation for config=3Dfalse was never properly considered and it has 2 major flaws: 1) mandatory means nothing for config=3Dfalse data nodes The server doesn't get to decide "maybe I will return /foo counter values today" because mandatory=3Dfalse. I brought this issue up years ago and Martin clarified the issue (can't find it now). Mandatory-stmt does not alter module conformance. Only if-feature=3Dfalse can do that (and deviations of course). Unless a filter or NACM removes the data node, then a on is supposed to return the requested data if it exists. Period. Constraints on Data Several YANG statements define constraints on valid data. These constraints are enforced in different ways, depending on what type of data the statement defines. o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. o If the constraint is defined on state data, it MUST be true in a valid state data tree. o If the constraint is defined on notification content, it MUST be true in any notification data tree. o If the constraint is defined on RPC or action input parameters, it MUST be true in an invocation of the RPC or action operation. o If the constraint is defined on RPC or action output parameters, it MUST be true in the RPC or action reply. It is not clear that bullet 5 really applies to content within the parameter. It clearly applies to the nodes specified in the rpc or action "output" statement. It seems that bullet 2 does not apply because the client does not have the state data tree, it has an element. 2) must-stmt constraints are purely theoretical in the rpc-reply XPath context Again, it is not clear at all that constraints defined in YANG models are part of the validation within an . Clearly the output parameters are validated but not at all clear whether a state data tree can exist in an or only in a server. Since the XPath context allows config and state data from OUTSIDE the , it is clearly impossible for a client to have BOTH the server state data tree and the from the same moment in time. This conceptual evaluation is never actually done on the server, but that is how the constraint is defined. Since these constraints are rare it is not an urgent issue, but it should be addressed if yang-next is ever chartered. > I consider 4) and 5) to violate the YANG standard. > Regards Balazs > Andy > > -----Original Message----- > From: Juergen Schoenwaelder > Sent: 2021. =C3=A1prilis 21., szerda 12:32 > To: Bal=C3=A1zs Lengyel > Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa) = < > jason.sterne@nokia.com>; netmod@ietf.org > Subject: Re: Compatibility of config=3Dfalse data > > RFC 7950 section 8: > > Several YANG statements define constraints on valid data. These > constraints are enforced in different ways, depending on what type of > data the statement defines. > > o If the constraint is defined on configuration data, it MUST be > true in a valid configuration data tree. > > o If the constraint is defined on state data, it MUST be true in a > valid state data tree. > > The main difference between configuration data and state data is that a > server can keep the configuration data in a valid state by rejecting any > changes that make the configuration data invalid. If, however, a server > reports an invalid state data tree, then obviously the server did choose = to > do so and the clients may have to deal with it (which includes the option > of the client to reject all state data since it is invalid, but that migh= t > not always be the best or most desirable option). > > If there is a mandatory state leaf that the server can't implement, what > should the server do? The worst of all possible solutions is to report a > fake leaf. This has happened quite a bit in the history of SNMP and this = is > really really bad. Instead of reporting fake values, it is far better to > not report the leaf so that the deviation is clear. Ideally, the server > formally declare the deviation and all is good. > > When the NMDA document was put together, the intention was to say that we > want the state data to be as close as possible to the ground truth and we > rather do not want systems to report fake leafs. > > /js > > On Wed, Apr 21, 2021 at 08:45:02AM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Andy, > > > > While NMDA states =E2=80=9Cit is possible that constraints MAY be viola= ted under > some circumstances=E2=80=9D > > > > * this was never declared for non-NMDA systems, so IMHO a client ca= n > reasonably assume that if mandatory=3Dtrue for a config=3Dfalse node was > declared the reason is that it will always be present; otherwise it shoul= d > simply be mandatory=3Dfalse. > > * IMHO this allowance for the operational datastore is for > extra-ordinary situations. In the normal case as defined in the > NMDA-RFC=E2=80=9C SHOULD conform to any constraints specifie= d=E2=80=9D. > > > > > > > > Regards Balazs > > > > > > > > From: Andy Bierman > > Sent: 2021. =C3=A1prilis 20., kedd 20:21 > > To: Juergen Schoenwaelder ; > > Bal=C3=A1zs Lengyel ; Sterne, Jason (Nokia= - > > CA/Ottawa) ; Andy Bierman > > ; netmod@ietf.org > > Subject: Re: Compatibility of config=3Dfalse data > > > > > > > > > > > > > > > > On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de j.schoenwaelder@jacobs-university.de> > wrote: > > > > My understanding is that a returns the leafs that exist and that > > are not filtered. > > > > > > > > Yes -- this is what clients expect. > > > > It is not clear that real client apps rely too much on YANG validation > > of > > > > the config=3Dfalse nodes in . > > > > > > > > The validation of server provided monitoring data was not a focus of > YANG. > > > > It may not be valid to assume every sentence that applies to > > config=3Dtrue > > > > also applies to config=3Dfalse. > > > > > > > > Even the NMDA RFC ignores YANG validation of config=3Dfalse nodes. > > > > There is a paragraph that says it SHOULD be done, but it really refers > > > > to how operational values of config=3Dtrue MAY not pass validation. > > > > > > > > > > > > /js > > > > > > > > Andy > > > > > > > > > > On Tue, Apr 20, 2021 at 03:35:28PM +0000, Bal=C3=A1zs Lengyel wrote: > > > Hello Juergen, > > > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: > > > > > > If "mandatory" is "true", the behavior of the constraint depends on > > > the type of the leaf's closest ancestor node in the schema tree th= at > > > is not a non-presence container (see Section 7.5.1): > > > o If no such ancestor exists in the schema tree, the leaf MUST > > > exist. > > > o Otherwise, if this ancestor is a case node, the leaf MUST exist > if > > > any node from the case exists in the data tree. > > > o Otherwise, the leaf MUST exist if the ancestor node exists in t= he > > > data tree. > > > > > > Let's take the simplest example a top level leaf. If it is > > > mandatory=3Dtrue -> the leaf MUST exist. The above statements do not > > > differentiate between config=3Dtrue or config=3Dfalse leaves. > > > > > > If the leaf exists, for me, it is trivial that the reply to a > > > get/get-data operation MUST return it. (assuming it is not filtered > > > out) Anything else would be counter-intuitive and IMHO contradict RFC > 7950. > > > > > > Do you agree? > > > If not, could you please describe what does a mandatory=3Dtrue > > > statement mean for a config=3Dfalse leaf in your interpretation? > > > > > > ------------------------------------------------------------------- > > > IMHO we never stated that > > > > > > > > > Regards Balazs > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > > > > Sent: 2021. =C3=A1prilis 14., szerda 17:08 > > > To: Bal=C3=A1zs Lengyel > > > > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) > > >; Andy Bierman > > >; netmod@ietf.org > > > > > > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - > > > 2021-04-13 > > > > > > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Bal=C3=A1zs Lengyel wrote: > > > > > > > * On the other hand, changing a state leaf from mandatory false t= o > > > true means always including the leaf in a response. > > > > > > Where do you get this from? > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > > 073b36ea > > > 28-0d304a28a3dae2f9&q=3D1&e=3D81180de4-8958-40ba-aeb8-c689e3da33e8&u= =3Dhtt > > > ps%3A%2F %2Fwww.jacobs-university.de > > > > > d8a30ca42b-c249ef726e615faa&q=3D1&e=3Dbc74e019-40cf-4237-b824-ce71a0c= dcb > > > 90&u=3Dhttp%3A%2F%2F2fwww.jacobs-university.de%2F> %2F> > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 < > https://protect2.fireeye.com/v1/url?k=3Dd890b7b7-870b8efa-d890f72c-86b568= 293eb5-194b9ab47bb1629f&q=3D1&e=3Dc0276ac5-8c8a-44d6-a9a9-0c536215db5a&u=3D= https%3A%2F%2Fwww.jacobs-university.de%2F%2520%253Chttps%3A%2F%2Fprotect2.f= ireeye.com%2Fv1%2Furl%3Fk%3D7cfb0d8b-236034ea-7cfb4d10-86d8a30ca42b-e823d1e= ec435af45%26q%3D1%26e%3Dbc74e019-40cf-4237-b824-ce71a0cdcb90%26u%3Dhttps%25= 3A%252F%252Fwww.jacobs-university.de%252F> > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 < > https://protect2.fireeye.com/v1/url?k=3D15fc93b5-4a67aaf8-15fcd32e-86b568= 293eb5-538a1e7d95e0a648&q=3D1&e=3Dc0276ac5-8c8a-44d6-a9a9-0c536215db5a&u=3D= https%3A%2F%2Fwww.jacobs-university.de%2F > > > --000000000000d91b5905c07cf787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 21, 2021 at 7:48 AM Bal= =C3=A1zs Lengyel <balazs.= lengyel@ericsson.com> wrote:
Hello Juergen,
IMHO the server should in the order of preference:
1) ALWAYS report mandatory state data - this is the correct thing; it shoul= d happen most of the times
2) Report real data in some of the cases and deviate the mandatory=3Dtrue s= tatement to mandatory=3Dfalse. - This means I deviate from the real module,= but at least I publish a contract I adhere to
3) Never report the data and deviate the schema node to not-supported . - T= his means I strongly deviate from the real module, but at least I publish a= contract I adhere to
4) Not deviate the module as described above, but do not report data
5) Report fake data - I agree that this is the worst



IMO mandatory-stmt has = no meaning for config=3Dfalse.
In fact, validation for config=3Df= alse was never properly considered and it has 2 major flaws:

=
1) mandatory means nothing for config=3Dfalse data nodes

The server doesn't get to decide "maybe I will r= eturn /foo counter values today"
because mandatory=3Dfalse.= =C2=A0 I brought this issue up years ago and Martin clarified
the= issue (can't find it now).

Mandatory-stmt doe= s not alter module conformance.
Only if-feature=3Dfalse can do th= at (and deviations of course).
Unless a filter or NACM removes th= e data node, then a <get-data> on <operational>
is su= pposed to return the requested data if it exists. Period.

 Constraints on Data


   Several YANG statements define constraints on valid data.  These
   constraints are enforced in different ways, depending on what type of
   data the statement defines.

   o  If the constraint is defined on configuration data, it MUST be
      true in a valid configuration data tree.

   o  If the constraint is defined on state data, it MUST be true in a
      valid state data tree.

   o  If the constraint is defined on notification content, it MUST be
      true in any notification data tree.

   o  If the constraint is defined on RPC or action input parameters, it
      MUST be true in an invocation of the RPC or action operation.

   o  If the constraint is defined on RPC or action output parameters,
      it MUST be true in the RPC or action reply.


It is not clear that bullet 5 really applies to conten= t within the <config> parameter.
It clearly applies to the = nodes specified in the rpc or action "output" statement.
It seems that bullet 2 does not apply because the client does not have th= e
state data tree, it has an <rpc-reply> element.


2) must-stmt constraints are purely theoreti= cal in the rpc-reply XPath context

Again, it is no= t clear at all that constraints defined in YANG models are part of the
validation within an <rpc-reply>.=C2=A0 Clearly the output para= meters are validated but
not at all clear whether a state data tr= ee can exist in an <rpc-reply> or only in a server.

Since the XPath context allows config and state data from OUTSIDE t= he <rpc-reply>,
it is clearly impossible for a client to ha= ve BOTH the server state data tree
and the <rpc-reply> from= the same moment in time.=C2=A0 This conceptual evaluation
is nev= er actually done on the server, but that is how the constraint is defined.<= /div>

Since these constraints are rare it is not an urge= nt issue, but it should be addressed
if yang-next is ever charter= ed.


=C2=A0
I consider 4) and 5) to violate the YANG standard.
Regards Balazs


Andy
=C2=A0

-----Original Message-----
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>=
Sent: 2021. =C3=A1prilis 21., szerda 12:32
To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Cc: Andy Bierman <andy@yumaworks.com>; Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com= >; netmod@ietf.= org
Subject: Re: Compatibility of config=3Dfalse data

RFC 7950 section 8:

=C2=A0 =C2=A0Several YANG statements define constraints on valid data.=C2= =A0 These
=C2=A0 =C2=A0constraints are enforced in different ways, depending on what = type of
=C2=A0 =C2=A0data the statement defines.

=C2=A0 =C2=A0o=C2=A0 If the constraint is defined on configuration data, it= MUST be
=C2=A0 =C2=A0 =C2=A0 true in a valid configuration data tree.

=C2=A0 =C2=A0o=C2=A0 If the constraint is defined on state data, it MUST be= true in a
=C2=A0 =C2=A0 =C2=A0 valid state data tree.

The main difference between configuration data and state data is that a ser= ver can keep the configuration data in a valid state by rejecting any chang= es that make the configuration data invalid. If, however, a server reports = an invalid state data tree, then obviously the server did choose to do so a= nd the clients may have to deal with it (which includes the option of the c= lient to reject all state data since it is invalid, but that might not alwa= ys be the best or most desirable option).

If there is a mandatory state leaf that the server can't implement, wha= t should the server do? The worst of all possible solutions is to report a = fake leaf. This has happened quite a bit in the history of SNMP and this is= really really bad. Instead of reporting fake values, it is far better to n= ot report the leaf so that the deviation is clear. Ideally, the server form= ally declare the deviation and all is good.

When the NMDA document was put together, the intention was to say that we w= ant the state data to be as close as possible to the ground truth and we ra= ther do not want systems to report fake leafs.

/js

On Wed, Apr 21, 2021 at 08:45:02AM +0000, Bal=C3=A1zs Lengyel wrote:
> Hello Andy,
>
> While NMDA states =E2=80=9Cit is possible that constraints MAY be viol= ated under some circumstances=E2=80=9D
>
> *=C2=A0 =C2=A0 =C2=A0this was never declared for non-NMDA systems, so = IMHO a client can reasonably assume that if mandatory=3Dtrue for a config= =3Dfalse node was declared the reason is that it will always be present; ot= herwise it should simply be mandatory=3Dfalse.
> *=C2=A0 =C2=A0 =C2=A0IMHO this allowance for the operational datastore= is for extra-ordinary situations. In the normal case as defined in the NMD= A-RFC=E2=80=9C<operational> SHOULD conform to any constraints specifi= ed=E2=80=9D.
>
>=C2=A0
>
> Regards Balazs
>
>=C2=A0
>
> From: Andy Bierman <andy@yumaworks.com>
> Sent: 2021. =C3=A1prilis 20., kedd 20:21
> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&= gt;;
> Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Sterne, Jason (Noki= a -
> CA/Ottawa) <jason.sterne@nokia.com>; Andy Bierman
> <andy@yumaw= orks.com>; netm= od@ietf.org
> Subject: Re: Compatibility of config=3Dfalse data
>
>=C2=A0
>
>=C2=A0
>
>=C2=A0
>
> On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder <j.schoenwaeld= er@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de<= /a>> > wrote:
>
> My understanding is that a <get> returns the leafs that exist an= d that
> are not filtered.
>
>=C2=A0
>
> Yes -- this is what clients expect.
>
> It is not clear that real client apps rely too much on YANG validation=
> of
>
> the config=3Dfalse nodes in <operational>.
>
>=C2=A0
>
> The validation of server provided monitoring data was not a focus of Y= ANG.
>
> It may not be valid to assume every sentence that applies to
> config=3Dtrue
>
> also applies to config=3Dfalse.
>
>=C2=A0
>
> Even the NMDA RFC ignores YANG validation of config=3Dfalse nodes.
>
> There is a paragraph that says it SHOULD be done, but it really refers=
>
> to how operational values of config=3Dtrue MAY not pass validation. >
>=C2=A0
>
>=C2=A0
>
> /js
>
>=C2=A0
>
> Andy
>
>=C2=A0
>
>
> On Tue, Apr 20, 2021 at 03:35:28PM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Juergen,
> > https://tools.ietf.org/html/rfc7950#secti= on-7.6.5 states:
> >
> > If "mandatory" is "true", the behavior of the= constraint depends on
> >=C2=A0 =C2=A0 the type of the leaf's closest ancestor node in = the schema tree that
> >=C2=A0 =C2=A0 is not a non-presence container (see Section 7.5.1):=
> >=C2=A0 =C2=A0 o=C2=A0 If no such ancestor exists in the schema tre= e, the leaf MUST
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0exist.
> >=C2=A0 =C2=A0 o=C2=A0 Otherwise, if this ancestor is a case node, = the leaf MUST exist if
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0any node from the case exists in the da= ta tree.
> >=C2=A0 =C2=A0 o=C2=A0 Otherwise, the leaf MUST exist if the ancest= or node exists in the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0data tree.
> >
> > Let's take the simplest example a top level leaf. If it is > > mandatory=3Dtrue -> the leaf MUST exist. The above statements = do not
> > differentiate between config=3Dtrue or config=3Dfalse leaves.
> >
> > If the leaf exists, for me, it is trivial that the reply to a > > get/get-data operation MUST return it.=C2=A0 (assuming it is not = filtered
> > out) Anything else would be counter-intuitive and IMHO contradict= RFC 7950.
> >
> > Do you agree?
> > If not, could you please describe what does a mandatory=3Dtrue > > statement mean for a config=3Dfalse leaf in your interpretation?<= br> > >
> > -----------------------------------------------------------------= --
> > IMHO we never stated that
> >
> >
> > Regards Balazs
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.= de
> > <mailto:j.schoenwaelder@jacobs-university.de> >
> > Sent: 2021. =C3=A1prilis 14., szerda 17:08
> > To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com
> > <mailto:balazs.lengyel@ericsson.com> >
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com
> > <mailto:jason.sterne@nokia.com> >; Andy Bierman <andy@yumaworks.com
> > <mailto:andy@yumaworks.com> >; netmod@ietf.org
> > <mailto:n= etmod@ietf.org>
> > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes -
> > 2021-04-13
> >
> > On Wed, Apr 14, 2021 at 01:55:04PM +0000, Bal=C3=A1zs Lengyel wro= te:
> >
> > > *=C2=A0 =C2=A0On the other hand, changing a state leaf from = mandatory false to
> > true means always including the leaf in a <get> response. > >
> > Where do you get this from?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103
> > <https://protect2.= fireeye.com/v1/url?k=3D9e758f86-c1eeb764-9e75cf1d-86
> > 073b36ea
> > 28-0d304a28a3dae2f9&q=3D1&e=3D81180de4-8958-40ba-aeb8-c68= 9e3da33e8&u=3Dhtt
> > ps%3A%2F %2Fwww.jacobs-university.de
> > <https://protect2.= fireeye.com/v1/url?k=3Dbaf9f9a4-e562c0c5-baf9b93f-86
> > d8a30ca42b-c249ef726e615faa&q=3D1&e=3Dbc74e019-40cf-4237-= b824-ce71a0cdcb
> > 90&u=3Dhttp%3A%2F%2F2fwww.jacobs-university.de%= 2F> %2F>
>
>
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://protect2.fireeye.com/v1/url?k=3Dd890b7b7= -870b8efa-d890f72c-86b568293eb5-194b9ab47bb1629f&q=3D1&e=3Dc0276ac5= -8c8a-44d6-a9a9-0c536215db5a&u=3Dhttps%3A%2F%2Fwww.jacobs-university.de= %2F%2520%253Chttps%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D7cfb0d8b-2= 36034ea-7cfb4d10-86d8a30ca42b-e823d1eec435af45%26q%3D1%26e%3Dbc74e019-40cf-= 4237-b824-ce71a0cdcb90%26u%3Dhttps%253A%252F%252Fwww.jacobs-university.de%2= 52F> >
>



--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://protect2.fireeye.com/v1/url?k=3D15fc93b5-4a67= aaf8-15fcd32e-86b568293eb5-538a1e7d95e0a648&q=3D1&e=3Dc0276ac5-8c8a= -44d6-a9a9-0c536215db5a&u=3Dhttps%3A%2F%2Fwww.jacobs-university.de%2F>
--000000000000d91b5905c07cf787-- From nobody Wed Apr 21 10:21:30 2021 Return-Path: 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 2796A3A302A for ; Wed, 21 Apr 2021 10:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ulmDqASZdXH2 for ; Wed, 21 Apr 2021 10:21:24 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD143A3027 for ; Wed, 21 Apr 2021 10:21:23 -0700 (PDT) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FQRyv5mGNz70gKh; Thu, 22 Apr 2021 01:15:51 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 21 Apr 2021 19:21:19 +0200 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2176.012; Wed, 21 Apr 2021 19:21:19 +0200 From: Italo Busi To: =?utf-8?B?J0JhbMOhenMgTGVuZ3llbCc=?= , Juergen Schoenwaelder CC: Andy Bierman , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" Thread-Topic: [netmod] Compatibility of config=false data Thread-Index: AQHXNr1tHGJAN7uACUuqiRSvysq17Kq/NzhA Date: Wed, 21 Apr 2021 17:21:19 +0000 Message-ID: <943b010d310744cebe2f799c1c9000ff@huawei.com> References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.231] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 17:21:29 -0000 QmFsYXpzLA0KDQpGZXcgcXVlc3Rpb25zIGZvciBjbGFyaWZpY2F0aW9uDQoNCkluIGNhc2UgMywg aXMgaXQgcmVxdWlyZWQgdG8gZGV2aWF0ZSB0aGUgc2NoZW1hIG5vZGUgdG8gbm90LXN1cHBvcnRl ZCBvciB3b3VsZCBpdCBiZSBhbHNvIHBvc3NpYmxlIHRvIGRldmlhdGUgaXQgYXMgbWFuZGF0b3J5 PWZhbHNlPw0KDQpIb3cgd291bGQgeW91IGNvbnNpZGVyIHRoZSBkZWZpbml0aW9uIG9mIHNvbWUg InNwZWNpYWwiIHZhbHVlIChlLmcuLCAwIGluIGNhc2Ugb2YgaW50ZWdlciBvciAidW5rbm93biIg aW4gY2FzZSBvZiBlbnVtZXJhdGlvbikgYXMgYSB3YXkgdG8gcmVwb3J0ICJmYWtlIiBkYXRhPw0K DQpBcmUgdGhlc2UgcnVsZXMgd3JpdHRlbiBvciBwbGFubmVkIHRvIGJlIHdyaXR0ZW4gc29tZXdo ZXJlPw0KDQpUaGFua3MsIEl0YWxvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQmFsw6F6cyBMZW5neWVsIFttYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t XQ0KPiBTZW50OiBtZXJjb2xlZMOsIDIxIGFwcmlsZSAyMDIxIDE2OjQ4DQo+IFRvOiBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4g Q2M6IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjsgU3Rlcm5lLCBKYXNvbiAoTm9r aWEgLSBDQS9PdHRhd2EpDQo+IDxqYXNvbi5zdGVybmVAbm9raWEuY29tPjsgbmV0bW9kQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBDb21wYXRpYmlsaXR5IG9mIGNvbmZpZz1mYWxz ZSBkYXRhDQo+IA0KPiBIZWxsbyBKdWVyZ2VuLA0KPiBJTUhPIHRoZSBzZXJ2ZXIgc2hvdWxkIGlu IHRoZSBvcmRlciBvZiBwcmVmZXJlbmNlOg0KPiAxKSBBTFdBWVMgcmVwb3J0IG1hbmRhdG9yeSBz dGF0ZSBkYXRhIC0gdGhpcyBpcyB0aGUgY29ycmVjdCB0aGluZzsgaXQgc2hvdWxkDQo+IGhhcHBl biBtb3N0IG9mIHRoZSB0aW1lcw0KPiAyKSBSZXBvcnQgcmVhbCBkYXRhIGluIHNvbWUgb2YgdGhl IGNhc2VzIGFuZCBkZXZpYXRlIHRoZSBtYW5kYXRvcnk9dHJ1ZQ0KPiBzdGF0ZW1lbnQgdG8gbWFu ZGF0b3J5PWZhbHNlLiAtIFRoaXMgbWVhbnMgSSBkZXZpYXRlIGZyb20gdGhlIHJlYWwgbW9kdWxl LA0KPiBidXQgYXQgbGVhc3QgSSBwdWJsaXNoIGEgY29udHJhY3QgSSBhZGhlcmUgdG8NCj4gMykg TmV2ZXIgcmVwb3J0IHRoZSBkYXRhIGFuZCBkZXZpYXRlIHRoZSBzY2hlbWEgbm9kZSB0byBub3Qt c3VwcG9ydGVkIC4gLQ0KPiBUaGlzIG1lYW5zIEkgc3Ryb25nbHkgZGV2aWF0ZSBmcm9tIHRoZSBy ZWFsIG1vZHVsZSwgYnV0IGF0IGxlYXN0IEkgcHVibGlzaCBhDQo+IGNvbnRyYWN0IEkgYWRoZXJl IHRvDQo+IDQpIE5vdCBkZXZpYXRlIHRoZSBtb2R1bGUgYXMgZGVzY3JpYmVkIGFib3ZlLCBidXQg ZG8gbm90IHJlcG9ydCBkYXRhDQo+IDUpIFJlcG9ydCBmYWtlIGRhdGEgLSBJIGFncmVlIHRoYXQg dGhpcyBpcyB0aGUgd29yc3QNCj4gDQo+IEkgY29uc2lkZXIgNCkgYW5kIDUpIHRvIHZpb2xhdGUg dGhlIFlBTkcgc3RhbmRhcmQuDQo+IFJlZ2FyZHMgQmFsYXpzDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gU2VudDogMjAyMS4gw6FwcmlsaXMgMjEuLCBz emVyZGEgMTI6MzINCj4gVG86IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nz b24uY29tPg0KPiBDYzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+OyBTdGVybmUs IEphc29uIChOb2tpYSAtIENBL090dGF3YSkNCj4gPGphc29uLnN0ZXJuZUBub2tpYS5jb20+OyBu ZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IENvbXBhdGliaWxpdHkgb2YgY29uZmlnPWZh bHNlIGRhdGENCj4gDQo+IFJGQyA3OTUwIHNlY3Rpb24gODoNCj4gDQo+ICAgIFNldmVyYWwgWUFO RyBzdGF0ZW1lbnRzIGRlZmluZSBjb25zdHJhaW50cyBvbiB2YWxpZCBkYXRhLiAgVGhlc2UNCj4g ICAgY29uc3RyYWludHMgYXJlIGVuZm9yY2VkIGluIGRpZmZlcmVudCB3YXlzLCBkZXBlbmRpbmcg b24gd2hhdCB0eXBlIG9mDQo+ICAgIGRhdGEgdGhlIHN0YXRlbWVudCBkZWZpbmVzLg0KPiANCj4g ICAgbyAgSWYgdGhlIGNvbnN0cmFpbnQgaXMgZGVmaW5lZCBvbiBjb25maWd1cmF0aW9uIGRhdGEs IGl0IE1VU1QgYmUNCj4gICAgICAgdHJ1ZSBpbiBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZGF0YSB0 cmVlLg0KPiANCj4gICAgbyAgSWYgdGhlIGNvbnN0cmFpbnQgaXMgZGVmaW5lZCBvbiBzdGF0ZSBk YXRhLCBpdCBNVVNUIGJlIHRydWUgaW4gYQ0KPiAgICAgICB2YWxpZCBzdGF0ZSBkYXRhIHRyZWUu DQo+IA0KPiBUaGUgbWFpbiBkaWZmZXJlbmNlIGJldHdlZW4gY29uZmlndXJhdGlvbiBkYXRhIGFu ZCBzdGF0ZSBkYXRhIGlzIHRoYXQgYSBzZXJ2ZXINCj4gY2FuIGtlZXAgdGhlIGNvbmZpZ3VyYXRp b24gZGF0YSBpbiBhIHZhbGlkIHN0YXRlIGJ5IHJlamVjdGluZyBhbnkgY2hhbmdlcyB0aGF0DQo+ IG1ha2UgdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBpbnZhbGlkLiBJZiwgaG93ZXZlciwgYSBzZXJ2 ZXIgcmVwb3J0cyBhbiBpbnZhbGlkDQo+IHN0YXRlIGRhdGEgdHJlZSwgdGhlbiBvYnZpb3VzbHkg dGhlIHNlcnZlciBkaWQgY2hvb3NlIHRvIGRvIHNvIGFuZCB0aGUgY2xpZW50cw0KPiBtYXkgaGF2 ZSB0byBkZWFsIHdpdGggaXQgKHdoaWNoIGluY2x1ZGVzIHRoZSBvcHRpb24gb2YgdGhlIGNsaWVu dCB0byByZWplY3QgYWxsDQo+IHN0YXRlIGRhdGEgc2luY2UgaXQgaXMgaW52YWxpZCwgYnV0IHRo YXQgbWlnaHQgbm90IGFsd2F5cyBiZSB0aGUgYmVzdCBvciBtb3N0DQo+IGRlc2lyYWJsZSBvcHRp b24pLg0KPiANCj4gSWYgdGhlcmUgaXMgYSBtYW5kYXRvcnkgc3RhdGUgbGVhZiB0aGF0IHRoZSBz ZXJ2ZXIgY2FuJ3QgaW1wbGVtZW50LCB3aGF0IHNob3VsZA0KPiB0aGUgc2VydmVyIGRvPyBUaGUg d29yc3Qgb2YgYWxsIHBvc3NpYmxlIHNvbHV0aW9ucyBpcyB0byByZXBvcnQgYSBmYWtlIGxlYWYu IFRoaXMNCj4gaGFzIGhhcHBlbmVkIHF1aXRlIGEgYml0IGluIHRoZSBoaXN0b3J5IG9mIFNOTVAg YW5kIHRoaXMgaXMgcmVhbGx5IHJlYWxseSBiYWQuDQo+IEluc3RlYWQgb2YgcmVwb3J0aW5nIGZh a2UgdmFsdWVzLCBpdCBpcyBmYXIgYmV0dGVyIHRvIG5vdCByZXBvcnQgdGhlIGxlYWYgc28gdGhh dA0KPiB0aGUgZGV2aWF0aW9uIGlzIGNsZWFyLiBJZGVhbGx5LCB0aGUgc2VydmVyIGZvcm1hbGx5 IGRlY2xhcmUgdGhlIGRldmlhdGlvbiBhbmQgYWxsDQo+IGlzIGdvb2QuDQo+IA0KPiBXaGVuIHRo ZSBOTURBIGRvY3VtZW50IHdhcyBwdXQgdG9nZXRoZXIsIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNh eSB0aGF0DQo+IHdlIHdhbnQgdGhlIHN0YXRlIGRhdGEgdG8gYmUgYXMgY2xvc2UgYXMgcG9zc2li bGUgdG8gdGhlIGdyb3VuZCB0cnV0aCBhbmQgd2UNCj4gcmF0aGVyIGRvIG5vdCB3YW50IHN5c3Rl bXMgdG8gcmVwb3J0IGZha2UgbGVhZnMuDQo+IA0KPiAvanMNCj4gDQo+IE9uIFdlZCwgQXByIDIx LCAyMDIxIGF0IDA4OjQ1OjAyQU0gKzAwMDAsIEJhbMOhenMgTGVuZ3llbCB3cm90ZToNCj4gPiBI ZWxsbyBBbmR5LA0KPiA+DQo+ID4gV2hpbGUgTk1EQSBzdGF0ZXMg4oCcaXQgaXMgcG9zc2libGUg dGhhdCBjb25zdHJhaW50cyBNQVkgYmUgdmlvbGF0ZWQgdW5kZXINCj4gc29tZSBjaXJjdW1zdGFu Y2Vz4oCdDQo+ID4NCj4gPiAqCXRoaXMgd2FzIG5ldmVyIGRlY2xhcmVkIGZvciBub24tTk1EQSBz eXN0ZW1zLCBzbyBJTUhPIGEgY2xpZW50IGNhbg0KPiByZWFzb25hYmx5IGFzc3VtZSB0aGF0IGlm IG1hbmRhdG9yeT10cnVlIGZvciBhIGNvbmZpZz1mYWxzZSBub2RlIHdhcw0KPiBkZWNsYXJlZCB0 aGUgcmVhc29uIGlzIHRoYXQgaXQgd2lsbCBhbHdheXMgYmUgcHJlc2VudDsgb3RoZXJ3aXNlIGl0 IHNob3VsZCBzaW1wbHkNCj4gYmUgbWFuZGF0b3J5PWZhbHNlLg0KPiA+ICoJSU1ITyB0aGlzIGFs bG93YW5jZSBmb3IgdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBpcyBmb3IgZXh0cmEtb3JkaW5h cnkNCj4gc2l0dWF0aW9ucy4gSW4gdGhlIG5vcm1hbCBjYXNlIGFzIGRlZmluZWQgaW4gdGhlIE5N REEtUkZD4oCcPG9wZXJhdGlvbmFsPg0KPiBTSE9VTEQgY29uZm9ybSB0byBhbnkgY29uc3RyYWlu dHMgc3BlY2lmaWVk4oCdLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFJlZ2FyZHMgQmFsYXpzDQo+ID4N Cj4gPg0KPiA+DQo+ID4gRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQo+ ID4gU2VudDogMjAyMS4gw6FwcmlsaXMgMjAuLCBrZWRkIDIwOjIxDQo+ID4gVG86IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsNCj4g PiBCYWzDoXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT47IFN0ZXJuZSwg SmFzb24gKE5va2lhIC0NCj4gPiBDQS9PdHRhd2EpIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPjsg QW5keSBCaWVybWFuDQo+ID4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFJlOiBDb21wYXRpYmlsaXR5IG9mIGNvbmZpZz1mYWxzZSBkYXRhDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBUdWUsIEFwciAyMCwgMjAyMSBh dCA5OjI2IEFNIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiA8ai5zY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlIDxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy0NCj4gdW5pdmVy c2l0eS5kZT4gPiB3cm90ZToNCj4gPg0KPiA+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBhIDxn ZXQ+IHJldHVybnMgdGhlIGxlYWZzIHRoYXQgZXhpc3QgYW5kIHRoYXQNCj4gPiBhcmUgbm90IGZp bHRlcmVkLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFllcyAtLSB0aGlzIGlzIHdoYXQgY2xpZW50cyBl eHBlY3QuDQo+ID4NCj4gPiBJdCBpcyBub3QgY2xlYXIgdGhhdCByZWFsIGNsaWVudCBhcHBzIHJl bHkgdG9vIG11Y2ggb24gWUFORyB2YWxpZGF0aW9uDQo+ID4gb2YNCj4gPg0KPiA+IHRoZSBjb25m aWc9ZmFsc2Ugbm9kZXMgaW4gPG9wZXJhdGlvbmFsPi4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGUg dmFsaWRhdGlvbiBvZiBzZXJ2ZXIgcHJvdmlkZWQgbW9uaXRvcmluZyBkYXRhIHdhcyBub3QgYSBm b2N1cyBvZiBZQU5HLg0KPiA+DQo+ID4gSXQgbWF5IG5vdCBiZSB2YWxpZCB0byBhc3N1bWUgZXZl cnkgc2VudGVuY2UgdGhhdCBhcHBsaWVzIHRvDQo+ID4gY29uZmlnPXRydWUNCj4gPg0KPiA+IGFs c28gYXBwbGllcyB0byBjb25maWc9ZmFsc2UuDQo+ID4NCj4gPg0KPiA+DQo+ID4gRXZlbiB0aGUg Tk1EQSBSRkMgaWdub3JlcyBZQU5HIHZhbGlkYXRpb24gb2YgY29uZmlnPWZhbHNlIG5vZGVzLg0K PiA+DQo+ID4gVGhlcmUgaXMgYSBwYXJhZ3JhcGggdGhhdCBzYXlzIGl0IFNIT1VMRCBiZSBkb25l LCBidXQgaXQgcmVhbGx5IHJlZmVycw0KPiA+DQo+ID4gdG8gaG93IG9wZXJhdGlvbmFsIHZhbHVl cyBvZiBjb25maWc9dHJ1ZSBNQVkgbm90IHBhc3MgdmFsaWRhdGlvbi4NCj4gPg0KPiA+DQo+ID4N Cj4gPg0KPiA+DQo+ID4gL2pzDQo+ID4NCj4gPg0KPiA+DQo+ID4gQW5keQ0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4gT24gVHVlLCBBcHIgMjAsIDIwMjEgYXQgMDM6MzU6MjhQTSArMDAwMCwgQmFs w6F6cyBMZW5neWVsIHdyb3RlOg0KPiA+ID4gSGVsbG8gSnVlcmdlbiwNCj4gPiA+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNy42LjUgc3RhdGVzOg0KPiA+ID4N Cj4gPiA+IElmICJtYW5kYXRvcnkiIGlzICJ0cnVlIiwgdGhlIGJlaGF2aW9yIG9mIHRoZSBjb25z dHJhaW50IGRlcGVuZHMgb24NCj4gPiA+ICAgIHRoZSB0eXBlIG9mIHRoZSBsZWFmJ3MgY2xvc2Vz dCBhbmNlc3RvciBub2RlIGluIHRoZSBzY2hlbWEgdHJlZSB0aGF0DQo+ID4gPiAgICBpcyBub3Qg YSBub24tcHJlc2VuY2UgY29udGFpbmVyIChzZWUgU2VjdGlvbiA3LjUuMSk6DQo+ID4gPiAgICBv ICBJZiBubyBzdWNoIGFuY2VzdG9yIGV4aXN0cyBpbiB0aGUgc2NoZW1hIHRyZWUsIHRoZSBsZWFm IE1VU1QNCj4gPiA+ICAgICAgIGV4aXN0Lg0KPiA+ID4gICAgbyAgT3RoZXJ3aXNlLCBpZiB0aGlz IGFuY2VzdG9yIGlzIGEgY2FzZSBub2RlLCB0aGUgbGVhZiBNVVNUIGV4aXN0IGlmDQo+ID4gPiAg ICAgICBhbnkgbm9kZSBmcm9tIHRoZSBjYXNlIGV4aXN0cyBpbiB0aGUgZGF0YSB0cmVlLg0KPiA+ ID4gICAgbyAgT3RoZXJ3aXNlLCB0aGUgbGVhZiBNVVNUIGV4aXN0IGlmIHRoZSBhbmNlc3RvciBu b2RlIGV4aXN0cyBpbiB0aGUNCj4gPiA+ICAgICAgIGRhdGEgdHJlZS4NCj4gPiA+DQo+ID4gPiBM ZXQncyB0YWtlIHRoZSBzaW1wbGVzdCBleGFtcGxlIGEgdG9wIGxldmVsIGxlYWYuIElmIGl0IGlz DQo+ID4gPiBtYW5kYXRvcnk9dHJ1ZSAtPiB0aGUgbGVhZiBNVVNUIGV4aXN0LiBUaGUgYWJvdmUg c3RhdGVtZW50cyBkbyBub3QNCj4gPiA+IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBjb25maWc9dHJ1 ZSBvciBjb25maWc9ZmFsc2UgbGVhdmVzLg0KPiA+ID4NCj4gPiA+IElmIHRoZSBsZWFmIGV4aXN0 cywgZm9yIG1lLCBpdCBpcyB0cml2aWFsIHRoYXQgdGhlIHJlcGx5IHRvIGENCj4gPiA+IGdldC9n ZXQtZGF0YSBvcGVyYXRpb24gTVVTVCByZXR1cm4gaXQuICAoYXNzdW1pbmcgaXQgaXMgbm90IGZp bHRlcmVkDQo+ID4gPiBvdXQpIEFueXRoaW5nIGVsc2Ugd291bGQgYmUgY291bnRlci1pbnR1aXRp dmUgYW5kIElNSE8gY29udHJhZGljdCBSRkMNCj4gNzk1MC4NCj4gPiA+DQo+ID4gPiBEbyB5b3Ug YWdyZWU/DQo+ID4gPiBJZiBub3QsIGNvdWxkIHlvdSBwbGVhc2UgZGVzY3JpYmUgd2hhdCBkb2Vz IGEgbWFuZGF0b3J5PXRydWUNCj4gPiA+IHN0YXRlbWVudCBtZWFuIGZvciBhIGNvbmZpZz1mYWxz ZSBsZWFmIGluIHlvdXIgaW50ZXJwcmV0YXRpb24/DQo+ID4gPg0KPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+ID4gSU1ITyB3ZSBuZXZlciBzdGF0ZWQgdGhhdA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBSZWdh cmRzIEJhbGF6cw0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZQ0KPiA+ID4gPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGU+ID4NCj4gPiA+IFNlbnQ6IDIwMjEuIMOhcHJpbGlzIDE0Liwgc3plcmRhIDE3OjA4DQo+ ID4gPiBUbzogQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20NCj4g PiA+IDxtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPiA+DQo+ID4gPiBDYzogU3Rl cm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2EpIDxqYXNvbi5zdGVybmVAbm9raWEuY29tDQo+ ID4gPiA8bWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20+ID47IEFuZHkgQmllcm1hbg0KPiA8 YW5keUB5dW1hd29ya3MuY29tDQo+ID4gPiA8bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4gPjsg bmV0bW9kQGlldGYub3JnDQo+ID4gPiA8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiA+IFN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBZQU5HIFZlcnNpb25pbmcgV2Vla2x5IENhbGwgTWludXRlcyAt DQo+ID4gPiAyMDIxLTA0LTEzDQo+ID4gPg0KPiA+ID4gT24gV2VkLCBBcHIgMTQsIDIwMjEgYXQg MDE6NTU6MDRQTSArMDAwMCwgQmFsw6F6cyBMZW5neWVsIHdyb3RlOg0KPiA+ID4NCj4gPiA+ID4g KiAgIE9uIHRoZSBvdGhlciBoYW5kLCBjaGFuZ2luZyBhIHN0YXRlIGxlYWYgZnJvbSBtYW5kYXRv cnkgZmFsc2UgdG8NCj4gPiA+IHRydWUgbWVhbnMgYWx3YXlzIGluY2x1ZGluZyB0aGUgbGVhZiBp biBhIDxnZXQ+IHJlc3BvbnNlLg0KPiA+ID4NCj4gPiA+IFdoZXJlIGRvIHlvdSBnZXQgdGhpcyBm cm9tPw0KPiA+ID4NCj4gPiA+IC9qcw0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBKdWVyZ2VuIFNj aG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+ ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg QnJlbWVuIHwgR2VybWFueQ0KPiA+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMNCj4gPiA+IDxo dHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTllNzU4Zjg2LWMxZWViNzY0LTll NzVjZjFkLTg2DQo+ID4gPiAwNzNiMzZlYQ0KPiA+ID4gMjgtMGQzMDRhMjhhM2RhZTJmOSZxPTEm ZT04MTE4MGRlNC04OTU4LTQwYmEtYWViOC0NCj4gYzY4OWUzZGEzM2U4JnU9aHR0DQo+ID4gPiBw cyUzQSUyRiAlMkZ3d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUNCj4gPiA+IDxodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3YxL3VybD9rPWJhZjlmOWE0LWU1NjJjMGM1LWJhZjliOTNmLTg2DQo+ ID4gPiBkOGEzMGNhNDJiLWMyNDllZjcyNmU2MTVmYWEmcT0xJmU9YmM3NGUwMTktNDBjZi00MjM3 LWI4MjQtDQo+IGNlNzFhMGNkY2INCj4gPiA+IDkwJnU9aHR0cCUzQSUyRiUyRjJmd3d3LmphY29i cy11bml2ZXJzaXR5LmRlJTJGPiAlMkY+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4 NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMw0KPiA8aHR0 cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az1kODkwYjdiNy04NzBiOGVmYS1kODkw ZjcyYy0NCj4gODZiNTY4MjkzZWI1LTE5NGI5YWI0N2JiMTYyOWYmcT0xJmU9YzAyNzZhYzUtOGM4 YS00NGQ2LWE5YTktDQo+IDBjNTM2MjE1ZGI1YSZ1PWh0dHBzJTNBJTJGJTJGd3d3LmphY29icy0N Cj4gdW5pdmVyc2l0eS5kZSUyRiUyNTIwJTI1M0NodHRwcyUzQSUyRiUyRnByb3RlY3QyLmZpcmVl eWUuY29tJTJGdjElMg0KPiBGdXJsJTNGayUzRDdjZmIwZDhiLTIzNjAzNGVhLTdjZmI0ZDEwLTg2 ZDhhMzBjYTQyYi0NCj4gZTgyM2QxZWVjNDM1YWY0NSUyNnElM0QxJTI2ZSUzRGJjNzRlMDE5LTQw Y2YtNDIzNy1iODI0LQ0KPiBjZTcxYTBjZGNiOTAlMjZ1JTNEaHR0cHMlMjUzQSUyNTJGJTI1MkZ3 d3cuamFjb2JzLQ0KPiB1bml2ZXJzaXR5LmRlJTI1MkY+ID4NCj4gPg0KPiANCj4gDQo+IA0KPiAt LQ0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5n IDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzDQo+ IDxodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTE1ZmM5M2I1LTRhNjdhYWY4 LTE1ZmNkMzJlLQ0KPiA4NmI1NjgyOTNlYjUtNTM4YTFlN2Q5NWUwYTY0OCZxPTEmZT1jMDI3NmFj NS04YzhhLTQ0ZDYtYTlhOS0NCj4gMGM1MzYyMTVkYjVhJnU9aHR0cHMlM0ElMkYlMkZ3d3cuamFj b2JzLXVuaXZlcnNpdHkuZGUlMkY+DQo= From nobody Thu Apr 22 02:08:04 2021 Return-Path: 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 15FD73A0C0B for ; Thu, 22 Apr 2021 02:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.onmicrosoft.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 fm5R2pUr5YlX for ; Thu, 22 Apr 2021 02:08:00 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022CB3A0C17 for ; Thu, 22 Apr 2021 02:07:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y9/R4iIDvWzZI/isQjIr6EVm0dmtWJz2c4iTTJ6BSNQv5dddmRcvWlexuqKehfhEssTk4PLxIIMIEGBOFWpwsu2Qgsjgo56KIuqb6R4IM9eJK7JsTGWdTX/f8xqec2zFDxZ4L5xlUgmPpVJ62pVuEwsXcWBZn5nDk/HWRrThmeGXcHoLnu0kYW/+566xy0UkDQPYPmZ7n0bobwviiZL4hdgvEywNiAZx2nYMp+WVIAiRsrssFeafKztK3P6S7l++p/JYd2ugBR1rRVOxNUe7uZ/Z+NLBKaUfGyxC1lgQ9cH1riwKtq9hoynBaJWaLoHnXIIcJikkFzybdEe8h9YhhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g+eLjlLhwxUdUW2aKySfIgKHlPgcaDSznenHt4tqI1k=; b=AmlN/+AIshyoevlumEQks9bmujg/XaDHgxFypfwrxuGMNUe+0kztD8ZkxYi+bE/nCK/Zr20mQS9a3oUwT36dn5Lp2aEWL653vqQxLmcfH9pR8yfmP7/re67yA+w+6yZzRkHp+n3J9TQMsV2HSgctXNDWTZZP+MxsyUd+PZhtIuEyzjna1X5IgfcRZndMSfMnGB9mTzlwXk5IYhktDSCq4ZNyRTwcsp6OUrm/49IOym7g7EHrn/Z9MBLDa898eE+zcGby+gt2L6U2mzoO5s1iHxZnRSoUeNWUCZlZmdwlnjeeKnZskPS89Ip+h8/hFe8qk9j6v7KP+jq8JN3QHRFNvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g+eLjlLhwxUdUW2aKySfIgKHlPgcaDSznenHt4tqI1k=; b=DRROTFbn2YUaBSJ3lvzbEmjxWLgKNmjpsvhS/bC64FlLcAwlOwmh7wC1yeD1mmD65/o4vbHcpygluyps8NyO2rQaK6CR+2MYWPF7a7VsgxOe8NaB9ZhHwk4WhsWuakfIgUfhEcxzaQj/UxyBBjH8nt0sk5CpvL/QzO7sPCIhCWg= Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=lightside-instruments.com; Received: from AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) by AM0PR08MB3122.eurprd08.prod.outlook.com (2603:10a6:208:5d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20; Thu, 22 Apr 2021 09:07:55 +0000 Received: from AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::84b4:6a0a:9a03:af99]) by AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::84b4:6a0a:9a03:af99%4]) with mapi id 15.20.4065.021; Thu, 22 Apr 2021 09:07:55 +0000 To: Andy Bierman Cc: "netmod@ietf.org" , Balazs Lengyel References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> From: Vladimir Vassilev Message-ID: <1003348d-f98f-438a-cd47-0ed3a13ef6f7@lightside-instruments.com> Date: Thu, 22 Apr 2021 11:07:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [84.209.6.28] X-ClientProxiedBy: OL1P279CA0035.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:13::22) To AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.19] (84.209.6.28) by OL1P279CA0035.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:13::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20 via Frontend Transport; Thu, 22 Apr 2021 09:07:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 21ea1a6c-7e77-4632-8952-08d9056e1db8 X-MS-TrafficTypeDiagnostic: AM0PR08MB3122: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SLWjw7eSwFG/HXrcHfmQCDjK8L+kLB21/rod3dm5awyHbjM4JLKuFtVMvn78Bl12e/JIsOrq7fUXWOyf9g0ndbds1qE94G7yXghnI9LFWRSLIky5UQpaUE0PTB7LdbQ+qZffQ+nWaXFE1FxGCsgORySGZpXwh3eAn52LDrXqfcI9NZ6Z18HYQSxq8NAlDdm7DhdhgJrb8p7lks8GBMDCXmUXUy9N4yaNXzakOiV8OIgOFTPxImLk2SxXFZ2YFp5wLtRSe8ql1G4VaO/AvZbN8rhEOBFIDA7w22qkz7nsc42zloxmMJQOJrgQMGoolCgy3WqeJqN4SDd+mHe/qotDZv/SdoTnIZ0CouajljNpArIW3eStug6Sgd5TZNFIL4nWyaySHCPoGen2UcWUGBHVEiCZZKbQ+1cO3ycgPuzYrCRE1Oka+qJeyDtvc8OI2KNCX/BHs+U3q5DER+Opx2TfxBf30SC5uwLUzGuj/oe2AAbj1bWR9lvxw0Itiu0NU4eNsHgSUNMwJNnpHOaFBkjf4IB1DLrNUYQnU8bg/BlaLMdSADu0RXU2+K8GnvWj/uw1guRHxTTY3a559f4Nh6vNOro9unTHhCCOIzbB5PX8b42uRUuAXkYTv7vsAUdnLNj+gVVsge/Eb8bYgWL99WoWhs5XFOXXi7ONDTQhr82X9taCE3AElph3gYzNdO9j0Te8uSnhOSseyuHC6ddz4r3rEg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB4084.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39830400003)(346002)(136003)(366004)(396003)(38100700002)(8676002)(956004)(16526019)(38350700002)(54906003)(31686004)(2906002)(2616005)(52116002)(86362001)(6916009)(36756003)(186003)(66556008)(8936002)(16576012)(31696002)(66946007)(6486002)(5660300002)(6666004)(478600001)(26005)(4326008)(66476007)(316002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?TG0vUXNNa1Z2NVA1SWVGaXAxaEdPUTBtM0tVT0dNMnVLVEVIS3M5N2FUblRk?= =?utf-8?B?QVU5cENGWnRzR2VLb1JyS09XUm12bm4yZnFUcnB2MW5nR216L2lnL1VvWUJD?= =?utf-8?B?djA3OGVjcHNjd0VPQ0djc0VXS3VmeHUxb1BKTEZuWGdLU3Fmb3pqUU5yUGpE?= =?utf-8?B?aUg4OEp4dXF4bFgrcEROYU9Tai8zd1NIdlA4QW9maVhVamFDNXlJdlUrY2Fm?= =?utf-8?B?TURSVjJQcnhPUlR4b3NMdjNLS09VNy8xbEhtckZkemNPdlY1OFZnYW1ySXRt?= =?utf-8?B?OGZYSHFNY0ticldIck8zaUdSSTVuL3ZMWlNQWXhhQmJzdGY5d0dYc2Vpc3J2?= =?utf-8?B?MXFqVG42SHhVYUR0a0gzdU44SjUxYU9Jc3BLbUpvWEJNRHhnY2hkaHRXeHAz?= =?utf-8?B?by94UDRsRXVJNzBNSHpCaVVPbk9McitJR004azIrMWoxcVJiMm9LQVFjcHFF?= =?utf-8?B?NW1wUi8vTkZRcXFGdFV4WUhwMUR2dTBtZjJmYnJMeXlGeElRSVhMLzMwSFJL?= =?utf-8?B?RXAwZzVzQjJ4Vlc1dmRPUGp5aGdYTTdjZzB0R3IzRldTLzZBbnVZRWl2NkRr?= =?utf-8?B?dmovNStiN0ZTMStwVXlkQ2pzdFcyY0VvbGNOOUtQZGRUSnZyME1leE45N2lq?= =?utf-8?B?VVBBK1NzRndNVVlNa2JkUjNhU1MwTGxxWFJYakV3Z3BIdURIRUJEMitjeklB?= =?utf-8?B?RGlmWEx6dFlpOGNPaXdyK1hPMG52WHMzN1I5L0FXaHNtanlmSlBtaFpLWjha?= =?utf-8?B?ZG02bTlUeFZybm9oTzI1czVMNHRqcFJqcEptbkp3ZFlWZTBMRDBBdU5pZWpC?= =?utf-8?B?eE5CVlEyNWd3eWpndDFwMVV0UkQ0ZVVnUDBTNWl3N0o1NzFUWjFYeUtaeFht?= =?utf-8?B?aVRPMnRPb2dxQXZiSUlEV1ZHTmtJU1dOV0NoR3NvNDRVWlNVTWQrNG40dVNF?= =?utf-8?B?WFd2ek03Y1lRcWFTYlExYkgwQzVFb2tkNmNnMmx3NFZVVTEwR3NlejRsblha?= =?utf-8?B?emZ2b0NpaGJBR2c2S2RMV1AzLzRMdTJ5WkwrRHUvSHNWc0t5NlQ3Q2IrNmV3?= =?utf-8?B?aVQyMndqMFgvT2g5UjdBMEVhKzByaFk0Tm9lQmpENzRrWDNGNDhOOTlTYnpj?= =?utf-8?B?L1dzdWZ0aTA0STBNdWRFamNmRVkyOEJTam5yOEM2QXBGdkk2ZlIwYm0wcjJl?= =?utf-8?B?RTQyVDFUeUhqK3h5SDVlVVlvL1dxdHd1cDhYakVVWHVBVkFJdkRYa2U5WUxr?= =?utf-8?B?clJiNEgveDM0QUhack1CenhqY0phdGhtS1dzd2JmbS9xYmFUQjJjQ0hHN094?= =?utf-8?B?NmFFSXJlNmlnWm03VDV0aFgwSnlrMjZPMnFYa3NqbkdDenNocmNFeUFxekRv?= =?utf-8?B?RmxWM2hxZytUUTIvdU95NFhoalVVdzJWZjhpUG8xK1A1YjNvRE1TTGdQUlNJ?= =?utf-8?B?MFdUREsrT3k5RHA0RDNlMGVqVHVlTVBRVlY1alkzM0xDMWYzNk5DSWNFdnN0?= =?utf-8?B?LzhDRGhub3JwMWlzKzNyTUlzYzRGNThvcUpyYlUwNktVenR3WmlkMjIybVRV?= =?utf-8?B?M2F0ZFk3OFR1ajBDdUh1cW1OVWxLQUNTZ1ZETm1MRlhZZlZZKzEzMlNHVnJL?= =?utf-8?B?V3poejZ6U0ZhOFNJa3BYeTdZK2Q0SllISlBqREp5REpoeHNrdmVraVlXQ0g5?= =?utf-8?B?S0V1T2ZvcXdzbFo5WVJURGUwOG5JNWZjaENhUkJCK0JlZXBmY2ZNOUJNK0VZ?= =?utf-8?Q?O8ZtjmbNFpzSZl7XmAevTAy1/c9V/E8EuMoDcSU?= X-OriginatorOrg: lightside-instruments.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21ea1a6c-7e77-4632-8952-08d9056e1db8 X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB4084.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2021 09:07:55.7457 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c0326317-f373-4461-a96f-7946e0abb603 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HexY/HYAQatmsiMBkt+R/tTfShU2d4Kd7PoW/LlZugEmZ6f102GmIoUZ8nS4UcFcYtz8b42lxEGCnw5kM5zKSsOvB/pJTHdQOyrPDH/hGVRh1dr+fw3JkYgZvQOdnhTU X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3122 Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 09:08:03 -0000 On 21/04/2021 17.10, Andy Bierman wrote: > > IMO mandatory-stmt has no meaning for config=false. This is not spelled out in the current version of YANG. Instead one can assume that using config=false, mandatory=false leafs is the correct way to model optional information fields. There is nothing formal in RFC7950 that contradicts that. This interpretation seems to be one solution when the implementation has to handle different equipment instances where some support certain information fields and others do not. An alternative solution would require the overhead of defining an extra leaf for each optional leaf indicating if the information is present or not or adding an invalid value to the value space of the leaf representing the optional information. That said I do not think this optional information fields modelling technique was the intention in the majority of published modules that do not specify mandatory-stmt in config=false nodes. It is just that RFC7950 has mandatory=false specified as default and this works better for config=true nodes then config=false nodes. /Vladimir From nobody Thu Apr 22 08:06:53 2021 Return-Path: <01000178fa1e7aae-c345a751-f2aa-46a2-bf2f-7b8cc1777255-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 C3F613A1262 for ; Thu, 22 Apr 2021 08:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 hv_a8BhmFRts for ; Thu, 22 Apr 2021 08:06:46 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1233A1261 for ; Thu, 22 Apr 2021 08:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619104005; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=a6L/J7xNa+NuDmiYjEOp0gMUNP8zpruVDAdvYCeIvnM=; b=g76nHjxlauyQCGD7KHBRr5PRVQNklEMyb74ihDWt7n3YGEUgMk5ke6APU8XBiQDW trzPRjr7H8hp1sH9HuM8Pan4TpN3MH81LyELquq/BDgLZJ31Y9MqkTkDKreYiTuPBT5 kgGHOgpbBU8bVgNlEjsmONKtVEfzNNjxxVm98f4I= From: Kent Watsen Message-ID: <01000178fa1e7aae-c345a751-f2aa-46a2-bf2f-7b8cc1777255-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_668E07C4-FE50-418C-A432-23AC6EF6A647" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 22 Apr 2021 15:06:44 +0000 In-Reply-To: <1003348d-f98f-438a-cd47-0ed3a13ef6f7@lightside-instruments.com> Cc: Andy Bierman , "netmod@ietf.org" To: Vladimir Vassilev References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> <1003348d-f98f-438a-cd47-0ed3a13ef6f7@lightside-instruments.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.22-54.240.8.96 Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 15:06:51 -0000 --Apple-Mail=_668E07C4-FE50-418C-A432-23AC6EF6A647 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > That said I do not think this optional information fields modelling = technique was the intention in the majority of published modules that do = not specify mandatory-stmt in config=3Dfalse nodes. It is just that = RFC7950 has mandatory=3Dfalse specified as default and this works better = for config=3Dtrue nodes then config=3Dfalse nodes. I tend to agree. Furthermore, I feel that it is best practice to = specify "mandatory true=E2=80=9D when it is the intention that the = =E2=80=9Cconfig false=E2=80=9D node is always provided. There are effectively three kinds of =E2=80=9Cconfig false=E2=80=9D = leafs: 1) opstate data 2) rpc/action replies 3) notifications=20 IMO, the =E2=80=9Cbest practice=E2=80=9D holds in all three cases, but = it might be interesting to consider each in turn. Note that I wrote =E2=80=9Cintention=E2=80=9D above. It is understood = that a system may not be able to provide the =E2=80=9Cmandatory=E2=80=9D = node, but I wonder how much of that statement is supported by data. K. --Apple-Mail=_668E07C4-FE50-418C-A432-23AC6EF6A647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
That said I do not think this optional information fields = modelling technique was the intention in the majority of published = modules that do not specify mandatory-stmt in config=3Dfalse nodes. It = is just that RFC7950 has mandatory=3Dfalse specified as default and this = works better for config=3Dtrue nodes then config=3Dfalse nodes.

I= tend to agree.  Furthermore, I feel that it is best practice to = specify "mandatory true=E2=80=9D when it is the intention that the = =E2=80=9Cconfig false=E2=80=9D node is always provided.

There are effectively = three kinds of =E2=80=9Cconfig false=E2=80=9D leafs:
  1) opstate data
  2) = rpc/action replies
  3) = notifications 

IMO, the =E2=80=9Cbest practice=E2=80=9D holds in all three = cases, but it might be interesting to consider each in turn.

Note that I wrote = =E2=80=9Cintention=E2=80=9D above.  It is understood that a system may not be able to provide = the =E2=80=9Cmandatory=E2=80=9D node, but I wonder how much of = that statement is supported by data.

K.

= --Apple-Mail=_668E07C4-FE50-418C-A432-23AC6EF6A647-- From nobody Thu Apr 22 08:25:20 2021 Return-Path: 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 3C9A73A13C1 for ; Thu, 22 Apr 2021 08:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 r2sbKMU5FMQQ for ; Thu, 22 Apr 2021 08:25:13 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 4C4323A13BF for ; Thu, 22 Apr 2021 08:25:13 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 12so72550901lfq.13 for ; Thu, 22 Apr 2021 08:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kSWXZr5o8Svx8mXlWScPFG8WSPvmYoYTP82h9k2Nkb4=; b=hDLPV5YIpm/CECXhM5r8USVr+qKFfs9ZyMDSNiJitdK5MVJa8UZKJ0Oi176CuOsykW Syuv8syKDNajJ/wGbjRl63Tdcn1j7XNJS3fFCcJ1dhT1peAE7zfLdnAdjl2piCNui7KQ jlgkleTlZ3U5Bthzzbn9HCmf73RIFgSwyltlHmXvvlUwF3VI7DcDnzyFclV+8s6f40Sf UCfv3NNNnVITgs0EObWBstCsYv96D8wsdmJXovZfR0RU+9bFlNGlgGQRk6U3VwdgvKlp nwUxRZWhW70aPo5LMsUlCEDgChHoQYcQD5X9SS/4ZoBEoPxc+XdWaaIExCABcYz3G1w5 JQ2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kSWXZr5o8Svx8mXlWScPFG8WSPvmYoYTP82h9k2Nkb4=; b=D/axzi7HOQpHGMXRT7A8uiavsPeiW4A80h+yrs1awp92Cs3cim2VaqE6TxHmbtAD1p q6BClFnYscUW5ctwE5x2mLvutSkQhjp/XkIGTHiTj8XnGPpzv7bLQaJVY0ticzbV2vjh PymwJPUgIWH4QA0Uq4HNy0qUI6SDHqopVGS5lA5fKd1AXNrbxTRSavtEUxm86LzyFuwF w66W5UQsQ5ZX60rIzb/7xq5j934937DLTXtJKRDeRE28zSh5HGOxOj6b97rk42aqZaHe OJNlnuy9+Pt3TI5UxnhSwN4MUBQ2CUviqk16oJD5BqJDAhmX8CgysobyT7b9pDi/VD4Q acGw== X-Gm-Message-State: AOAM530a4DtNKec9LQDnj4Le4bp4EmAlH/SWL2whhAXMKBJ2OiFJSYBH H+fI25Nt4cB/rrtfH4ozyf/TpXKZbyXCd+OFXRdX2w== X-Google-Smtp-Source: ABdhPJyd9c1n3g0XYOway2nnw+Y8aR5CwUeiHq4APL2UelBvEY7RVmIDhQllGZZrqgatyMkA4Tdwy+esJRDoH3MB7Pw= X-Received: by 2002:a19:b81:: with SMTP id 123mr2901556lfl.553.1619105110416; Thu, 22 Apr 2021 08:25:10 -0700 (PDT) MIME-Version: 1.0 References: <20210420162631.ufy63hvyrjmkvi3g@anna.jacobs.jacobs-university.de> <20210421103228.ik2e6aq7et6izoax@anna.jacobs.jacobs-university.de> <1003348d-f98f-438a-cd47-0ed3a13ef6f7@lightside-instruments.com> In-Reply-To: <1003348d-f98f-438a-cd47-0ed3a13ef6f7@lightside-instruments.com> From: Andy Bierman Date: Thu, 22 Apr 2021 08:24:59 -0700 Message-ID: To: Vladimir Vassilev Cc: "netmod@ietf.org" , Balazs Lengyel Content-Type: multipart/alternative; boundary="000000000000f5f37d05c09148e5" Archived-At: Subject: Re: [netmod] Compatibility of config=false data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 15:25:18 -0000 --000000000000f5f37d05c09148e5 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 22, 2021 at 2:07 AM Vladimir Vassilev < vladimir@lightside-instruments.com> wrote: > > On 21/04/2021 17.10, Andy Bierman wrote: > > > > IMO mandatory-stmt has no meaning for config=false. > > This is not spelled out in the current version of YANG. Instead one can > assume that using config=false, mandatory=false leafs is the correct way > to model optional information fields. There is nothing formal in RFC7950 > that contradicts that. This interpretation seems to be one solution when > the implementation has to handle different equipment instances where > some support certain information fields and others do not. An > alternative solution would require the overhead of defining an extra > leaf for each optional leaf indicating if the information is present or > not or adding an invalid value to the value space of the leaf > representing the optional information. > > That said I do not think this optional information fields modelling > technique was the intention in the majority of published modules that do > not specify mandatory-stmt in config=false nodes. It is just that > RFC7950 has mandatory=false specified as default and this works better > for config=true nodes then config=false nodes. > > I misspoke. The mandatory-stmt applies to the top-level leaf. A valid state data tree must have the leaf instance present at all times. If mandatory=false then this instance is optional. So if a client has a complete copy of the server state data tree then the mandatory-stmt validation can be checked. I doubt any server implementation would ever validate its own output. This is a slow and expensive way to discover bugs in your own code. I don't think the WG gave much thought to the issue of client validation of server config=false state data. Several WG members have expressed thoughts on the wisdom of sending an unfiltered request to the server, in order to obtain a complete state data tree. /Vladimir > Andy --000000000000f5f37d05c09148e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 22, 2021 at 2:07 AM Vladi= mir Vassilev <vlad= imir@lightside-instruments.com> wrote:

On 21/04/2021 17.10, Andy Bierman wrote:
>
> IMO mandatory-stmt has no meaning for config=3Dfalse.

This is not spelled out in the current version of YANG. Instead one can assume that using config=3Dfalse, mandatory=3Dfalse leafs is the correct wa= y
to model optional information fields. There is nothing formal in RFC7950 that contradicts that. This interpretation seems to be one solution when the implementation has to handle different equipment instances where
some support certain information fields and others do not. An
alternative solution would require the overhead of defining an extra
leaf for each optional leaf indicating if the information is present or not or adding an invalid value to the value space of the leaf
representing the optional information.

That said I do not think this optional information fields modelling
technique was the intention in the majority of published modules that do not specify mandatory-stmt in config=3Dfalse nodes. It is just that
RFC7950 has mandatory=3Dfalse specified as default and this works better for config=3Dtrue nodes then config=3Dfalse nodes.


I misspoke.
The mandatory-st= mt applies to the top-level leaf.=C2=A0
A valid state data tree m= ust have the leaf instance present at all times.
If mandatory=3Df= alse then this instance is optional.

So if a clien= t has a complete copy of the server state data tree then the mandatory-stmt=
validation can be checked.

I doubt any = server implementation would ever validate its own output.
This is= a slow and expensive way to discover bugs in your own code.

=
I don't think=C2=A0the WG gave much thought
to the= issue of client validation of server config=3Dfalse state data.
= Several WG members have expressed thoughts on the wisdom of
sendi= ng an unfiltered <get> request to the server, in order to obtain a co= mplete
state data tree.


<= br>
/Vladimir

Andy
=C2=A0
--000000000000f5f37d05c09148e5-- From nobody Sun Apr 25 23:46:47 2021 Return-Path: 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 E4F8C3A0D81 for ; Sun, 25 Apr 2021 23:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, SPF_PASS=-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=ericsson.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 ljVoFcWUe9_R for ; Sun, 25 Apr 2021 23:46:41 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D573A0D6B for ; Sun, 25 Apr 2021 23:46:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KrjNMMXtE2GZVhFRfGIwjSHnrLYR5R5K32N4cQM2AREMFACHFuyArx5A6soUrzZvWGarR/acWQC2zc0M6ie/W6zK5ywWA8R+YtpiY5BR9zjzL6L2l6VGeZabZ9dvht9enRkdMvMPlV0O74v6zMfqSR21ITL7aneiQ4SFTfQYhMxHoein2Wpgdrjj1tUKocW0/jahte08XGJJeqi6ML5EA4RMZoICmwrfSvqJfM22zZr3uKMpqImnxubkt+F84VnTKEmvVqtt2VU9QJzwbs6hVK/Gg9t8FJkUIP5VZTgMm4eeTKrThSoS73EGskJVLuhwYQxcDKXh5GA8DdmPhm5khg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w/sP9IyYIyc+y/SihancyyX4MPluh4rFcZYMuWY+9bg=; b=aBPkVtSwl9kje9j4S+xX1urwwgz5jzvPhTVGrvfQI9J3bPIwKYvayexSweb0r6QyarKeobKrd+6tUarF5TC70phd8RFZznGp/N3I9XJE+Ao68I+7aTbZVlhypY2/J6FtvYpSdW6JoVM9ybPn+ty8hRo9AGiCbaFo1lFU7jNbRAsrN8NhzdopatE9RjUzDrOQuXzZPqP7VLklgIcI+crn3vdSmNJtX3xlLCXnQ65jDOAeSTj4ZoUMB+S/0M9c5pGCK1cKPhQPSGwvdmWIwiV1ZfmqvA8LZZS0dGjmhON9PoEBIz9QMLxOBn6Wm+dVIb5aHI15od8MSjqINsnT5NA5CQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w/sP9IyYIyc+y/SihancyyX4MPluh4rFcZYMuWY+9bg=; b=nkfrhV+H5OofiuyzfLQooLpJx0LJ4Zqhk60FnS6r6uf6jEQcI85p03NiglA5kyKr+SO8AN8M9+jcNgw6r3NJRkWc/RT5AiV3Jw9V1wz9CeAqeZd3idklmFAGQAN2UvxFPCOQXLevRMlXhqCrdDvNQvT55BUS/J2vWiAZ6N7RzqQ= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8172.eurprd07.prod.outlook.com (2603:10a6:20b:323::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.11; Mon, 26 Apr 2021 06:46:32 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::1c20:4116:edeb:8f8e%7]) with mapi id 15.20.4042.028; Mon, 26 Apr 2021 06:46:32 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "'netmod@ietf.org'" Thread-Topic: Network Modeling (Concluded WG) ??? Thread-Index: Adc6ZKKKzeml8tK0TAm2GdvjNVXh4w== Date: Mon, 26 Apr 2021 06:46:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.248.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f900d6d9-a0f6-4627-cc1b-08d9087f06f7 x-ms-traffictypediagnostic: AM8PR07MB8172: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 21CpdsdBZ1SGYx1JNbHsmIDwl/C/u8p49nlC1HzZUJgJ/THIDIL5VgUn8/aOm7DI7eMY6UAxf06xgiDZO8HQTJ5U5q/vIxB4AFNCJUNGkiTWkuHiSthUryIwYs9nb5+/zTUOGSrhgC9EpPvzp23sFRzo5y6C415nRQtTydzXEDvTTPeyjTxHivLwx1p0t8pZHmjkYYiF7yK+TwP75RFKfe4XVvcs7oHrLw9D+3OoWr2JwWnVzGpkLMl/FGt9D/Lz8Dj8NmAuBcCpXUQfIQ4h6K/zkM7jBKaRdlvro2ONIGNFZ+obBCQRaHDyHuymQ2SOjmLNn/+aeoD5+FI0zwP4UDg3P19hFQhlACN58EFvwRnhojiWBYK5jEkG5ZRnt43V81ehZYMf46CBl4HXYK41/S3ghzbVnrJo68nrwZg9jjft5sdaCrakq1UlNAcqNxIpBxj+09+DiOvLFsfrCdSQTsWW4bf9KzC8S80BXE0Nwh0/EVBNq2Kc1Nfu2QQlbPvdKidHzZlJ+PBWvm0FqJy2tyfs5nIArcyyf7phhD5Tn4YDJ+ataMl5tu3W4Dcqmx7kKz/X1HXHNFgwZa9VARR1JnVZnmi59/6wu1WRgnBHoVutrPWw28cLVO9A8e01Xa1r/C7U7iKhOLNaP/CHnLhG+VdGSmOw3MKEGYSW/HLXCNkZKkvZeSB4/btvLV7ashcY5VtD4nyvd3nj0cYIh2YfDAu2pNOXDO6tG2Wmcwx0m7M= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(39860400002)(396003)(346002)(316002)(71200400001)(9326002)(33656002)(6506007)(52536014)(2906002)(8676002)(6916009)(186003)(478600001)(26005)(966005)(7696005)(8936002)(66616009)(66476007)(64756008)(38100700002)(66556008)(55016002)(66446008)(166002)(76116006)(66946007)(86362001)(122000001)(558084003)(5660300002)(9686003)(99936003)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?uIDI+NNc7w72E/VUQNIs3Sv/dOV9CB/y/jK+ZXztvzIWSdL15moljXMrKW?= =?iso-8859-1?Q?vaxb32mVBj9Ito32+7pWJVsVpZ04Kjq8fYZw15VYH7K1ke+HnZ1tTiLYyY?= =?iso-8859-1?Q?VU0/6j9NfRCarDjrLTDqrd2Hny1cf8ZXyQqWKCT8l13TN4f3CW9VyPz5DJ?= =?iso-8859-1?Q?fyrnOFOGPSGwrfvi2vmWTq//R81T+2UNys1zFKIYf1meTyVKNyCfdloUHI?= =?iso-8859-1?Q?/LKRqFo8gcFhqcvP5Rix6thJVnLVsKhTseMNfoj7G35aaFIYw+4RQG9Scm?= =?iso-8859-1?Q?Q58sRH12fMIqg3RJNQ4RSpZiBYrYNaPprZKC+fXVE5hHajl7FTYe/NQKzt?= =?iso-8859-1?Q?IU/gP44KhNC7vH7J0Z5um1glPtd3roCVBQ0dtRpR11Ax6oMqyTXlI5yAco?= =?iso-8859-1?Q?7qxODbxITPNn6/znEjDr3sP/9HqORhfO/1DEy5Az4h4joeGvt5rWBGyJj/?= =?iso-8859-1?Q?h5Hfxfy7tFyjVy8ww597IRBDVtApRkVnJ7K6ANdB+VJ2XwoGNS4S8EOUZ3?= =?iso-8859-1?Q?FnDsJU5mqs69cNuyzwpA+qSruhNF2MGfISlxScpdwOnqM+hMY2NS8at/6H?= =?iso-8859-1?Q?xBtzCbeyPX7rKXH6Q/8cVpcII3V8sFViGcZ0JtQtVYC9+ASY0HgsUtF/B6?= =?iso-8859-1?Q?fLZqzb4DOkTnF1VJ5bKc6WRnVkoXwLyenoIfJU6HiJ15Nfr/fbRVenW8Ty?= =?iso-8859-1?Q?mK43XaspicQD5N1n9+Iw9M1nb7/lMJyGZ4xrM2K6FEXy8+1Qa9Y+HBjt/I?= =?iso-8859-1?Q?zfw3V1Xoc+ErGFBW4+IlhDK6wOMAibQJaJVfteRx+KU1Tl9qArPCm7zNun?= =?iso-8859-1?Q?xIciMbf0HJyoYa3oqguMrCKUijQ5TWNtsUArrcJqVwiOBRqy7/BfRQN0eu?= =?iso-8859-1?Q?7MFnykkhfC7o2ueiKEjml1X3klg90SF9q+1d3WE2Q3SgZBR9yIk1Dj1PdI?= =?iso-8859-1?Q?+1bG4CnDQ9BVYNJ/ECKSxPgen+zMtxzs/jAstOT/r7Gn6lu3BlCxQQc0rx?= =?iso-8859-1?Q?YpKXDHlePgD7zzxDiNEXTxCDh767uwhanBTAEoHqHgMvjr5BbzpNk/Tyq3?= =?iso-8859-1?Q?2DoTeRIZYGMh41zvSTKN3AFNqiP9d8vIhzarqU9MWuH6i3+T2fWzowDqJ7?= =?iso-8859-1?Q?60MmePZx2mEWo/6uS0k/M98u6Z1VrK78HKUgeOaNQBCRvx2gR/gxos3kBg?= =?iso-8859-1?Q?uaitHlJ32Q+f3erE9E/PsiM02BwkcvfmN61kLdv3dxPChpbWwj0qY9U8v9?= =?iso-8859-1?Q?1OAr+NbK/zQhmd/nbz7ffyVp34qLDK3OpSUCGmUHN+w2HW+AVvKeghIkLk?= =?iso-8859-1?Q?1b4+F5HZv9hXeXtmdzCPColLvuzotFnJZhJivwlWVtyvOGz42ZfNfi1AqG?= =?iso-8859-1?Q?tbCT84pOu3?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_08AA_01D73A78.A6F59D80" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f900d6d9-a0f6-4627-cc1b-08d9087f06f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 06:46:31.9322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZwVWLkRyAAnCxEAGk9f5keoaBAGtFibxpQUlumTUJhrnva/aWFsxJIlnMzUFQvAfsJQWY5VqWGGWsCtORDBVklkzsYC/k+gHDlD5JUmDLeQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8172 Archived-At: Subject: [netmod] Network Modeling (Concluded WG) ??? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 06:46:46 -0000 ------=_NextPart_000_08AA_01D73A78.A6F59D80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_08AB_01D73A78.A6F59D80" ------=_NextPart_001_08AB_01D73A78.A6F59D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, This is what I found today on the https://tools.ietf.org/wg/netmod/ Netmod Status Pages Network Modeling (Concluded WG) What? Why ? Regards Balazs -- Balazs Lengyel Senior Specialist Ericsson Hungary Ltd. Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com ------=_NextPart_001_08AB_01D73A78.A6F59D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

This is what I found today on the https://tools.ietf.org/wg/netm= od/

 

Netmod Status Pages =

Network Modeling = (Concluded WG)

 

What? Why ?

Regards Balazs

 

-- =

Balazs = Lengyel=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Senior = Specialist=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Ericsson Hungary Ltd.

Mobile: = +36-70-330-7909=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: = Balazs.Lengyel@ericsson.com

 

------=_NextPart_001_08AB_01D73A78.A6F59D80-- ------=_NextPart_000_08AA_01D73A78.A6F59D80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDQyNjA2NDYzMFowIwYJKoZIhvcNAQkEMRYEFJHLFrsQR2Y7 PLw+PHl87J0yXWoBMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAHoI tCdb15w5m/4saABoYUtD263SCkKOuTYRYe/c94Gu0xj7KhVOVFb9tLn9WqRRDIPyKP8/sKRHlEjN 8uYafY0zYPbvDUAUxYbkfDVmlr+Q/Eu4PK3xmNaYSOm/9y7bdllQDo0QHP2QYOVsN1Fl1j6EHhBG VTFLx92xKJblFgYAyUCe4w7g4sN9gQ4G7TUIQ6i2w/ucinh5vK70wMwNsLh3y7UlTgkj4TkkuV3W 6c9OeGZTElN9Blmiwbd44QF2+ezvvyjA18mDmbrZE4zj0muQAA8IqIww/iOxvjVlMSfCdi/U2FB5 V6OViWQ9dFZSD1tMleD4+NSosRHvgs3/XXwAAAAAAAA= ------=_NextPart_000_08AA_01D73A78.A6F59D80-- From nobody Mon Apr 26 01:07:24 2021 Return-Path: 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 52FDD3A1269 for ; Mon, 26 Apr 2021 01:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 34fytstTnCue for ; Mon, 26 Apr 2021 01:07:18 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB533A1268 for ; Mon, 26 Apr 2021 01:07:17 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FTHYc34tJzyRk; Mon, 26 Apr 2021 10:07:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Mon, 26 Apr 2021 10:07:16 +0200 Cc: "netmod@ietf.org" X-Mao-Original-Outgoing-Id: 641117235.841725-d6ba80bab0ba214915e0db4330fb2b75 Content-Transfer-Encoding: quoted-printable Message-Id: <166267A5-81AE-426F-86B8-09E318EE5631@tzi.org> References: To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netmod] Network Modeling (Concluded WG) ??? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 08:07:22 -0000 On 2021-04-26, at 08:46, Bal=C3=A1zs Lengyel = wrote: >=20 > This is what I found today on the https://tools.ietf.org/wg/netmod/ As you can see at=E2=80=A6 https://datatracker.ietf.org/wg/netmod/about/ =E2=80=A6this is a glitch. (Glitches like this have happened before on the tools servers; = unfortunately I=E2=80=99m less optimistic about this being fixed as = quickly these days as it used to be.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 26 01:31:10 2021 Return-Path: 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 2B80F3A137F for ; Mon, 26 Apr 2021 01:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.917 X-Spam-Level: X-Spam-Status: No, score=-11.917 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WWjcWk/o; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aJVqmkHI 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 lPG9kpXvStD5 for ; Mon, 26 Apr 2021 01:31:03 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FE43A137B for ; Mon, 26 Apr 2021 01:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6480; q=dns/txt; s=iport; t=1619425863; x=1620635463; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qDX+GZ9wYlqgI1mh1iHOEIeIpay5Yry1upuhTXFCdNs=; b=WWjcWk/o91O9XXleOPWXNZUVN6HNg/l+mi1tyCkkRvOK2tTfugc8ZJjN 0sR5JRzTrp9P4D8KbnI51ZGUL/6YJ9H/G18QTH6RMrHkAa1bcCZg5itF4 eLwbg+dLw40h1x6YtG4/NOduAnZCtltsoBe94IqxdAcxOhpXGymQb020O E=; X-IPAS-Result: =?us-ascii?q?A0CVAgCfeYZgmJ1dJa1aHgEBCxIMQIFHC4EjMFF+WjYxC?= =?us-ascii?q?4gAA4U5iG6UTIR2gS4UgREDVAsBAQENAQEkDgIEAQGEUAKBegIlNQgOAgMBA?= =?us-ascii?q?QEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQDYZEAQEBBC0TAQE4DwIBC?= =?us-ascii?q?BEEAQEoBzIUCQgBAQQBEgiCaQGBflcDLwEDnl0Cih94gTSBAYIEAQEGhRcYg?= =?us-ascii?q?hMJgTqCeYJxEz9GhlMCJxyBSUKBVoJfPoF9YwIDgSgBEgEjKwmDF4IrglmBL?= =?us-ascii?q?FCTEyeKeIFanREKgw6IX4ESizeICBCFEZ9/lSeLeJJohG0CBAIEBQIOAQEGg?= =?us-ascii?q?VYBNWtwcBWDJAlHFwIOjh8Zg1eFFIVJczgCBgEJAQEDCXyLAwGBEAEB?= IronPort-PHdr: A9a23:cE2X2BJUIP1WH34FPdmcuZsyDhhPgJ39IxIV55w7irlHbqWk+dH4M VfC4el25HfFWIzB4LRFhvbY9af6Vj9I7ZWAtSUEd5pBH18AhN4NlgMtSMiCFQXgLfHsYiB7e aYKVFJs83yhd0QAHsH4ag7ep3So5ngTFwnxcw1vKbe9Fovblc/i0ee09tXaaBlJgzzoZ7R0I V22oAzdu9NQj5FlL/M6ywDCpT1DfOEFrV4= IronPort-HdrOrdr: A9a23:3kCaA6NF9Bp+4cBcT5vx55DYdL4zR+YMi2QD/3taDTRIb82VkN 2vlvwH1RnyzA0cQm0khMroAsi9aFvm39pQ7ZMKNbmvGDPntmyhMZ144eLZrQHIMxbVstRQ3a IIScdDIfX7B1RikILe6A63D94vzLC8gdyVrM3ZyGpgShwvTqlm4RtwBArzKDwIeCBtA50lGJ 2AovdWvjbIQwVZUu2XJFkgG9LCqdrCiY78bXc9ZyIPxQGSgVqTmcbHOjeC2BN2aUIr/Z4D9i z/nxX99uGftZiAu2Lh/kvyy7gTp9f70NtEA6W3+4YoAxHhkByhaogke5DqhkFPnMiV5FwnkM bBrn4bVqwZgR68DwLFwyfF4AXu3C0j7HXv0zaj8AHeiPbkTzE3Adcpv/M/TjLl6lEttNw58K VH03PxjesvMTr8nT/w79WNahdylkDcmwtFrccviRVkIO8jQY4UibZa0FJeEZ8GEi6/wpsgCv NSAMbV4+sTWU+GbljC11MfgeCEbzAWJFOrU0ICssua33x9h3Zi1XYVw8QZgzMp6I89cZ9Z/O 7JW54Y1I1mf4szV+ZQFe0BScy4BijmWhTXKl+fJlzhCeUhN2/SrYX0pJE4/vujdpBN7JZaou WDbHpo8UoJP27+A8yH25NGtjrXRn+mYDjrwsZCo5djvLnxQ6fqLD2DRFgin9DImYRbPuTrH9 KIfL5GCf7qKmXjXaxT2RflZpVUIX4CFM0Z0+xLH26mk4buEMnHp+bbePHcKP7GCjA/QF7yBX MFQXz2LMVE5Ua7R2/gjHHqKjTQU3262ag1PLnR/uAVxoRIHJZLqBIphVOw4dzOLyZDvKwwdE 53O6jmjau/uGmz8Q/znidUEysYKnwQzKTrUntMqwNPGVjza6w/t9KWfn0XwGGKPQZlT8TdEB dWolN+/a7fFe3X+QkST/acdk6KhXoao3yHC6oGkqqY/MH/Z9cTFZA9QpF8Eg3NCj14kQtns3 14dQcBX0PTfwme0JmNvdgxPqX/f8M5qBq3KcRUwEivy3m0lIUKfD8neBKAFeSQmh0jQjJIgE YZyd5vvJOw3RC1KWU+h+wkNkZrc2r/OsMfMC21IKNJh7vsZAZ8CUCNiDDysWBoRkPas2MPm2 fmMSqYPcvuP2MYkHVZ3qH2mWkELVm1d15sa3x8rI12HXnHvHE2yuOQeq+vyQKqGys/6/BYPz ffbTQIJARyg9ixyR6OgT6HUW4r35M0I4Xmff4eWqCW3nOmM4uTk64aW/dS4ZZ+Ldjr29V7Gd 63akuQLDniDfku1BHQrnE5ODNsoH1hlf/zwhXq4Cy523E4aMCia2hOVvUeI9uG6XLjSOvN2J Jljcgtte/1K37vcLe9uNbqRi8GLgmWrX+9Tukup5wRtaUutKFrF52eVTfTznlI0Bg3Mc+crj JSfI1rpLTafoN/dc0bfCxUukAkk9mCN0MnuA37CO1WRyBls1bLe9eSp7bYo7smBUOM4BbqMV 6E6itH4rPLWTCA2bNyMdN9HU1GLEwnrHJs8+OJe9eOVEGkd+Rf8EG7NXH4erlHU6SBEagRqB E/49zgpZ7jSwPonATL+T18KeZS9mziR8W4CgeFA/RJ/Ny3Ik7kuNrd3OejyDPsDSKmYEEZj5 BffUMebs5fmiAv5bdHoBSaW+jyuAY5iFNQ7jFsi0711oWn6GndG1taMQexuOQjYRBDdn6Sjc rE9uCE1HPypDhdsKOzZ3ttQg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,251,1613433600"; d="scan'208,217";a="701294318" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Apr 2021 08:31:02 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 13Q8V2nK008759 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 26 Apr 2021 08:31:02 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 26 Apr 2021 03:31:02 -0500 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 26 Apr 2021 03:31:01 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 26 Apr 2021 03:31:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N3V19xEPpdcwykrFwtCY4EpkBXccFfmSbNGBjPVOQk1AtqJqR2UoJ1yNcMbNbjr9sbLZXcX70TiYyFzZJCCfZUEMShBa5JtE4fGllzaPeQvU5Gae8bQKWPEXz90ZNnO2bKS2qqW4Dzm0woGId1dPVWbWmSZki/6Di6vQCc/t/9Zpp0qAUvSPCdrH3+nXPpwgEqDRM2paifqBjdjt1EWl1DQWk95C4ldfZJ4UHWPjcpkj83Dk9l1jSBJe84At3KZNnFNLbUj9lqQFEzcteDd57CLi7nsSlBps9MrsI0mAJrAVsgGPJV8mDevlCh3HAPPBRIoSGbpzQaTSxHoEuXcyGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TNrOrhNpEWfm0xV1GIBz59SnnpFiet/7bKg2aU2bd4w=; b=SLvs4m8uUW1voXd8OPgVfAzq7yNop33M9T3Oxiq6vzjX5pYhQi2AGZM3gUIg775Q3Tr7QqgOA+ZqEcpSdyBkR1020VAok7dPxjVF4o/w1AHbhyNlo3HvKZLaziYcmEdUp401zP9fj3bS2XPiET8/eKdvtpjDLH+ybbNKUVfXe2EHsDArRSxLHMYZhAQQx32hYyPRAy64KPVQgz9AFFMKodTQCRco87YWWyZggBNy1zos07Q5fa3Yj1EnppASSWbUGHmOKew2LXFQB8UQ9xvkjncNNsUplBms/dZQkwS80QiMwrfpjusB/rEsw0eclgjaZizi1jC2OMXU5eFuCj1GIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TNrOrhNpEWfm0xV1GIBz59SnnpFiet/7bKg2aU2bd4w=; b=aJVqmkHIcOKgfbDbDj5gmuNAKelgLmK7UspuCEMzfJJh/Ce2hyz7Vak6eeZi5odDLH6t+L9enFtkiG98kC2w6DnLo97E4p24qQR89Ij2J6ShWC9YJ2FtPNqSdfrdR/iwfEEhyNCLz56bXKAvpHF0ebcoT7eBq++swLB7+ohPcus= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3012.namprd11.prod.outlook.com (2603:10b6:208:79::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Mon, 26 Apr 2021 08:31:00 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::217d:4810:6cea:ef72]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::217d:4810:6cea:ef72%6]) with mapi id 15.20.4065.027; Mon, 26 Apr 2021 08:31:00 +0000 From: "Rob Wilton (rwilton)" To: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "'netmod@ietf.org'" Thread-Topic: Network Modeling (Concluded WG) ??? Thread-Index: Adc6ZKKKzeml8tK0TAm2GdvjNVXh4wAEVWEQ Date: Mon, 26 Apr 2021 08:31:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 372ad11f-8595-42f3-0893-08d9088d9f36 x-ms-traffictypediagnostic: BL0PR11MB3012: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wbSxX7O9pdmWLDFWAQL8bFQ2znpFOItZm6wZ+bxbH397xsNsKTBMJAl06Ab224x+xRmMtLxkNrC2Bn0J/Rpo6JqPV8G95KRDVnbD0/WIeB2cA1l85gpuZFG3kooJ9s9O1WeWiuKZMgEZBLmrho+dezCbT+U/RNrQUgbIZYJmvwBIUmZ2NBSjB6D52+iFPoHuiYvRn0gnjtUWDKsDT8q7fcF19av9qkxHBSfmKYK/pENMwegf+rikL1qFPc9eSTjgog1UypfLtgMsOVbHGAra6Lj0NPzj78WvAKwKzvEBsXcX2XWLJhFNRcOncwiX3QikqXdtbIk/IUHWxxaiHUUB0WopGVeWCCiSAvU/mrnC6olVoFtJegVxTjvaUKGbKAQOVXqOTYH3Dpa0ygEFwebGWhV5WP5BWyiOWE7VDbFjBMdl1ijKpSRIj8bydJ99l6jdIvwH8Aq8BLC3kOE3NaoKwAq7Gje94uA4DL7dudacEHfQRSY21R9Vcnkv8NvjmcEZqHypPsBGV9CWBHTyn0z+r9JeXMoXVKCZelJo/ORSKfQL+qsUZQPVeXsFgDNTFYcZnD1mv5MqD3OjU+LWEG1rIwgw93AA0dQFttAnzqtdIDDAQpZ0QI+ZCIzHoYPEfxGsBposbInAfTFBd/h/Wv8ua9hYPLpnOSlpcHg6ZGeV9TSD/54qN9neXojhzIXkJaqngaTFhG5Zd+lOXofDS6EvXcQ7BeyezNcm62MwL9etsHE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(396003)(346002)(376002)(366004)(86362001)(8936002)(66574015)(8676002)(2906002)(66946007)(478600001)(9326002)(55016002)(9686003)(33656002)(186003)(83380400001)(966005)(7696005)(71200400001)(38100700002)(6506007)(26005)(53546011)(4744005)(110136005)(166002)(122000001)(5660300002)(76116006)(52536014)(316002)(66446008)(66556008)(64756008)(66476007)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?c5344O0+Bi2A0bIUna9DPmI6z1TcR49HshEd/yjfB5cmKf5OqzCihCZlP8?= =?iso-8859-1?Q?dzaQPToPCfUF8PXJFpYTbW/sa/N+WMmpp58XTZqUJhCk5K5K8zLI4DsHa3?= =?iso-8859-1?Q?O/P4yYE847fSP/4C5xnTdEXu288qBJe1FnuUL8EwiqY+PF/5KMy4EHuAvi?= =?iso-8859-1?Q?add5NDnQsy3JEJl0KArzWkRcK8/BgPaTllmBsGqGLAQxVAQhu7tfGimxGK?= =?iso-8859-1?Q?76PUBNiXQhclwNi0m72W/6w+d0KCcWJ+60FjS43VosrqSNZ2riGEEYYbEU?= =?iso-8859-1?Q?HFr8kAWUGY7CDg4ML0tAxdXBcXt8Du19sfJcZWzKzE72xSmcgGfqX4ywja?= =?iso-8859-1?Q?Lj6xIJZnauAP6Ktp9vwhP4ytT/NHPyWZaBrulElLqj6w7gkrpkBdq+Pl+a?= =?iso-8859-1?Q?wlGb47+phs8mlV6NmVjPBSkoH3EpHBinYCsQIZF2KawcowIsgVz6zcHH2c?= =?iso-8859-1?Q?bvUevcmjkrZOGYu1J5A+9RFJICOXvgi7vjuGjOydmVXO1pX/rgazRcMjua?= =?iso-8859-1?Q?kAlk2eDCgXKC9Rw2iYXczeBdK5/f01lJdcDAj4UxQ6566mW8/RzYPaZeAF?= =?iso-8859-1?Q?lDYhbCVJYV26HMk3arI+QnQuIseBREmYOGxFm1kNGdmGcK40PONT6n8gn2?= =?iso-8859-1?Q?PRf4YmaySxjkOi7mAoVybB9/2M6YYU3hnbPQr7IDRVI2+3zsMpK9JJzSwd?= =?iso-8859-1?Q?4sIDK8ei2ZLF0ARwXEhlJCgGnoqHYsaTWv2BRMWlDd/JbYbAwmQJ3A2NbS?= =?iso-8859-1?Q?t4TUyo9IRIH7ZW3XTuLPxoRC6Pt53Q70zZIlVTTmmsayndyy8Ul5NiznId?= =?iso-8859-1?Q?gHo1BD9rKGpVdGNyZLCq5IKNr5oqiWO+Ezf9pzn1p/R1E5wS5XezFQcX9d?= =?iso-8859-1?Q?UJkLouwQijqevIRUg+o0g/UdWKxYZ1Km0g17tUIhUwBdSrhc3LJguIZZCo?= =?iso-8859-1?Q?zOPiGeEBycuxCmF/ddm76ABrA5qLRoN2OwjAapngB+NyrvC5k+APE0bllO?= =?iso-8859-1?Q?jL352vcn3No3rCGgqQ8jkNjODg43nQCz1iz+kHw3d3BieRLWupXW4/A/Cc?= =?iso-8859-1?Q?8vnEBmKjNE0VoHbnXei7gnET9QF3ot2CMfHlIGQTGYU2qUZTA+7S9kUWgp?= =?iso-8859-1?Q?TUGsnYSeF/yUVZGKQettkDFP2eUe79TKliCf0PFr7XEY9JKNQqM8FjlSUL?= =?iso-8859-1?Q?bVYcMr5nFCiujb+f5oJo7bQV+/ajpk9/6AeZojs1ct0vLO9rVNJ1LMw1hV?= =?iso-8859-1?Q?q8b7vazyKNLGLTw0m1ax9L9DO0SpWOLFL5UDp/1dpVyxcey2TCRkTkJ0Zf?= =?iso-8859-1?Q?Gbr52ktXKi+lLTTcKfEU0DCfVuq9TW2fR8Y/Vd47GfCEwDsTSV55HDu0lk?= =?iso-8859-1?Q?Ui2litDIAH?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43665D44B9707228B93C2D14B5429MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 372ad11f-8595-42f3-0893-08d9088d9f36 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 08:31:00.2846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bhA23iTbsgC7MmrYrUhquLKTAb6knPW3Tr6bWtOcG19n6sQsP9jo64gakqv6JLx+Q19UxGLTpFpXUxtDukbvvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3012 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netmod] Network Modeling (Concluded WG) ??? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 08:31:08 -0000 --_000_MN2PR11MB43665D44B9707228B93C2D14B5429MN2PR11MB4366namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Balazs, I think that you can rest easy - Netmod has not been closed. The link below looks fine now for me. Are you still seeing the same page? I presume that it was just a transient bug on the tools.ietf.org pages, and= I would generally trust the datatracker pages over the "tools" ones. Regards, Rob From: netmod On Behalf Of Bal=E1zs Lengyel Sent: 26 April 2021 07:47 To: 'netmod@ietf.org' Subject: [netmod] Network Modeling (Concluded WG) ??? Hello, This is what I found today on the https://tools.ietf.org/wg/netmod/ Netmod Status Pages Network Modeling (Concluded WG) What? Why ? Regards Balazs -- Balazs Lengyel Senior Specialist E= ricsson Hungary Ltd. Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --_000_MN2PR11MB43665D44B9707228B93C2D14B5429MN2PR11MB4366namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Balazs= ,

&nbs= p;

I think t= hat you can rest easy – Netmod has not been closed.=

&nbs= p;

The link = below looks fine now for me.  Are you still seeing the same page?=

&nbs= p;

I presume= that it was just a transient bug on the tools.ietf.org pages, and I would = generally trust the datatracker pages over the “tools” ones.

&nbs= p;

Regards,<= o:p>

Rob<= /o:p>

&nbs= p;

&nbs= p;

From: netmod <netmod-bounces@ietf.org> On Behalf Of Bal=E1zs Lengyel
Sent: 26 April 2021 07:47
To: 'netmod@ietf.org' <netmod@ietf.org>
Subject: [netmod] Network Modeling (Concluded WG) ???

 

Hello,

This is what I found today on t= he https://tools.ietf.org/wg/netmod/

 

Netmod Status P= ages

Network Modeling (Concluded = WG)

 =

What? Why ?

Regards Balazs

 

--

Balazs Lengyel   = ;            &n= bsp;    Senior Specialist      = ;            &n= bsp;    Ericsson Hungary Ltd.

Mobile: +36-70-330-7909 &n= bsp;            emai= l: Balazs.Lengyel@ericsson.com<= /a>

 

--_000_MN2PR11MB43665D44B9707228B93C2D14B5429MN2PR11MB4366namp_-- From nobody Mon Apr 26 07:12:45 2021 Return-Path: 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 492C73A2123 for ; Mon, 26 Apr 2021 07:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.294 X-Spam-Level: X-Spam-Status: No, score=0.294 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.391, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 wAsANrmfI9SY for ; Mon, 26 Apr 2021 07:12:39 -0700 (PDT) Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.41]) (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 C33133A211E for ; Mon, 26 Apr 2021 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1619446356; bh=BgmDxIp/YCflX/Ma5WPvLAtLUhdNZGkES+bJZq+FHB0=; h=Date:Subject:From:To:References:From:Subject:Reply-To; b=FqkhAj0RWS6dMKYg639sFkqfR4I0aaW/wRbQDpTJLmPBt0GcrZKdEeB8L1rWiolreMD12mOprHqLbT4AsO22RUoojpLUg6GdXODtagVOGTBnpVJoRJOYJMgxckuSZzUN8hNUKl1mrBxlaSVxNmou3R4PHT0sVky+llYgxJKehbwKVDx2+SqbKHTrL6e8BgAhD051DD38jEgu+jATNZC1wrUojsbkzTaZsKF9dVHfjH7lDbx8Byhs1PhZyvnquCijxQc8AgX/jWnUUDKX1TjJv3k4fwWVXCfQ0puUH9gmVFp03tiTA8vMOJdoRpAAcrCLSGM/O3elgEa0PVd+sUhWTA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1619446356; bh=Brj1HRzzzwSbQvSV3vq2J1qHy0Y6YIEBzL9SqEXrp3I=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=TIjQwEP8nJkEmEJuqQqqxBRy4txUehXgFpYxjzt8X3Jmc1Mi4WitLGEqSwQKJfHYx3tMKGIyCKYEq5Sp4Vc4NyFY41GQCkEDMRoQkd9n0SixAXup2Mxl67Kd3uh66QoOP1IDBtduMUVjKrJKZx6LAxUFyEJ4uD+Dilk3wuCFIDJkaWbN88jwcXMLyhlQ0NkyD1jcGDchKbn7Siq6ZqpEzrUAmGfJQGD0+uQvGAfJjnfcdFpZTftux93mm4VV5wstjnZILolxebduhS/HGsGRz5iJMEMHWyjYjA2vXyhI3YfIRyY9aR8JCfkKN6WtviPPcd50Q3LmhhDfXZwPWOvsJA== X-YMail-OSG: 7vqaNyoVM1lIaPoeXKJpAZCMMDZNIAFWVmdUbDPR6YRhpfL8Bh9i9g5BEHl_Be1 XCb320wGEbz3853Sp275lLfpUThm9q4UouTLEIHjMV3yoHmUwlmhT1Gcq4A3Qwp5dN2S_q7xdcep i5YS_Ev139vJ1qxyVaLU.CsUDy_Gt4fHhqMIo5rWIkYP88m28BXSPKSBxXtJbpcLa69RssNt.RD4 Z12zZ9axMNHraeW5JSmlccYw.T30xnzoymF7kOiWIZf6OkP0H05EasQZdgG7QKqNRxJ3t.gpPe6M tMrLM_pM7v8j3dk7Gj_rGpMOZtcOi.I8DagbpDZ_iPRCnq72y.JHBDZ844YdsbWhMqyWXT80yH0s nM70UgbPTJIZo.OOWPRhpiSEi_ZZQsP.32u5tFkAQ4VJrxe6pdm9fVgPkr.gnq.ZfLoflkecwDEX TJEU3Z2w4zK_WUyRYAdhZPn.MzwHq2.mYk9H4aMIKIViS7urjyskqWgpYsPw_niOmG_s1iquvi6Q TfCDHnLSvI.TkfCNyEpg6XcjLo8dTyezCvjXI98CuUNdEH9roYgT.Azq0JCs5UFu2WsHJqsLvUo5 Z2WJuQFsEvUhLpBd6iJqEmtDbZP1I.hB.fLDyn9uvqkjNawqJMDn1KU6eyceAYK5LNz3SzwAXHdM v9QU8XEqPygs.jX17dHdCBcPsa5djjy132Cw7efoNy8UOrP0VSrgFS6ucExIebxWNw5UHc9gPtAf nL8zKgJ_kBgua2JmcGTzZ85mejdOBURlL9ScMkKfsYvtkTC36AY.6b.NI68Y_A7K0fB2kRJt.bFh 36s6UCOSnNg8mN6lne0fAWnh3sJlhgywDVrleQWjQdjxoT7eW_6909DUohwWeOx8Z4YxmnfEBsk2 EIg_DSL.aaJo4Uhcz.BdSKXT1Cq0X4vu8rwNHTZdJ2DAPCFqAE669YyZtef52gPFl3nN3DIJzxey sLdVd8ts.lCdIpNll3DDmx5Uegup_aHThA.MHSyx5FaKGxb8O9MeZGeR0zcw0IiQKNaQtgTBn5_s fdWZNCUaa8KlJvWKQTsEovcdm_CZj5l29Mr2sTcSZkOA8dpLF1VwoMinWR5M6TwiNHtoacD_7U8N oBiEKPOXE_l4EoOhxgcboDiE.UVag9BJFrhXy7Cb0H.EZ5MA.zl49tIzhYzD7dTLQQR_2W_Y7cV4 hazmXlMxa6qX1QSQ1bxfVA6FZ3JM.EnSMel8xiw8PJkVFUUOmL4oFQiNsNFpD.Vxge1mx4galpxg nCvEVpHf2QvgKqHHqpdRvIMKWV0tuQrMUmNqBlIHungCkKICYjPc0qpAzOx1kVYR7x5c2HTaNIkB 6Z05FI3LxOn1KBoKi.5jCPbKPI0tgQiXZCvHCy9l_JlQ_RkrGg6OQB9DlpwQ21dXXam_NjDV1gx6 r_OIRD3K7SBSeAd0M.4Hq3aDCnN51wANDZG.HXYvr_BiT9WU3qNQnrJ0zh4qC1GPGGPvYYHw02aT L7yarOISgZorDH5kh0EpmlhFfMQyW.09i5WiJRfVXt6e8NE6fw8SOUNSeQy_Jp81U.S9Dl_A6p4m tQwuNz9FGUEAbxn9vd0KL0KZJUjhmHHh7702Oje4a0boGp8t.Z_JMGTNloFmOPCI_Ofopr2KpIB9 CZJbf.MD9cgZ41YqyQuEkFuXrdE2dBlMLX.g8Q6BTOiXVBeIo9o5YQVznjRXr0QCbo04VZgMXIv4 ocu1KdtiuQz0_2cTrjx3hOy5bXoV4sa.6PzjzSStLFVU_QvJjnYVIPjTCvYH95RzOqHd.KpiB2eb lAXh38n7n5_Orboc_4bFpM06Z_Bb2hUN5Bn1L1wyjusCck5J1Jz8xP.WO9Ydg0a0wlhW6uCq.K46 QDZ21Fk8UITYqTEv57eDxt.r78AKugSFpVLKHbBmGDOiVGHjjjBlDWTXWFNHcA8BQlUnO6cgTvyN 3QWJ3B54K87wu02zE_pYB2Pnrcty_KjETLA0yLY1L7AJ7yloux_JBkln0IzwKsT3oPbMq_CpuufB zniWrsw4krXm1BFwVf39VqRDhZS1GrSK500EoqrfcwGkWFPWx8Yz4W0iFOXLEf8TibcTgYI1WSFg zNvo25oycmkaujUTFhZXNsgwnixSqkbXinZgd2p6TbEk7FbDazokW_i64PvgcjxJeWwmkkYBidcU nKkSTwjr8npA3CVw.EJFEZ7Pf5vyHsma8jLJUtRGauWqdjaI4HUFzCVba9qD7IAicS.vGOr2eMaP MVL_6ICyddt5niX0WYjNlCF7FpVeQwlAXu5Yt3ibG_0V8AObsS4_31MZEjSFEINxrE33XQ98SADk yZG3lhL0gMoE1LasyvF3Ho7wt6J0XpmxsQ9w0StU7FayM5LbG_CYN22OWpRzvsLIeGaLrIzAChBJ SGBC8MfI5402TY9m7r_H7NQ7TIME3y97Xd7EJnk3TjyIxrAk12HWLm3r9OQzYHsWGs7PNrv.Noul E9wEKnrqk3KfP0Ci3umnoBl7dAUXttV3qUfJfilMZK0V3jp0Z.a3F3L.GOYt_1.0fvFF2ljTUHA3 lfyBJ9NEWJkULU6m0sA2uGijHlDLUmWHjqw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Mon, 26 Apr 2021 14:12:36 +0000 Received: by kubenode578.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12e1d93caa68b4863e3dd788de03d61e; Mon, 26 Apr 2021 14:12:32 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Mon, 26 Apr 2021 10:12:28 -0400 From: Reshad Rahman To: "Rob Wilton (rwilton)" , =?UTF-8?B?QmFsw6F6cw==?= Lengyel , "'netmod@ietf.org'" Message-ID: Thread-Topic: [netmod] Network Modeling (Concluded WG) ??? Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3702276752_1508399407" References: X-Mailer: WebService/1.1.18138 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/16) Archived-At: Subject: Re: [netmod] Network Modeling (Concluded WG) ??? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 14:12:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3702276752_1508399407 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable And there I was thinking I=E2=80=99d have more spare time=E2=80=A6. =20 From: netmod on behalf of "Rob Wilton (rwilton)" = Date: Monday, April 26, 2021 at 4:31 AM To: Bal=C3=A1zs Lengyel , "'netmo= d@ietf.org'" Subject: Re: [netmod] Network Modeling (Concluded WG) ??? =20 Hi Balazs, =20 I think that you can rest easy =E2=80=93 Netmod has not been closed. =20 The link below looks fine now for me. Are you still seeing the same page? =20 I presume that it was just a transient bug on the tools.ietf.org pages, and= I would generally trust the datatracker pages over the =E2=80=9Ctools=E2=80=9D ones. =20 Regards, Rob =20 =20 From: netmod On Behalf Of Bal=C3=A1zs Lengyel Sent: 26 April 2021 07:47 To: 'netmod@ietf.org' Subject: [netmod] Network Modeling (Concluded WG) ??? =20 Hello, This is what I found today on the https://tools.ietf.org/wg/netmod/ =20 Netmod Status Pages=20 Network Modeling (Concluded WG) =20 What? Why ? Regards Balazs =20 --=20 Balazs Lengyel Senior Specialist E= ricsson Hungary Ltd.=20 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com =20 _______________________________________________ netmod mailing list netmod@= ietf.org https://www.ietf.org/mailman/listinfo/netmod=20 --B_3702276752_1508399407 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

And there I was = thinking I=E2=80=99d have more spare time=E2=80=A6.

 

From: net= mod <netmod-bounces@ietf.org> on behalf of "Rob Wilton (rwilton)&= quot; <rwilton=3D40cisco.com@dmarc.ietf.org>
Date: Monday, Apr= il 26, 2021 at 4:31 AM
To: Bal=C3=A1zs Lengyel <balazs.lengyel=3D40er= icsson.com@dmarc.ietf.org>, "'netmod@ietf.org'" <netmod@ietf= .org>
Subject: Re: [netmod] Network Modeling (Concluded WG) ???=

 

Hi Balazs,

 

I think that you can rest easy =E2=80=93 Netmod has = not been closed.

 

The link below looks fine now for me.  Are you still seei= ng the same page?

 

I presume that it was just a transient bug on the tools.ietf.= org pages, and I would generally trust the datatracker pages over the =E2=80=9Ctoo= ls=E2=80=9D ones.

 

Regards,

Rob

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Bal=C3=A1zs = Lengyel
Sent: 26 April 2021 07:47
To: 'netmod@ietf.org' = <netmod@ietf.org>
Subject: [netmod] Network Modeling (Conclu= ded WG) ???

 <= /o:p>

Hello,

This is what I found today on the https://tools.ietf.org/wg/netmod/

 

Netmod Status Pages

Network Modeli= ng (Concluded WG)

 

What? Why ?

Regards Balazs

 

-- <= o:p>

Balazs Lengyel  =             &nbs= p;     Senior Specialist     &n= bsp;            =      Ericsson Hungary Ltd.

Mobile: +36-70-330-7909    =           email: Balazs.Lengyel@ericsson.com

 

_______________________________________________ netmod = mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

--B_3702276752_1508399407-- From nobody Mon Apr 26 15:48:07 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 449293A33A4; Mon, 26 Apr 2021 15:48:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-netmod-geo-location.all@ietf.org, last-call@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161947728622.5344.4005647920914159054@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Mon, 26 Apr 2021 15:48:06 -0700 Archived-At: Subject: [netmod] Genart last call review of draft-ietf-netmod-geo-location-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 22:48:06 -0000 Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netmod-geo-location-?? Reviewer: Linda Dunbar Review Date: 2021-04-26 IETF LC End Date: 2021-05-03 IESG Telechat date: Not scheduled for a telechat Summary: This draft describes the Geo-location object for YANG. The document is written very clear. I don't see any problem., except for one question: The "pattern ’[ -@\[-\^_-~]*’" is used by leaf astronomical-body and container geodetic-system. Why not creating a Constant for the pattern to be referenced? in case you want to make changes to the pattern. Major issues: None. Minor issues: None. Nits/editorial comments: None. Best Regards, Linda Dunbar From nobody Tue Apr 27 07:04:59 2021 Return-Path: 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 DC45B3A09D8 for ; Tue, 27 Apr 2021 07:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 qNg8rkeipRcJ for ; Tue, 27 Apr 2021 07:04:53 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2122.outbound.protection.outlook.com [40.107.236.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7223A09D7 for ; Tue, 27 Apr 2021 07:04:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gm/gsX7trwn+Q/6AJN/e2g9L4oVpimF7XL0NbbutB3SgLzyo7mnzupMeTbHBfVrlhwvIkgnyODF3nxyDn7Sf2nT0mdZAsl30yPTeQyd30YRvJRbAvvQ+5ajAXsnL+52X7NXMBAhH0IIpLKsyH0jJtaoXBrsT9rNRs7WvAssFp6Mm0DwcyesHwHVGwTG0iBK1WsEOx4cZi0hF9KIPmqI9AA8caEdFqGYg64wlqHx86M6rRlssiRHCyyCehEarWJ1kcUoTvi5ZE8qNq5sc78CwCSVM+L4e2jez1xB6k9XKgaH0uhqe5r/CuHNszBYvcP8Xvp4Kh5fs3MjV1RWagWO+Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=akvu20if+ELCKGGDWKHuMFEde1mxb/EaeFKyaSowuWo=; b=kPjSogGNxMGDfbIX6ihxzQkCRiCwlLDbZhAGYkunyZ9O7QHErMjhNYdXKkJv4/gmQsiWDaDdzAbqtKBC6os2IYE1SnMUZjteUWalb14IU5MFenSO+QXPOZGujVXL/30S0ZNZFpS388rMine7P6XWKLENeAv48L14i/+xaMYL0YiNlGB3PooJRUv6MKXEJ7gIAzcTMs+GwOMag8X/8nZ4UHOZkpx1hrOYL/1FF3YwyBeM4rEj4YrhSbU5RLUm5ujsHihrwfFym+c7yCZ/qua6c6ftbPX6keaiI3SznxDj5RMHw1gHqpklEOCEhtW3GUaIf224E4rIw/pPO9dk+Ssh+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=akvu20if+ELCKGGDWKHuMFEde1mxb/EaeFKyaSowuWo=; b=gdCh9jxVBI+BwR/tGcVSXI3lqUgHApK95rQcP1hYMk2wiLK2TvY6jqg8zcCK9p05LbXolVd8neh/C6Cp1UDp2/iOcrRmiiOnIDspUhHjXNNs48BQ/J/kJskVaDG1yBvCB0d0QtyHJtR4eg2NUYN9eQmr/kQFM93Tlerxn4K0PI0= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6267.namprd08.prod.outlook.com (2603:10b6:5:1ec::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Tue, 27 Apr 2021 14:04:51 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4065.027; Tue, 27 Apr 2021 14:04:51 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-04-27 Thread-Index: Adc7bjYiO+6Q3DTCSUO8sHh2YaXAwQ== Date: Tue, 27 Apr 2021 14:04:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [23.233.24.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 127ea4c8-e6a2-44dd-ce92-08d909856ce0 x-ms-traffictypediagnostic: DM6PR08MB6267: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q7hstkWo2WOih9yFHUXv8rzo7N7tnQwEyghJ/1kWYdrpuoc/xbeyFx/uKRMurz2fLjIyLaMnvKklEN3op93moMMx6fOr7CAn7wOQM867lIazqvr16aglGNacNjF7D/M0Mzp77fXJrVwiRFhTRxFM2eMjVtn0gSqaMwyO6ItSOVxjKV70qXTfiS4R52smon6f1JkzkKzlqnrdxYLQychTHkgsQTch6E5i3sSKbmvVSFGxDpK1bwM9fKiVWQn/9xyPWn2z30/QBmHQkbvdoYlL+qrnbIToPlfUGMbGnu2A34UCMpGQk6YWy2W3mfDPqyVVQiKk9WHhjCPCKALAhpB8bYEsItxQQVQqTGzpkmUYPTbRcFjU4pnze9Z9Ov8l/rGw7YtINlDWXaMAnUvqdQT5knMC/Le6pEYMWruwF9UXXWtV96RBAaJQWdYOT4KVfCe1N39LgXPka4gCB3SEQ2+GUc0zIqgyf7p1qbaTEXxFoWFZa8rm10OKx+hFviwyZzLeQ+foM8Sc0DzAoVQXvWgncnQGbU4t3dM9p+p05wYiyTDZjwhHifStlH4D3bWOjRTtEUFuooDV9Mf5298NxVDtc3sptXTXm1jKbPIrdtRt1jfm41fBmHuL44/tslGzuBOHxycI+hw3NTqt0dP/79yMgsOM3xuy2t0//0yLTYD8bOh9kNp9ZZYbVAYxPM9ZAYnE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(376002)(39860400002)(396003)(122000001)(8676002)(83380400001)(66476007)(66556008)(71200400001)(26005)(38100700002)(52536014)(7696005)(478600001)(66946007)(316002)(186003)(5660300002)(16799955002)(33656002)(86362001)(8936002)(966005)(55016002)(76116006)(9686003)(2906002)(6916009)(6506007)(66446008)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?nut9exiXy0pnzzOlSIV/lCtheeLJDTe9ewLF3MGIwY5fFPLvJzezPkSJMY59?= =?us-ascii?Q?Bab5h1ZqNfrxKkRKDyeQOqKTRXusjSDqLsI6QMKoz/F+VZn7KMjrvKHF2yqy?= =?us-ascii?Q?+HlKA/1LQLFxrtj4KbxQgKH3A+sST1I0s6w3iqxDSj9PMCqvP+MB/bi2yj8n?= =?us-ascii?Q?N/MwjhCQGCSWhZYnZMxe+VTN8IxMF9UXbY4lJfyfH4X7puRM95fMxNL3omtO?= =?us-ascii?Q?/o9aASfg+ib/NYzGGYI6yG/pvYkGjUN4HywqpL5Q232k6u7MJm+XJN7eh5Xq?= =?us-ascii?Q?km6PMLUBFJMUVCm2FvvaIyiaCBJkSWSjiLv7T3qc8YWOtH3sSNnvokjX384W?= =?us-ascii?Q?JU+I7Rhay9fD/iJjtcGYmKV2cGUwtBT0UJKZ0h+XlV143mVkgZm8dZUKsMaA?= =?us-ascii?Q?yoEPd6E1JtEjefoOR2K6iZoozUsDPQZOZ7KFOGhAQyy8A5VDCsBOn/GClPa5?= =?us-ascii?Q?QeAreLJZls9GH2paf6+OErDnWc6UuktmJxe/9XZNGsnJ8xIobwYMhvl7woTx?= =?us-ascii?Q?xwjOjh05zU3UYuzyqVL3z2C3MBDPp6QWhrpzLumYC8torToNt5glOkX65mm6?= =?us-ascii?Q?DxESgWmUse5B6wFFfLiTiQba0sKzGNSZX//QxtvGqzhp6Yu/gtHwsRjmwAWT?= =?us-ascii?Q?LeewhTQrC3IERhzn0iD3zI0isO/o2387H5GuRlsO/SnfbjOx2TFGJMFpKMRi?= =?us-ascii?Q?rCzx3U3c7q2k5hGUyrZa+bhPPi3wYLthrPjJno3+Aw3adStd12S15oHvPSEv?= =?us-ascii?Q?Ts1ihUSoF7hw/PMTsB5bIF1XNWzOz6UxQK10JfEU7ohk1m3Hx25cqzl+OMsx?= =?us-ascii?Q?iW8WI/LvvwlQn9o1ewIA3BfZybLv1Vnm2Dq1SRJvdI/ZYtrvZbLjts6owmft?= =?us-ascii?Q?Nw8kJZBsEq+gGHIz5DtGu40gfrfIEyY2NE09HfAbOrn7Y0uyojDd8cHMI/WW?= =?us-ascii?Q?uhUW67O+rj/t17Qa+AkZk6ZubrEooMqFZNrAywCsxpkkcR6dkNOCxUL/x0DO?= =?us-ascii?Q?pncAwmjJ/Yq3z2zHEUXPhACNdObkUQO5zZnAXmFLKfV1f7K5sj+kijrtVh7y?= =?us-ascii?Q?74P1WqbL6AXbH9JblSUnBM4mVOCFu0iTtfkSv6OHTAdRdSHIjPo6+SH1n1dI?= =?us-ascii?Q?wiqcx1Xqi5Cy41Yd5A8Mqq9xJc5rKK/nz2Iji/+mvJoLe9//TVN2I4afyjG/?= =?us-ascii?Q?orwAOWbk2WXVlH0aIKsbt5/YwYqmdW/CLmKmesRykldZPGZGSqV4HlFP2lha?= =?us-ascii?Q?xU9OnFQvI//R+skpi0EMLc/r+XuBNuSB6BdbvcCMvcKIZ8r5qU/cdis5CfnQ?= =?us-ascii?Q?MKhfi+Hihxgry0danWdztApo?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084F0BC5304A1540C2AABF89B419DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 127ea4c8-e6a2-44dd-ce92-08d909856ce0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2021 14:04:51.0009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: X3mlW/INSCaVxyC+6+qV7eUDuQauGJVDZYQSSjORh3sCMWAsneZghsN5Q5vbfz/zzrLG1MjSEDmefpDIeVXVmA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6267 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-27 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 14:04:58 -0000 --_000_DM6PR08MB5084F0BC5304A1540C2AABF89B419DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-04-27 We continued reviewing Reshad's Module Versioning slides from IETF110 to ca= pture feedback to roll into the draft. Comparison draft should do the following (need to raise Github issues) - have switches for how/if to consider extension statement changes - output should differentiate between changes in config vs changes in state= (separate output reports for config and for state) Issue for tooling/comparison draft: - consider an extension that defines whether changes to an extension (or ad= ding/removing) is BC or NBC (Github issue #92) Extensions (Github issue #12): - differentiate between the *declaration/definition* (i.e. the YANG 'extens= ion' statement keyword) of an extension, and the *use* of the extension - go with 7950 rules for the *declaration/definition* (i.e. you can add a n= ew extension definition and that is BC, but removing or changing one is NBC= ) - For *usage* of an extension: a) everything is BC unless specified otherwise ? b) using the extension in a newly added schema node is BC, = anything else is NBC (e.g. newly adding/using the extension in a pre-existi= ng schema node is NBC, or removing a use of an extension is NBC) c) usage changes are indeterminate (i.e. may break compatib= ility) unless otherwise specified by the specification of the extension Reshad's IETF110 slides: Finished slide 7, start with slide 8 next meeting Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB5084F0BC5304A1540C2AABF89B419DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-04-27

 

We continued reviewing Reshad's Module Versioning sl= ides from IETF110 to capture feedback to roll into the draft.

 

Comparison draft should do the following (need to ra= ise Github issues)

- have switches for how/if to consider extension sta= tement changes

- output should differentiate between changes in con= fig vs changes in state (separate output reports for config and for state)<= o:p>

 

Issue for tooling/comparison draft:

- consider an extension that defines whether changes= to an extension (or adding/removing) is BC or NBC (Github issue #92)<= /o:p>

 

Extensions (Github issue #12):

- differentiate between the *declaration/definition*= (i.e. the YANG 'extension' statement keyword) of an extension, and the *us= e* of the extension

- go with 7950 rules for the *declaration/definition= * (i.e. you can add a new extension definition and that is BC, but removing= or changing one is NBC)

- For *usage* of an extension: 

     a) everything is BC un= less specified otherwise ?

        &nbs= p;       b) using the extension in a newly ad= ded schema node is BC, anything else is NBC (e.g. newly adding/using the ex= tension in a pre-existing schema node is NBC, or removing a use of an exten= sion is NBC)

        &nbs= p;       c) usage changes are indeterminate (= i.e. may break compatibility) unless otherwise specified by the specificati= on of the extension

 

Reshad's IETF110 slides: Finished slide 7, start wit= h slide 8 next meeting

 

Jason

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

 

--_000_DM6PR08MB5084F0BC5304A1540C2AABF89B419DM6PR08MB5084namp_-- From nobody Tue Apr 27 13:02:26 2021 Return-Path: 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 B587B3A1E57; Tue, 27 Apr 2021 13:02:21 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AVsUCVVar_Kd; Tue, 27 Apr 2021 13:02:20 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4D43A1E59; Tue, 27 Apr 2021 13:02:20 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (066-227-211-029.res.spectrum.com [66.227.211.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 74F0A805BF; Tue, 27 Apr 2021 20:02:19 +0000 (UTC) References: <161947728622.5344.4005647920914159054@ietfa.amsl.com> User-agent: mu4e 1.5.12; emacs 27.2 From: Christian Hopps To: Linda Dunbar Cc: gen-art@ietf.org, draft-ietf-netmod-geo-location.all@ietf.org, last-call@ietf.org, netmod@ietf.org Date: Tue, 27 Apr 2021 16:00:24 -0400 In-reply-to: <161947728622.5344.4005647920914159054@ietfa.amsl.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-geo-location-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 20:02:22 -0000 Linda Dunbar via Datatracker writes: > Summary: > This draft describes the Geo-location object for YANG. The document is w= ritten > very clear. I don't see any problem., except for one question: > > The "pattern =E2=80=99[ -@\[-\^_-~]*=E2=80=99" is used by leaf astronomic= al-body and container > geodetic-system. Why not creating a Constant for the pattern to be refere= nced? > in case you want to make changes to the pattern. Changing the pattern in YANG is a backward incompatible change, so we don't= actually want to make that indirect or easy. :) Thanks, Chris. > > Major issues: None. > > Minor issues: None. > > Nits/editorial comments: None. > > Best Regards, > Linda Dunbar From nobody Thu Apr 29 13:55:07 2021 Return-Path: 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 044D73A0E6C for ; Thu, 29 Apr 2021 13:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 8jSBYHSrpQH1 for ; Thu, 29 Apr 2021 13:54:57 -0700 (PDT) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2095.outbound.protection.outlook.com [40.107.102.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56F53A0E4B for ; Thu, 29 Apr 2021 13:54:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FWjgo+6lh6aSr9tYXYnteuAYmtBL8is5BY7nOEy/fOg9IFOoVVp7QCCeUrxyurm1e2QTquurcYbLrGxHy6OtZTNfGbJeV97LLfQQFBfa/zf+IE9//dyefAfZRx0bE2hxE945NrNC/8jNOck0MKvwDTdDFv1sIUU8aXTASnrr/5cx+tBBgehbcKpVorok1kJ1qpbSv8P3DdHc3BLw+DODiS3aohv4IMdIAV2CcWtCra1pi2c9Ngi4cG3tp2MO8BjUnDhDZnIEX1wKiun9BCfEwFDj/54fOQbkHbZ+NKW92MDF9gVryRL/epyYmNecv98Ihubxd5qNXnSyJQn+K+3Zew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2qFvLeCKMER6sxVr5+jruJYwuJTHh+yAbS9B7WiBqtw=; b=VR7I9JVMmvOUofW3WyJXlZFnhFC5m6LsqC1o7kZvkmJCp+ncJ4pwm3dV8KtXE6lAsp50NZ52/KrzpehAvYNFvJ1hZS3ShAfczSBPtq4ZoLwK+qb78phhrGQyEQTWr/aJaHkj3ieGQm72/SCIQfhs5TtC6Mo3bGPIT8HmYvk62wBNWnt0tOLtft8mE+JimloWXkh6U4QHZsc8vKu3pWkBr3gk1LSz81D9dEOcjzpXuqv9s7qO/wfqgHHKp9GoNRtLYQMa0rTbiHhUa8p4ybPfTtapzJ+QBAqMywCqiGuJFO+KNulkl1dVe/FU1I6ShOqIp1VlLMtyt0cN7krLyXz9ng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2qFvLeCKMER6sxVr5+jruJYwuJTHh+yAbS9B7WiBqtw=; b=PqNABtJ6IMgKBA1pwlU+/BKP8YIjbr7tBLm6jYvKKNo7OQNGR5jVLGeXXsbuAWuJ8IKgXxakr3uKjHOiDPAe4Sic6D3p6217Hpz68I+pclE5pJFUjBf/l1/1Hh9mk/wInx4ytPn8a6nRSFCsdwZyfCLwZFkO86obJCpZiSTci8U= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB3324.namprd08.prod.outlook.com (2603:10b6:4:65::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.25; Thu, 29 Apr 2021 20:54:54 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::616e:7de0:be27:e9b1%3]) with mapi id 15.20.4065.027; Thu, 29 Apr 2021 20:54:54 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-04-27 Thread-Index: Adc7bjYiO+6Q3DTCSUO8sHh2YaXAwQBy6KgA Date: Thu, 29 Apr 2021 20:54:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:f2c0:e4ae:97:342c:d994:8eaf:9ca1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1be3b88-9508-44f2-3067-08d90b510aac x-ms-traffictypediagnostic: DM5PR08MB3324: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /oPboZ4XgeX5LuL/3nDyxrviEIZmulAK23SFJ2MflEqSy96hpUopxEBFrUhtmUxj2ZvatSsWFq6MDifKZKad+P5tz8GiteadvEZowMCI3QduNEBRNPqTNHSrGR5aDJY+iIh97taNcoKBbY16dJ9BKOl2eBHhjU3NsFEt9abUzNPlkI0oasxQ8AU52Zcif68Imtt/Ggi1v8/icylDwNFsmiuE5IzcuddAgoE7sPMUQuD70uEMHaqmlN0FpIX6aBUMfGgkK+LF7CAzKoRuzVnXCx8oCkIN8e1F7k0IxaoZDKwpn54g63+f4+0dKFcFJio0sgsIMMKKpy2uMZDeCqAbjTQt31jGBSufIk9Qxi26uq9f8D2AjSrfSHTmVqqvW4gVLY5Wn3qj9HHviBx+LkgqW05lU87mrik8rMkNaYvQ+ZXAot+3vlZrrAwirHngbZdaYf2IYItOldcVHNVKti5gyNOb3Js8qi21fEYdZpVF5DClP3LbdwtCf/8CIE1riGjbA3EZXzRhiUYUmDYeZGc8O2goHpdhHPvLnvG3+oDQ/AHaw+spHwmtrNF1Ki1B+0ojmd7koeDn0y7a+fdO44UkKDKUBf2QUxaAlzagNJiaRWpNo0/Ms6ApBteeeZcBNY7kFgbxZx3Y17DPGqeHh4JhyOqWV2wrUq3ql/p5BdX4ZAvGKRFEDwYe8qj2wjQ9U9RB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(39860400002)(136003)(376002)(966005)(52536014)(5660300002)(478600001)(38100700002)(71200400001)(33656002)(66476007)(66446008)(64756008)(122000001)(16799955002)(66946007)(186003)(7696005)(83380400001)(55016002)(86362001)(316002)(76116006)(8936002)(66556008)(6506007)(8676002)(2906002)(6916009)(53546011)(166002)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?MziBBm1xeUhiGM5HXWxMKtj5r7QqKeiLyLk4jEVRHN8eA2nmJiA8QxkjuTjS?= =?us-ascii?Q?KRSsk97rYBYFg6Pethx62W47lvfAP5KwyUi9HZYN5YjuyXDhA/8iYwi9MDZ0?= =?us-ascii?Q?tjq3NS0j4uK5QYLYWV+WQc8eGLg5nPtlntLDzYCEPqTBrADK6Wl5HMdUcfkZ?= =?us-ascii?Q?xHfxXlLl+Sg0eScOqchgiQL3Du5qHLMiTSrf8T8rv1KdFQu+Ea1RkyptrAXJ?= =?us-ascii?Q?21Jr/FRB+5d96gZNBxV8I36jNxjSnjHjGkC8b5f8hnoG1BQw+bYR4/Rn+ncU?= =?us-ascii?Q?D8c+7wTBr+kMt1pIPCsAJH9a7vWHBOOmsuquUZ6Jxg0KX0O0XUoZ27gDEvgu?= =?us-ascii?Q?Kvf7S63/3+padhbbn4QQ/DwzFwNk1lcHLETnMCguz0TVGnZf2uI38N6MdmyT?= =?us-ascii?Q?yBhxi0ejmJ5TVyHmRCPgLE32JKl+/K1izlCnSIsbrFq/TzvemmB4dMIKA6ZD?= =?us-ascii?Q?wPRLyfn2tMjb6yHf+Qf8gUA8CuCldjmNoKXqeI9vayhiVynjBYkvag9QoE8G?= =?us-ascii?Q?yFfyOBJkVLu7v1ZcuB+3EI0m/MK9TDVZYBKm+2ukUcPD+19pDRX1/q+XzDic?= =?us-ascii?Q?/hX2/h06g9SZ67yQV+rkfurBul7DbNJruuvlVrrv3sRX6w8ehKYu9rjyumZs?= =?us-ascii?Q?VjlN0jBA4gDCMSr/WfiPqCfpicx6Nna4bBxeDOkGQKW+sCWzU1upYotiPLqK?= =?us-ascii?Q?z/yjPHaajVeMnoIEvMfVTxmBU6lRQahp7ZHji8y8XyPwU0a4eHaSg4ZR4tgy?= =?us-ascii?Q?Si8Cd4fnwMQHNw1tCDCyI32FyoeKH9CTF76+wBnj4ly4ewpuqkrQnXtKB5bT?= =?us-ascii?Q?lddRiYngb6PuJX4n/QDtxt5Bn2DaI1kMeU0SY4Hv7u0RGjMcu4ba129WA3sa?= =?us-ascii?Q?ZyH1dOsjr4ruOgrRtnXS1LG+QrrEbJI54afrYCJqlhPnQpotRystR+y0CJrs?= =?us-ascii?Q?spiXPUx7u8yVgyqyRzYjTGIkrWGTAgWVCauroQ/hW3rz4bSxmT7JX+lHNIIC?= =?us-ascii?Q?nxyId5Sa9iOIRhr96YaqOjqvGJwd8yJyJmbf/PdgctKN2PGkhm01M7hoQPiz?= =?us-ascii?Q?1DV/yQTOl8qF8RHcd+zcPBg+Z5ODTEZlJ+PABbgPAUJIiafj6VMV5s+PL6NA?= =?us-ascii?Q?vMVwfT3HmWJMEEGrwXupgQuK5q44F94owZ1v6oRtA1XlHPJEb5iI6akyakfE?= =?us-ascii?Q?rYwIPKdRKlV/MYXZ4B5Zc+oR3XW03SP7EGtd06OZiDzbxzIBQMmwGew6LSbJ?= =?us-ascii?Q?dx7hKU6A2AaUF32vetpnUptA0IZmqMEZt/OYY0TAb+yPvZpL48hmgaaYAQsG?= =?us-ascii?Q?c/BoJwuvvljD8EmeG2Nm7B705UunDvxcZd63Zi1HNOGOiIY2lkNoW2RBd4pv?= =?us-ascii?Q?YKL8LFCpwBhXl2lqTyMPOUNAfl7c?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB50843282A121723F2C0730499B5F9DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1be3b88-9508-44f2-3067-08d90b510aac X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2021 20:54:54.7599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kUxKnGNJCAjeTv4jrsFbk+elyTpWi0NjxucJYYFU3zlF38oRiXIqbuwaTPtUN6h562zYwLKbIpJAidTHnVb5IA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3324 Archived-At: Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-27 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 20:55:06 -0000 --_000_DM6PR08MB50843282A121723F2C0730499B5F9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I created issues 93 and 94 for the comparison tool issues mentioned below. Jason From: Sterne, Jason (Nokia - CA/Ottawa) Sent: Tuesday, April 27, 2021 10:05 AM To: netmod@ietf.org Subject: YANG Versioning Weekly Call Minutes - 2021-04-27 YANG Versioning Weekly Call Minutes - 2021-04-27 We continued reviewing Reshad's Module Versioning slides from IETF110 to ca= pture feedback to roll into the draft. Comparison draft should do the following (need to raise Github issues) - have switches for how/if to consider extension statement changes - output should differentiate between changes in config vs changes in state= (separate output reports for config and for state) Issue for tooling/comparison draft: - consider an extension that defines whether changes to an extension (or ad= ding/removing) is BC or NBC (Github issue #92) Extensions (Github issue #12): - differentiate between the *declaration/definition* (i.e. the YANG 'extens= ion' statement keyword) of an extension, and the *use* of the extension - go with 7950 rules for the *declaration/definition* (i.e. you can add a n= ew extension definition and that is BC, but removing or changing one is NBC= ) - For *usage* of an extension: a) everything is BC unless specified otherwise ? b) using the extension in a newly added schema node is BC, = anything else is NBC (e.g. newly adding/using the extension in a pre-existi= ng schema node is NBC, or removing a use of an extension is NBC) c) usage changes are indeterminate (i.e. may break compatib= ility) unless otherwise specified by the specification of the extension Reshad's IETF110 slides: Finished slide 7, start with slide 8 next meeting Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB50843282A121723F2C0730499B5F9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I created issues 93 and 94 for the comparison tool i= ssues mentioned below.

Jason

 

From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, April 27, 2021 10:05 AM
To: netmod@ietf.org
Subject: YANG Versioning Weekly Call Minutes - 2021-04-27=

 

YANG Versioning Weekly Call Minutes - 2021-04-27

 

We continued reviewing Reshad's Module Versioning sl= ides from IETF110 to capture feedback to roll into the draft.

 

Comparison draft should do the following (need to ra= ise Github issues)

- have switches for how/if to consider extension sta= tement changes

- output should differentiate between changes in con= fig vs changes in state (separate output reports for config and for state)<= o:p>

 

Issue for tooling/comparison draft:

- consider an extension that defines whether changes= to an extension (or adding/removing) is BC or NBC (Github issue #92)<= /o:p>

 

Extensions (Github issue #12):

- differentiate between the *declaration/definition*= (i.e. the YANG 'extension' statement keyword) of an extension, and the *us= e* of the extension

- go with 7950 rules for the *declaration/definition= * (i.e. you can add a new extension definition and that is BC, but removing= or changing one is NBC)

- For *usage* of an extension: 

     a) everything is BC un= less specified otherwise ?

        &nbs= p;       b) using the extension in a newly ad= ded schema node is BC, anything else is NBC (e.g. newly adding/using the ex= tension in a pre-existing schema node is NBC, or removing a use of an exten= sion is NBC)

        &nbs= p;       c) usage changes are indeterminate (= i.e. may break compatibility) unless otherwise specified by the specificati= on of the extension

 

Reshad's IETF110 slides: Finished slide 7, start wit= h slide 8 next meeting

 

Jason

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID= =3Dma7627a2ae7b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

 

--_000_DM6PR08MB50843282A121723F2C0730499B5F9DM6PR08MB5084namp_--