Hi authors, chairs, WG,
I’m generally supportive of this work, but I think that there are still some
potential corner cases that are not covered, or it isn’t entirely obvious how
they are handled.
Comments below.
Moderate level comments:
(1) p 7, sec 2.3. Inactive-Until-Referenced
[Resending due to mailer issues.]
Hi authors, chairs, WG,
I’m generally supportive of this work, but I think that there are still some
potential corner cases that are not covered, or it isn’t entirely obvious how
they are handled.
Comments below.
Moderate level comments:
(1) p 7,
this to a separate experimental draft to unblock
taking the module versioning draft to last call?
Regards,
Rob
From: Andy Bierman
Date: Wednesday, 10 April 2024 at 22:11
To: Rob Wilton (rwilton)
Cc: Jason Sterne (Nokia) ,
netmod@ietf.org , Joe Clarke (jclarke)
Subject: Re: [netmod] YANG Versioning
Hi Andy,
For me, it seems likely that vendors using YANG Semver will want to use a
filename that can contain the Semver label, and I still see some advantages for
everyone to do it in a similar way. E.g., it is very likely that internally we
will just use this format, but will probably strip
Yes possibly. Florian would you be interested in helping if we were to do that?
Regards,
Rob
From: Scott Mansfield
Date: Tuesday, 27 February 2024 at 14:16
To: Rob Wilton (rwilton) , Florian Kauer
, netmod@ietf.org
Subject: RE: Modeling of veth pairs
Could we add this case to the intf-ext
netmod-intf-ext-yang.
From: Florian Kauer
Date: Tuesday, 27 February 2024 at 09:02
To: netmod@ietf.org
Cc: Rob Wilton (rwilton) , scott.mansfi...@ericsson.com
Subject: Modeling of veth pairs
Hi,
I would like to model a veth pair in YANG, preferrably without proprietary
models.
In Linux, thes
be
updated to clarify these two points.
Any thoughts for the authors or WG on how to process this errata?
Regards,
Rob
> -Original Message-
> From: RFC Errata System
> Sent: Tuesday, July 12, 2022 4:42 PM
> To: m...@tail-f.com; war...@kumari.net; Rob Wilton (rwilton
Hi,
I just wanted to let everyone know that I'm trying to charter a new "Network
Management Operations" WG. We are in the process of discussing the charter
scope, WG name, and initial work, currently on the ne...@ietf.org open mailing
list. I'm hoping to get put a draft version of the
Specifically regarding MUST statements on state date, RFC 8342 section 5.3,
also has this statement (which effectively aligns to Jürgen's last paragraph):
SHOULD conform to any constraints specified in the data
model, but given the principal aim of returning "in use" values, it
is
Hi,
Looking at this erratum, I agree that it would be better that the module prefix
is used consistently for references to other types within the same module, but
the existing YANG is not wrong.
In YANG, I generally expect prefixes are used when referencing data nodes or
types in other
The two options mix things together. Option 1 says updating YANG 1 and
> YANG 1.1 to allow YANG modules to be modified _based on
> draft-ietf-netmod-yang-module-versioning_ but this document has much
> more in it than just changing a MUST to SHOULD.
[Rob Wilton (rwilton)]
I think that for
Further to Jan's comments, given that all organizations (vendors, SDOs, and
industry consortia) producing YANG modules all occasionally update then in NBC
ways to fix bugs and issues, then I presume that all pragmatic YANG tooling is
obliged to handle cases where modules change in NBC ways.
As a contributor.
I think that Jeff has obviously found a modelling issue, and documenting some
collective guidance on how to handle that is useful. IIRC, an effort was
recently started to do an RFC 8407 (YANG Author Guidelines) bis document and
depending on what and how much needs to be
Hi Martin,
You may have just seen my comment to Juergen, but with an AD hat on, I think
that what you propose is not a valid option.
My understanding is that the IETF process does not allow an RFC to choose to
ignore a MUST statement in another RFC for pragmatic reasons (I would DISCUSS
on
Hi Jürgen, WG,
Writing as an author:
I think that the authors, who have invested a lot of time and effort in this,
are really just looking for a path forward to reach consensus, if that is
possible.
I don't think that presenting the 3 options was intended to mean that
participants just have
: 09 June 2023 16:39
To: Rob Wilton (rwilton)
Cc: Kent Watsen ; Jan Lindblad (jlindbla)
; Jürgen Schönwälder
; Andy Bierman ;
netmod@ietf.org
Subject: RE: [netmod] New Version Notification for
draft-ma-netmod-immutable-flag-07.txt
Hi, Rob
Thanks for sharing your concerns, but I think
> -Original Message-
> From: tom petch
> Sent: 26 June 2023 16:41
> To: Rob Wilton (rwilton) ; Martin Björklund
>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
>
> From: Rob Wilton (r
Hi Tom,
> -Original Message-
> From: tom petch
> Sent: 26 June 2023 12:57
> To: Rob Wilton (rwilton) ; Martin Björklund
>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
>
> From: netm
gt;
> Hi,
>
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.
[Rob Wilton (rwilton)]
The actual goals of this work (i.e., the set of drafts) is aiming to address
the requirements stated here:
https://datatracker.ietf.org/doc/html/draft-ietf-n
I'm wondering whether we are in the realm of missing the bigger picture here,
or perfection being the enemy of good enough.
My first example:
The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has recently been
rechartered to respecify the meaning of the date string in a
is because there is definitely
interest in this work, but personally I would like to see quite significant
changes, and I suspect that more work is required to reach consensus.
Regards,
Rob
From: Kent Watsen
Sent: 01 June 2023 21:55
To: Jan Lindblad (jlindbla) ; Jürgen Schönwälder
; Andy Bierman ; Rob
Wilto
Hi Juergen, Andy,
With an author/contributor hat on ...
It is unclear to me, from an RFC document perspective, what is being proposed
here, and appreciate that each of you may have different thoughts as to what is
being proposed.
E.g., are you proposing:
(1) That the yang module versioning
I was looking at this draft again, and since I had read the -02 version of the
draft I thought that I would send the comments here.
My no hats view here (looking at the latest draft) is:
* documenting something here is probably helpful because this is an issue
that folks are experiencing
To: Rob Wilton (rwilton) ; Italo Busi
; Jeffrey Haas
Cc: netmod@ietf.org
Subject: RE: [netmod] Unknown bits - backwards compatibility
Rob & Italo - are you proposing that the "raw-bits" are all always returned
(whether they are known or not)?
Jason
From: netmod mailto:netmod-bo
Italo's suggest was also how I was thinking of this.
We could define a convention for how the "raw" leaf should be named relative to
the bits decoded leaf, and also what type the "raw" leaf should use. E.g., in
the case where the length of the bits field is known (e.g., it is
: Kathleen Moriarty
Sent: 04 April 2023 19:14
To: Stephan Wenger
Cc: Rob Wilton (rwilton) ; Jürgen Schönwälder
; Joel Halpern ;
Deen, Glenn ; trust...@ietf.org; netmod@ietf.org; The
IESG
Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata
Rob,
Multiple instances could
:23
To: Rob Wilton (rwilton)
Cc: Jan Lindblad (jlindbla) ;
netmod@ietf.org
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
Hi Rob,
- In terms of properties that cannot be changed once written, I would rather
see this issue framed more in the direction of it just being extra
age-
> From: Jürgen Schönwälder
> Sent: 04 April 2023 16:43
> To: Stephan Wenger
> Cc: Joel Halpern ; Rob Wilton (rwilton)
> ; Kathleen Moriarty ;
> Deen, Glenn ; trust...@ietf.org;
> netmod@ietf.org; The IESG
> Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecurit
giving an overview of all paths/subtrees in the module.
Hence, I think that this would end up somewhat changing the template text, and
having one less copy of it seems easier.
Thanks,
Rob
> -Original Message-
> From: Kathleen Moriarty
> Sent: 03 April 2023 21:14
> To: Rob Wil
I'm getting an out-of-office bounce from Glenn, so adding trust...@ietf.org in
the hope that either Kathleen or one of the other trustees is give an answer
more quickly.
Thanks,
Rob
> -Original Message-
> From: Rob Wilton (rwilton)
> Sent: 03 April 2023 18:19
> To: kathlee
Hi Glenn, Kathleen,
In addition to discussing draft-moriarty-yangsecuritytext in the NETMOD WG
session on Friday (where the conclusion was to go the AD sponsored path), I
also raised this issue with the IESG/IAB at the end of the IETF week, and
someone had the suggestion of filling an errata
Hi,
I think that we need to be careful here. In summary, I agree with a lot of the
concerns flagged by Jan, both in ensuring that we don't break existing
NETCONF*/YANG configuration paradigms (*, by NETCONF, I mean NETCONF or
RESTCONF), but also the approach of considering the best long-term
ystore drafts (since they currently state
that the keys/certificates must be copied into , and I think that we
are saying with NMDA that this is not required).
Thanks,
Rob
> -Original Message-
> From: Jürgen Schönwälder
> Sent: 26 March 2023 13:24
> To: Rob Wilton (rwilton)
>
Hi,
I'm in the process of AD reviewing Kent's keystore and truststore drafts in
NETCONF.
In both of these drafts, there is a desire to be able to use keys or
certificates that are managed on the device, potentially as part of a TPM, and
yet be able to reference those keys/certificates from
Hi Jürgen, Netmod, & rfc6874bis interested parties,
In my AD review of draft-ietf-netmod-rfc6991-bis-15, Jurgen has proposed a
change to definition of the zone-id in the ip-address, ipv4-address, and
ipv6-address types. These changes move the definition somewhat closer to what
is in
Hi Jürgen,
Thanks for the draft. Please see my AD review comments below, except for a
couple of comments related to the change to ipv6-address definition that I've
spun into a separate thread so that I can include the interested parties of
draft-ietf-6man-rfc6874bis into the discussion.
.net;
> lind...@cisco.com; j.shoenwael...@jacobs-university.de;
> mjethanand...@gmail.com; wangzi...@huawei.com; Per Andersson
> (perander) ; bill...@huawei.com; Rob Wilton (rwilton)
> ; res...@yahoo.com; balazs.leng...@ericsson.com; Joe
> Clarke (jclarke) ; jason.ste...@nokia.com
>
"No, I'm not aware of any IPR that applies to this draft"
Regards,
Rob
> -Original Message-
> From: Kent Watsen
> Sent: 16 January 2023 23:00
> To: netmod@ietf.org
> Cc: Joe Clarke (jclarke) ; Rob Wilton (rwilton)
> ; Reshad Rahman ; Balázs Lengyel
> ;
which we do not really have formal syntax.
[Rob Wilton (rwilton)]
+1.
It is quite likely that implementations will choose some reasonable limit for
most of these unlimited strings, so it isn't really that they are unlimited,
but the limit is set by the implementation rather than at th
I've decided to reduce the number of NETMOD chairs from 3 chairs down to 2.
Kent and Lou will continue as NETMOD chairs, Joel is stepping down.
For the current amount of work in NETMOD, having two chairs is the optimal
number. In addition, having a free third chair slot potentially allows
Hi Juergen, WG,
draft-ietf-netmod-yang-module-versioning defines section "4. Import by derived
revision" that allows an author to specify a minimum revision of a module that
is allowed to satisfy a YANG import.
IIRC, and hopefully you will correct me if I am wrong, you had two concerns
about
Thanks Jurgen.
I agree, I have rejected this errata.
Regards,
Rob
> -Original Message-
> From: Jürgen Schönwälder
> Sent: 29 July 2022 17:21
> To: RFC Errata System
> Cc: war...@kumari.net; Rob Wilton (rwilton) ;
> kent+i...@watsen.net; joe...@bogus.com; lber...@la
Hi,
Putting aside the discussion about whether we should be changing the use of
ip-address vs ip-address-no-zone in existing YANG modules for the moment, I
believe that the current ipv4-address|ipv6-address|ip-address definitions is
either wrong, or unhelpful for two reasons:
(1) It specifies
Hi Juergen,
Thanks, please see inline ...
At the moment I would like to try and make sure that I accurately understand
the difference in opinion.
> -Original Message-
> From: Jürgen Schönwälder
> Sent: 08 June 2022 16:38
> To: Rob Wilton (rwilton)
> Cc: netmod@ietf.or
Hi Jürgen,
Thank you for your feedback and apologies for the very delayed reply. The
versions authors have been discussing some of the points that you raised in a
lot of detail and hence I was waiting for this discussion to converge before
replying to you.
> -Original Message-
>
Hi Randy,
Thanks for summarizing, but I don't really agree with your categorization for
(1) or (3).
My interpretation of ip-address and the related v4/v6 types, based on RFC 7950,
is that implementations MUST allow clients to configure zoned IP addresses to
be fully complaint with the
; From: Martin Björklund
> Sent: 12 April 2022 08:26
> To: Rob Wilton (rwilton)
> Cc: netmod@ietf.org; l...@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-
> 10.txt
>
> Hi,
>
> Here's another suggest
Spinning off part of the discussion into a separate thread, but keeping lsr
cc'ed on the discussion.
I'm trying to get a better understand of how and where zoned IP addresses
should be used in YANG data models.
RFC 4007 defines zones for IPv6 addresses, but not for IPv4. Even though RFC
Hi Tom,
Please see inline ...
> -Original Message-
> From: tom petch
> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) ; netmod@ietf.org;
> l...@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
>
> Fro
Hi all,
Thanks for the comments on this thread so far. It would be nice if we are able
to come to some sort of rough consensus to a solution.
I think that there is consensus that the YANG type ip-address (and the v4/v6
versions) are badly named as the prominent default type name has been
I basically agree with Acee, and I think that we should do (b):
b) Change the types as suggested and accept that doing so breaks
modules where zone indexes are meaningful.
I appreciate that this is an NBC change, but I believe that this is the most
intuitive definition and is
will be in the Netmod mail archives) are open to all participants.
Regards,
Rob
> -Original Message-
> From: Jürgen Schönwälder
> Sent: 16 March 2022 06:13
> To: RFC Errata System
> Cc: m...@tail-f.com; war...@kumari.net; Rob Wilton (rwilton)
> ; kent+i...@watsen.net; joe...
Hi William,
IANA have published a new revision with the revision history fixed.
iana-if-type YANG
Module<https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml>
Regards,
Rob
From: netmod On Behalf Of Rob Wilton (rwilton)
Sent: 04 March 2022 14:37
To: William Lupton ; Benoit
Hi Andy,
YANG packages are aimed at partly solving the problem you describe below.
In the -00 revision of the packages draft, it included SHA hashes* (YANG leaf
“checksum”) of the included modules and packages so that a client can determine
that its local copy of
Hi Andy,
On this specific point:
Note that with multiple release trains and the new SERMVER, it is likely
that multiple [name, date, label] tuples resolve to the same [name, date] pair,
making the uniqueness problem even worse.
The module versioning draft explicitly disallows this. Even when
Hi William,
I have asked Sabrina in IANA to please publish a new revision with the history
fixed.
Regards,
Rob
From: netmod On Behalf Of William Lupton
Sent: 04 March 2022 10:15
To: Benoit Claise
Cc: NetMod WG
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same
Hi Netmod WG,
As many of you may already aware, I've been closely involved in authoring both
the YANG module versioning draft
(https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/)
and (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/).
I will of course
Watsen
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton)
Cc: SADOVNIKOV, ALEXEI ; RFC Errata System
; m...@tail-f.com; war...@kumari.net; Joel Jaeggli
; Lou Berger ; Randy Presuhn
; netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
Move to close this Errata
To: Rob Wilton (rwilton)
Cc: netmod@ietf.org
Subject: Re: [netmod] Use XML namespaces in YANG document examples
Going back to the original issue and so top-posting.
NSF Monitoring Interface YANG Data Model
is on the IESG Telechat 17feb2022.
It contains the text - not an easy read unless you
"No, I'm not aware of any IPR that applies to this draft"
Thanks,
Rob
-Original Message-
From: Lou Berger
Sent: 31 January 2022 21:57
To: Joe Clarke (jclarke) ; Rob Wilton (rwilton)
; res...@yahoo.com; balazs.leng...@ericsson.com;
jason.ste...@nokia.com; benoit.cla...@hua
"No, I'm not aware of any IPR that applies to this draft"
Thanks,
Rob
-Original Message-
From: Lou Berger
Sent: 31 January 2022 21:54
To: Joe Clarke (jclarke) ; res...@yahoo.com; Rob Wilton
(rwilton) ; balazs.leng...@ericsson.com;
jason.ste...@nokia.com
Cc: NetMod WG ;
Hi Michal,
This isn't directly answering your questions, but I wanted to point out that
YANG versioning work is currently discussing YANG packages, and how they work
with Schema mount. There are weekly calls (which starts in just under half an
hour), that are open to all:
Hi Martin,
I think that the proposal is that should feed into rather
than directly into . The reasoning for this is to allow
configuration to depend on system defined configuration during validation
without requiring that configuration to be copied into . Clients
would still be allowed to
+1 to Juergen's comment.
// As a contributor.
-Original Message-
From: netmod On Behalf Of Jürgen Schönwälder
Sent: 24 November 2021 09:25
To: maqiufang (A)
Cc: netmod@ietf.org
Subject: Re: [netmod] Should the origin="system" be required for system
configurations copied/pasted into ?
ehalf Of Kent Watsen
Sent: 19 November 2021 17:06
To: Rob Wilton (rwilton)
Cc: Erik Auerswald ; netmod@ietf.org;
i...@ietf.org; adr...@olddog.co.uk; rfc...@rfc-editor.org; Qin Wu
; m...@lowentropy.net
Subject: Re: [Errata Verified] RFC8792 (6739)
I do not think this Errata should've been verified b
Hi Juergen,
My preference would be to last call this document so that other YANG modules
can make use of the new types. We can always spin a future bis document if
further common types are useful.
draft-ietf-netmod-yang-module-versioning also makes use of the
revision-identifier type defined
Hi Tom, Med, Authors
Tom, thanks for flagging these.
Med, authors, please can you check if the tree diagrams in
draft-ietf-opsawg-vpn-common-12 or draft-ietf-opsawg-l3sm-l3nm-18 need to be
updated. If they do, then given that these documents are in the RFC editor
queue then we will need to
Carsten & Med,
Thanks for raising this. I agree with the errata, but this will need to be
hold for doc update, because we cannot create a different revision of a YANG
module through the errata process.
Thanks,
Rob
From: iesg On Behalf Of Francesca Palombini
Sent: 05 October 2021 15:12
To:
> -Original Message-
> From: Joe Clarke (jclarke)
> Sent: 14 September 2021 20:38
> To: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: Revision-labels within filenames
>
> > I wasn't thinking of a URL to get the revision-label, I was more thinking
&g
Hi Kent,
It was the YANG package definitions that I had in mind. More details in the
response that I have just sent back to Joe.
Regards,
Rob
> -Original Message-
> From: Kent Watsen
> Sent: 14 September 2021 18:19
> To: Joe Clarke (jclarke)
> Cc: Rob Wilton (rw
> -Original Message-
> From: Joe Clarke (jclarke)
> Sent: 14 September 2021 17:57
> To: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: Revision-labels within filenames
>
> On 9/14/21 12:01, Rob Wilton (rwilton) wrote:
> > Hi Joe,
> >
> &
Hi Joe,
Sorry, I was on PTO for the meeting where this was discussed. I don't think
that it is great that the character needs to be encoded in a URL. It would
seem to make references to YANG files in YANG packages a lot more awkward to
read/write.
Perhaps reusing '@' is pragmatically the
m the
operational state datastore [RFC 8342], then
include-defaults aligns to the definition of that
datastore in RFC 8342.”;
Would text along these lines work?
Thanks,
Rob
From: Balázs Lengyel
Sent: 28 July 2021 23:08
To: Rob Wilton (rwilton) ; Andy Bierman
Cc: NetM
Sent: 27 July 2021 18:00
To: Rob Wilton (rwilton)
Cc: Balázs Lengyel ; NetMod WG
Subject: Re: [netmod] yang-instance-file include-defaults leaf
Hi,
None of this addresses my point that a default value of "trim" is not
appropriate.
Simply remove the default-stmt so that a missing lea
the default “trim”.
Regards,
Rob
From: Andy Bierman
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton)
Cc: NetMod WG ; Balázs Lengyel
Subject: Re: [netmod] yang-instance-file include-defaults leaf
On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton)
mailto:rwil...@cisco.com>> wrote:
Andy
Hi Ben, Chris,
I wanted to check whether this discussion has progressed at all. This is the
only remaining discuss after Roman has cleared his based on the IESG telechat
discussion yesterday (thanks Roman).
Regards,
Rob
> -Original Message-
> From: netmod On Behalf Of Christian
Juergen,
Yes, I agree that is a better phrasing.
Thanks for suggesting it.
Rob
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 09 July 2021 12:50
> To: Rob Wilton (rwilton)
> Cc: Balázs Lengyel ; Andy Bierman
> ; netmod@ietf.org; Benoit Claise
>
>
Andy,
Yes, when I suggested this, I was thinking that a boolean flag might be
sufficient. My point being that automatically filtering out default values
isn’t always the right thing to do.
E.g., something along these lines:
leaf exclude-defaults {
type boolean;
default true;
but perhaps YANG metadata annotations would also
work (RFC 7952).
Regards,
Rob
From: Andy Bierman
Sent: 08 July 2021 21:38
To: Rob Wilton (rwilton)
Cc: Juergen Schoenwaelder ; Balázs
Lengyel ; netmod@ietf.org; Benoit Claise
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-form
-list. If they are excluded then the consumer of the
instance data file can choose any versions of the YANG modules that satisfy the
import dependency."
Regards,
Rob
> -Original Message-
> From: Balázs Lengyel
> Sent: 09 July 2021 08:25
> To: Rob Wilton (rwilton) ;
Hi Balazs,
Would your inline schema not also need to specify the ietf-yang-types
dependency?
E.g., should it be:
ietf-netconf-acm@2018-02-14
ietf-yang-types@2013-07-15
Thanks,
Rob
> -Original Message-
> From: Balázs Lengyel
> Sent: 08 July 2021 12:48
> To: Rob Wil
as helpful.
Regards,
Rob
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel
> Cc: Andy Bierman ; Rob Wilton (rwilton)
> ; netmod@ietf.org; Benoit Claise
>
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-fo
> From: Balázs Lengyel
> Sent: 07 July 2021 08:49
> To: Rob Wilton (rwilton) ; 'netmod@ietf.org'
> ; a...@yumaworks.com; Juergen Schoenwaelder
>
> Cc: Benoit Claise
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
>
> Hello Rob,
> I would b
ws modules to be identified using
revision labels as well as revision dates.
Balazs, I'm good with most of your proposed resolutions, but have answered one
further question inline below.
> -Original Message-
> From: Balázs Lengyel
> Sent: 05 July 2021 13:47
> To: 'netmod@ietf.org'
time. I assume that
the updates to the instance-data doc are also in progress?
Thanks,
Rob
From: Benoit Claise
Sent: 05 July 2021 11:53
To: Rob Wilton (rwilton) ; netmod@ietf.org;
draft-ietf-netconf-notification-capabilit...@ietf.org
Cc: NetMod WG Chairs
Subject: Re: AD review of draft-ietf
Hi Michael,
> -Original Message-
> From: Anima On Behalf Of Michael Richardson
> Sent: 25 June 2021 21:41
> To: Toerless Eckert ; Fries, Steffen
> ; an...@ietf.org; netmod@ietf.org; Kent
> Watsen ; Rob Wilton (rwilton)
> Subject: [Anima] revising RFC8366 -- Re
Hi,
Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16
Thanks for this draft, sorry for the delay in reviewing. It looks like it is
in good shape.
I think that most of my comments are minor or cosmetic suggestions to
potentially improve the phrasing of the text.
1.
Hi,
Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13.
Thanks for this document, I think that it represents important useful
work for advancing the YANG ecosystem.
This document is in good shape, and I mostly have minor comments but
with a few more significant comments.
aeggli ; Rob Wilton (rwilton)
>
> Cc: NetMod WG Chairs ; draft-ietf-netmod-nmda-
> diff@ietf.org; netmod@ietf.org
> Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07
>
> Hi all,
>
> Rob, thank you very much for your AD review! We have just posted a new
> revisio
rg
> Cc: war...@kumari.net; Rob Wilton (rwilton) ;
> joe...@bogus.com; kent+i...@watsen.net; lber...@labn.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6570)
>
> Hi,
>
> This errata is correct and should be verified.
>
>
>
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.
Hi Chris,
Thank you and the WG for your work on this document. I've requested IETF LC.
Regards,
Rob
From: Christian Hopps
Sent: 16 April 2021 22:30
To: Rob Wilton (rwilton)
Cc: netmod@ietf.org; draft-ietf-netmod-geo-location@ietf.org
Subject: Re: AD review of draft-ietf-netmod-geo
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@ietf.org
> Subject: Re: AD review of draft-ietf-netmod-geo-location-07
>
// 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
, and then hopefully we
should be ready to progress this to IETF LC.
Regards,
Rob
From: Andy Bierman
Sent: 05 March 2021 18:46
To: Rob Wilton (rwilton)
Cc: NetMod WG Chairs ; joel jaeggli ;
draft-ietf-netmod-nmda-diff@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda
Hi Italo,
For NMDA:
* The device should accept the configuration if it is plausible that the
configuration could be applied. E.g., if you had the right linecards inserted,
with the right optics, and the configuration won't exhaust the available
resources.
* Once the device has
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
for
it.
Regards,
Rob
From: Andy Bierman
Sent: 05 March 2021 16:36
To: Rob Wilton (rwilton)
Cc: joel jaeggli ; draft-ietf-netmod-nmda-diff@ietf.org;
netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07
On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton)
mailto:rwil
Hi Andy, authors,
Sorry for the long delay in replying.
Please see [RW] inline below …
From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 30 October 2020 01:43
To: joel jaeggli mailto:joe...@gmail.com>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>;
draft-iet
But this can't really be solved until we have a new revision of YANG.
Rob
> -----Original Message-
> From: netmod On Behalf Of Ladislav Lhotka
> Sent: 03 March 2021 12:19
> To: Rob Wilton (rwilton) ;
> netmod@ietf.org
> Subject: Re: [netmod] Proposed IANA text for YANG Module Vers
1 - 100 of 301 matches
Mail list logo
