Thanks for the comments and feedback, Paul. I’ve opened GitHub issue
https://github.com/netmod-wg/syslog-model/issues/14 so Mahesh and I can track
the necessary changes on our end. See below for some initial responses.
The layout is completely broken / wrapped, making the document fairly
unrea
Hey, Éric. The ability for pyang and YANG trees to depict used groupings is a
default setting, and thus this kind of “long” tree would typically be seen (see
Section 2.2 of RFC8340). This can be condensed (with --tree-no-expand-uses),
but I don’t think additional text is warranted beyond the r
Jumping in as a co-editor…
That is correct. Would it help if the word collector was used? Something like
OLD:
It is intended this model be used by vendors who implement syslog in their
systems.
NEW:
It is intended this model be used by vendors who implement syslog collector in
their systems.
Thanks, Tim. We don’t have that in the IANA registry considerations, but I do
get your meaning in terms of the examples (where we don’t, in fact, have any
‘\’). Those are added as part of the automated doc gen system we’re using.
Joe
From: Tim Bray
Date: Tuesday, August 20, 2024 at 15:53
To:
First, let me say I like network modules a lot. I think that middleware
concept is nice and provides useful abstractions.
What I struggle with in this draft is the overall value to the SDN controller
user. I think I get the use case (but please correct me if I’m wrong). I
think the use case
The authors and contributors of the YANG versioning work have posted new
revisions of
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/ and
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/ that address
all pending comments from 118 and 119 as well as some
We discussed this, and I opted for “version” for two reasons. One, the prefix
is included (it’s now just “ys” for simplicity), and two, ultimately, we want
to give YANG modules (and later packages) a “version”. The “semantic” modifier
in the typedef name feels like needless extra typing since
From: Andy Bierman
Date: Tuesday, April 2, 2024 at 17:40
To: Joe Clarke (jclarke)
Cc: Jason Sterne (Nokia) ,
netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver
On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke)
mailto:jcla...@cisco.com>>
Thanks, Andy. See inline below.
I do not agree with these recommendations to change the file names of YANG
modules.
The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
Additional file naming that can be ignored by YANG 1.1 to
I support adoption of this work. It forms the foundation of work in other WGs,
and I’m happy to have this worked by netmod if there is sufficient interest.
As an opsawg co-chair, I’m copying opsawg to get their opinions. This work has
been presented there and is a dependency of an ACL draft cu
: [netmod] I-D Action: draft-ietf-netmod-syslog-model-32.txt
Internet-Draft draft-ietf-netmod-syslog-model-32.txt is now available. It is a
work item of the Network Modeling (NETMOD) WG of the IETF.
Title: A YANG Data Model for Syslog Configuration
Authors: Joe Clarke
Mahesh
Authors: Joe Clarke
Mahesh Jethanandani
Clyde Wildes
Kiran Koushik
Name:draft-ietf-netmod-syslog-model-31.txt
Pages: 43
Dates: 2024-03-19
Abstract:
This document defines a YANG data model for the configuration of a
syslog process. It is
G of the IETF.
Title: YANG Semantic Versioning
Authors: Joe Clarke
Robert Wilton
Reshad Rahman
Balazs Lengyel
Jason Sterne
Benoit Claise
Name:draft-ietf-netmod-yang-semver-14.txt
Pages: 34
Dates: 2024-03-04
Abstract:
I want to summarize what was presented at 118 in NETMOD, plus what was
discussed on this week’s team call regarding these two key issues.
* We will remove the multiple revision-label schemes
* The revision-label concept will be removed from the module versioning
draft and put into the Y
Like I said, I respect Mahesh’s input as original author. It’s hard to
disagree with that. That said, I think the original RFC8519 is useful on its
own, and these proposed extensions add value that may not be needed by
everyone. I’d much rather see this new work progress rather than opening u
This is the reason that, for me, I’d want the extension to be outside the
description in something that is machine-readable. Tools that do understand
this extension could make a better decision about which module revision to use.
Tools that do not understand the extension will resolve the impor
(NETMOD) WG of the IETF.
Title: Updated YANG Module Revision Handling
Authors: Robert Wilton
Reshad Rahman
Balazs Lengyel
Joe Clarke
Jason Sterne
Name:draft-ietf-netmod-yang-module-versioning-10.txt
Pages: 44
Dates: 2023-10-17
I was going to say something similar. We agreed on a set of requirements ahead
of the module versioning and other work that included a mechanism that would
indicate that an NBC change had been made. Simply allowing them without it
would more chaotic to consumers.
Joe
From: netmod on behalf
I support this work. I think the authors have a number of good enhancements in
here. I have a few comments:
* It feels like the problem statement section will get dated as this
document gets standardized. I get wanting to rationalize the work, but I would
focus more on the solution. Pe
Tom, you’re arguing our case. The requirements specifically state that modules
do and need to be updated sometimes in NBC ways. The idea of this work is not
to make perfection the enemy of good.
Joe
From: tom petch
Date: Wednesday, June 28, 2023 at 08:01
To: Joe Clarke (jclarke) , Benoit
Yes, I had pushed for this. I think it would have help better frame this work
given how long it is taking.
Joe
From: netmod on behalf of Benoit Claise
Date: Monday, June 26, 2023 at 12:21
To: tom petch , Joe Clarke (jclarke)
, netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf
Action: draft-ietf-netmod-yang-versioning-reqs-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Network Modeling
(NETMOD) WG of the IETF.
Title : YANG Module Versioning Requirements
Author : Joe
> As for the discussion on YANG artifact “equivalence” I recall we discussed
> this a bit in meetings and amongst the authors. I don’t remember all the
> points but it boiled down to when the revision changes, the revision-label
> changes. So if, for example, a module is extracted or produced
Thanks for the detailed review, Jürgen. See below on responses concerning YANG
Semver.
As for the discussion on YANG artifact “equivalence” I recall we discussed this
a bit in meetings and amongst the authors. I don’t remember all the points but
it boiled down to when the revision changes, th
Thank you for the review, Alex. A big thanks for catching the sync issue with
yang-module-versioning. I have updated the text in GitHub pending the end of
WGLC to make sure we capture all of the feedback.
The diff can be found at
https://github.com/netmod-wg/yang-ver-dt/commit/5081c8af42a3d93
available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Network Modeling
(NETMOD) WG of the IETF.
Title : YANG Semantic Versioning
Authors : Joe Clarke
Robert Wilton
Reshad Rahman
Grrr, this is at 9:00 am EDT on Tuesdays.
Joe
From: netmod on behalf of Joe Clarke (jclarke)
Date: Thursday, March 30, 2023 at 21:27
To: netmod@ietf.org
Subject: [netmod] ICS file for the weekly versioning meeting
Carsten opined it might be nice to have an ICS file for our weekly versioning
Carsten opined it might be nice to have an ICS file for our weekly versioning
call. Attached is the ICS that I have been using. Our next meeting is Tuesday
April 4 at 10:00 am EDT.
Joe
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VT
I am going to commit a -30 with a small typo fix, and then both Mahesh and I
are good with your proposal.
Joe
From: netmod on behalf of Kent Watsen
Date: Monday, March 6, 2023 at 09:22
To: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-syslog-model-28
NETMOD WG,
We started
-Drafts directories.
This Internet-Draft is a work item of the Network Modeling WG of the IETF.
Title : A YANG Data Model for Syslog Configuration
Authors : Joe Clarke
Mahesh Jethanandani
Clyde Wildes
-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.
Title : YANG Semantic Versioning
Authors : Joe Clarke
Robert Wilton
Reshad Rahman
Balazs Lengyel
"No, I'm not aware of any IPR that applies to this draft"
Joe
From: Kent Watsen
Date: Monday, January 16, 2023 at 18:00
To: netmod@ietf.org
Cc: Joe Clarke (jclarke) , Rob Wilton (rwilton)
, Reshad Rahman , Balázs
Lengyel , Jason Sterne (Nokia)
, Benoit Claise
Subject: IP
allow for
future extensibility here.
What does the WG think of these options (now that we’re in another LC)?
Joe
From: Kent Watsen
Date: Friday, January 13, 2023 at 07:58
To: Reshad Rahman
Cc: netmod@ietf.org , Joe Clarke (jclarke)
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog
I opened GH issue #177 for the branching text (see
https://github.com/netmod-wg/yang-ver-dt/issues/177).
Joe
From: netmod on behalf of Sterne, Jason (Nokia -
CA/Ottawa)
Date: Tuesday, October 18, 2022 at 10:09
To: netmod@ietf.org
Subject: [netmod] YANG Versioning Weekly Call Minutes - 2022-1
: draft-ietf-netmod-syslog-model-28.txt
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 Data Model for Syslog Configuration
Authors : Joe Clarke
On 6/8/22 13:29, Andy Bierman wrote:
On Wed, Jun 8, 2022 at 10:04 AM Jürgen Schönwälder
mailto:j.schoenwael...@jacobs-university.de>>
wrote:
On Wed, Jun 08, 2022 at 04:40:05PM +, Rob Wilton (rwilton) wrote:
> >
> > Rob,
> >
> > discussing details is likely distracting from the main differ
Thanks, Andy. We know it's been a while, and we're trying to take care of all
of these comments. See below.
On 3/9/22 13:13, Andy Bierman wrote:
On Wed, Mar 9, 2022 at 2:16 AM Jürgen Schönwälder
mailto:j.schoenwael...@jacobs-university.de>>
wrote:
Hi,
the YANG versioning solution appears t
es".
Joe
On 4/29/22 06:38, Qin Wu wrote:
> Hi, Joe:
> See usage example at the instance level in the Appendix B in v-07
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-node-tags-07
>
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Qin Wu
&
Thanks, Qin. See below. I had to get back into the tags groove.
On 4/10/22 06:49, Qin Wu wrote:
> Hi, Joe:
> Sorry for late follow up. Thank for your comment, please see my reply below.
> -邮件原件-
>> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Joe Clarke (jclarke)
>
> This draft is a work item of the Network Modeling WG of the IETF.
>
> Title : A YANG Data Model for Syslog Configuration
> Authors : Joe Clarke
> Mahesh Jethanandani
> Clyde Wildes
>
Hello, chairs and WG. At today's 113 meeting, the chairs mentioned the
ietf-netmod-syslog draft needs a new editor to bring it back from the
archive and fix up references, examples, and YANG imports. I did a
quick read through, and I see a number of these issues already.
If no one else has alrea
Rob commented at the mic during the 113 meeting that using
self-describing tags for specific data instances may be a design of this
solution, but the text doesn't state that. To add to the request to
provide such text, it would be useful to have an example showing this.
One potential use I can th
Thanks for your comments and feedback, Jürgen. Some of these changes
have been done in git whereas others have had issues opened for more
discussion and work. Based on other responses, we will create a new
revision of the I-D after the window opens.
See below for specific replies.
On 3/6/22 06:
"No, I'm not aware of any IPR that applies to this draft"
Joe
On 1/31/22 16:57, Lou Berger wrote:
>
> Authors, Contributors, WG,
>
> As part of WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that appli
"No, I'm not aware of any IPR that applies to this draft"
Joe
On 1/31/22 16:54, Lou Berger wrote:
>
> Authors, Contributors, WG,
>
> As part of WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that appli
I left some comments in the GH pull request, Jason. Mostly editorial, but I
think there might be a need for a stronger bit of normative language in there
as well.
Joe
On 11/17/21 14:30, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Hi all,
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-ya
ub to provide an un-revisioned module name.
That would work for '#' as well.
I think the proposal, therefore, is still to go with '#' to designate a
revision-label is to follow.
Joe
On 9/14/21, 12:56, "Joe Clarke (jclarke)" wrote:
On 9/14/21 12:01, Rob Wilto
ageous over #. But then you have the issue with tooling.
Joe
>
> Jason
>
>> -Original Message-
>> From: netmod On Behalf Of Rob Wilton
>> (rwilton)
>> Sent: Wednesday, September 15, 2021 5:08 AM
>> To: Joe Clarke (jclarke) ;
>> netmod@ietf.org
&g
> I wasn't thinking of a URL to get the revision-label, I was more thinking of
> a URL to identify the source YANG file for a particular revision.
>
> E.g., in the YANG packages examples:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages#appendix-A
>
> Ideally, I would like
natively, if we really want to differentiate, then could '@@' work?
@@ was discussed, but would likely still trip up current tools that
expect '@' followed by a revision date. But if we're good with
disrupting this, I'd prefer we overload the single '@'.
Joe
Carsten raised a point at the mic at IETF111 that the chosen character
'#' to separate the module name and module revision-label in filenames
is problematic. Currently, the YANG module versioning draft says that
if you want to use revision-label within the filename, you use
MODULE_NAME#REVISION_LA
em of the Network Modeling WG of the IETF.
>
> Title : YANG Module Versioning Requirements
> Author : Joe Clarke
> Filename: draft-ietf-netmod-yang-versioning-reqs-05.txt
> Pages : 12
> Date: 2021-07
...@ietf.org wrote:
> 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 : YANG Semantic Versioning
> Authors : Benoit Claise
>
module or submodule. Doing so
can lead to import breakages when import by revision-or-derived is used.
Moreover, truncating history may cause loss of visibility of when
non-backwards-compatible changes were introduced.
Jason
From: Joe Clarke (jclarke) <mailto:jcla...@cisco.com>
Sent: Satur
as to when/?
Yang-semver changes also good with me.
Regards,
Reshad.
From: netmod <mailto:netmod-boun...@ietf.org> on
behalf of "Joe Clarke (jclarke)"
<mailto:jclarke=40cisco@dmarc.ietf.org>
Date: Wednesday, February 10, 2021 at 4:02 PM
To: "Sterne, Jason (N
On T4 (gaps in revision numbers and revision history), I have some proposed
text for both draft-ietf-netmod-yang-module-versioning and
draft-ietf-netmod-yang-semver. See these diffs (some changes are due to
xml2rfc changes, but you'll note the more substantive text additions).
Thoughts:
modu
tem of the Network Modeling WG of the IETF.
>
>Title : YANG Module Versioning Requirements
> Author : Joe Clarke
> Filename: draft-ietf-netmod-yang-versioning-reqs-04.txt
> Pages : 12
> Date: 2021-01
This is only a reference fix and bump to unexpire it. Recent work has been
focused on YANG packages and semver for the most part.
Joe
> On Nov 2, 2020, at 11:47, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This dra
This is only a reference fix and bump to unexpire it. Recent work has been
focused on YANG packages and semver for the most part.
Joe
> On Nov 2, 2020, at 11:46, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This dra
On Aug 26, 2020, at 15:55, Juergen Schoenwaelder
mailto:j.schoenwael...@jacobs-university.de>>
wrote:
On Wed, Aug 26, 2020 at 05:43:27PM +0000, Joe Clarke (jclarke) wrote:
On Aug 13, 2020, at 06:23, Juergen Schoenwaelder
mailto:j.schoenwael...@jacobs-university.de>>
wrote:
On
> On Aug 13, 2020, at 06:23, Juergen Schoenwaelder
> wrote:
>
> On Thu, Aug 13, 2020 at 11:37:18AM +0200, Ladislav Lhotka wrote:
>>
>>
>> $ pyang -f yin ietf-inet-types.yang | xmllint --c14n - | sha256sum
>> 8d1ca8f30566ce8cbeffa095e20642f8f6e9f3a724286be4ead863b4467dc40b -
>>
>> might be
> On Aug 12, 2020, at 04:04, Ladislav Lhotka wrote:
>
> "Joe Clarke \(jclarke\)" writes:
>
>>> On Aug 11, 2020, at 10:45, Martin Björklund wrote:
>>>
>>> Hi,
>>>
>>> "Joe Clarke \(jclarke\)" wrote:
>&g
> On Aug 11, 2020, at 10:52, Ladislav Lhotka wrote:
>
>
>
> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
>> At the IETF 108 virtual meeting, Lada asked about what would happen if he
>> converted a YANG module to YIN syntax (or vice versa, or to some other
&
> On Aug 11, 2020, at 10:45, Martin Björklund wrote:
>
> Hi,
>
> "Joe Clarke \(jclarke\)" wrote:
>> At the IETF 108 virtual meeting, Lada asked about what would happen if
>> he converted a YANG module to YIN syntax (or vice versa, or to some
>> oth
At the IETF 108 virtual meeting, Lada asked about what would happen if he
converted a YANG module to YIN syntax (or vice versa, or to some other format).
This was during the discussion of the issue of what should happen if a module
changes and the only changes are insignificant whitespaces (e.g
YANG Semantic Versioning
>Authors : Benoit Claise
> Joe Clarke
> Reshad Rahman
> Robert Wilton
> Balazs Lengyel
> Jason Sterne
>
netmod-yang-versioning-reqs-03.txt
Date: June 29, 2020 at 14:33:39 EDT
To: Joe Clarke mailto:jcla...@cisco.com>>
A new version of I-D, draft-ietf-netmod-yang-versioning-reqs-03.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.
Name: draft-ietf-netmod-yan
> On Jun 22, 2020, at 11:41, Juergen Schoenwaelder
> wrote:
>
> I have RFC at version 1.0.0. I make some backwards compatible
> changes. I then make a backwards incompatible change. Then I add more
> backwards compatible changes. Then I remove the backwards incompatible
> change. What are
It’s that time again. The versioning requirements draft is about to expire.
What should the destiny of this draft be? The authors of the solution drafts
would like to see this move to informational RFC since it’s referenced by a
number of those drafts. I’m not terribly fond of just bumping t
> On Jun 10, 2020, at 17:13, Reshad Rahman (rrahman)
> wrote:
>
> Hi,
>
> I understand the requirement to not break what's currently working for date
> in the filename. However we do need something similar to work for
> revision-label. Having another file with the revision-label embedded in
>>
>> ###
>> Option J1
>> ###
>> use the following suffixes:
>> _non_compatible (instead of the old "M", for an NBC change)
>> _compatible (instead of the old "m", for a BC change)
>>
>> e.g. for NBC:
>> 1.1.0 -> 1.1.1_non_compatible
>> e.g. for BC:
>> 1.1.0 -> 1.1.1_compatible
the record,
> I do have some issue relating to other pieces, especially around the use of
> the letter 'm'.
Thanks, Jan. I missed the call yesterday, too, but I understand m|M is still
being debated and there isn’t strong support of those letters specifically.
Joe
>
>
There has been recent discussion about how to handle applying versions to new
modules, modules in development, and revisions to modules that previously did
not have a revision-label. Below is proposed text to offer both general and
IETF-specific guidelines for this. The intent is to place this
On Apr 2, 2020, at 12:01, Andy Bierman
mailto:a...@yumaworks.com>> wrote:
Hi,
I agree that a revision-label could be useful in an I-D but not to indicate NBC
changes (because it doesn't).
The rules need to be clear and simple with no exceptions.
1) Special version 0.x.y contains NO NBC info
Happy to do it when I’m not presenting.
Joe
> On Apr 1, 2020, at 19:17, Kent Watsen wrote:
>
> All,
>
> The NETMOD chairs need a Jabber Scribe for tomorrow's meeting!
>
> - We’re asking now so as to not waste precious time during the session...
> - The chairs cannot do it because their at
> On Apr 1, 2020, at 13:28, Andy Bierman wrote:
>
> Hi,
>
> I just want to confirm that all the proposed documentation procedures
> using new extensions are limited in scope to published modules only,
> and not applied to unpublished modules (terms defined in RFC 8407).
>
> IMO it would be ha
On Mar 17, 2020, at 08:15, Lou Berger
mailto:lber...@labn..net>> wrote:
All,
The adoption call ended yesterday. While there is clearly work to do to reach
consensus on these documents, they are all adopted as the starting point for
the solutions that the WG will develop on these topics. N
As an author/editor/DT member, I support adoption. Note: obviously adoption
doesn’t mean they’re final, and we are absolutely looking for the WG to provide
into, especially on the newer work around version selection and schema
comparison.
Joe
> On Mar 2, 2020, at 17:29, Lou Berger wrote:
>
I know of no IPR that applies to this draft.
Joe
> On Mar 2, 2020, at 17:13, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware
I know of no IPR that applies to this draft.
Joe
> On Mar 2, 2020, at 17:13, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware
I know of no IPR that applies to this draft.
Joe
> On Mar 2, 2020, at 17:13, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware
I know of no IPR that applies to this draft.
Joe
> On Mar 2, 2020, at 17:13, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware
I know of no IPR that applies to this draft.
Joe
> On Mar 2, 2020, at 17:13, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware
> On Dec 6, 2019, at 22:41, Qin Wu wrote:
>
> Thanks Martin and Joe for clarification and suggested changes. I will
> implement them in v-09.
Thanks, Qin.
Joe
>
> -Qin
> -----邮件原件-----
> 发件人: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
> 发送时间: 2019年12月5日 23
> On Dec 5, 2019, at 10:48, Martin Bjorklund wrote:
>
> Hi,
>
> "Joe Clarke (jclarke)" wrote:
>> On Dec 4, 2019, at 22:37, Qin Wu wrote:
>>
>> v-08 is posted to address comments received from YANG doctor review and
>> additional comments
On Dec 4, 2019, at 22:37, Qin Wu
mailto:bill...@huawei.com>> wrote:
v-08 is posted to address comments received from YANG doctor review and
additional comments from Joe.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-08
Thanks, Qin. But this isn’t actually w
Sorry, I had to walk out for a few minutes in this morning’s netmod meeting. I
noticed Balazs presented this yid-version notation for instance data. I
thought he mentioned that it could be 1, 2 or something like 1.1. However,
it’s defined to be a uint8. So it could never be 1.1. I’m not nec
[Qin]: Yes, resetting processes or restarting node did cover ZTP part, from
Martin’s comment, I feel we don’t need to tie resetting process with RFC8572,
since RFC8572 actually focuses on SZTP.
Actually we may have a lot of legacy ZTP mechanism we can leverage, I am not
sure which reference I s
On Nov 17, 2019, at 10:29, Qin Wu
mailto:bill...@huawei.com>> wrote:
Done, Kent.
https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/?include_text=1
Thanks for follow up.
Hey, Qin. I see you removed the ZTP reference. I saw the conversation, and
you still have the text about
On Nov 1, 2019, at 11:21, Kent Watsen
mailto:kent+i...@watsen.net>> wrote:
This begins a two-week Working Group Last Call (WGLC) on
draft-ietf-netmod-factory-default-05. The WGLC ends on Nov 15 (two days before
the NETMOD 106 session). Please send your comments to the working group
mailin
On Oct 28, 2019, at 11:54, Kent Watsen
mailto:kent+i...@watsen.net>> wrote:
Regarding this point:
First, I remember we talked about a reboot operation I think at the last
IETF(?). It was said that perhaps a reboot would happen as part of this RPC
because once the datastore is reset to fac
> On Oct 27, 2019, at 23:37, Qin Wu wrote:
>
> v-04 is posted
> https://tools.ietf.org/html/draft-ietf-netmod-factory-default-04
> additional text to clarify rpc usage.
Thanks, Qin. I re-read this latest draft, and albeit there were only a few
changes, I have some broader comments.
First, I
gyel
mailto:balazs.leng...@ericsson.com>>, Kevin
D'Souza mailto:kd6...@att.com>>, Benoit Claise
mailto:bcla...@cisco.com>>, Joe Clarke
mailto:jcla...@cisco.com>>
A new version of I-D, draft-verdt-netmod-yang-semver-01.txt
has been successfully submitted by Joe Clarke
On Jul 23, 2019, at 18:01, Rob Wilton (rwilton)
mailto:rwil...@cisco.com>> wrote:
If you want to dump the configuration on the device to a file for some offline
analysis, then it might be useful if it is possible for that file to have the
timestamps of when the configuration changed annotated
I’ve had a chance to digest the question asked in the meeting about should the
last-modified and entity-tag should be defined in the instance data draft.
I feel they should be removed and moved to a separate draft. First, the draft
doesn’t present a use case for these. There is already an over
:28, internet-dra...@ietf.org wrote:
>
>
> 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 : YANG Module Versioning Requirements
> A
Coming out of IETF 104, there was feedback that the YANG version requirements
draft (draft-ietf-netmod-yang-versioning-reqs) needed a wording change to
requirement 1.4. I have made the change I think addresses the feedback, and I
would like to get thoughts on this wording and publish a rev -01
> On May 8, 2019, at 07:31, tom petch wrote:
>
> - Original Message -
> From: "Joe Clarke (jclarke)"
> Sent: Monday, May 06, 2019 4:11 PM
>>
>> On May 6, 2019, at 08:06, Qin Wu
> mailto:bill...@huawei.com>> wrote:
>>
>> Hi
First, the term “YANG server” sounds odd to me. I know what you mean, but I
haven’t seen this defined before. Maybe just saying a device or host is
sufficient?
[Qin]: Right, “host”, in my opinion, is not a term used in the context of
NETCONF, it is also usually referred to end device in many
On May 6, 2019, at 08:06, Qin Wu
mailto:bill...@huawei.com>> wrote:
Hi, Chairs:
Sorry for late follow up, thanks Jurgen, Andy,Joe, Joel and all others for good
comments, here is the update based on discussion and suggestion on the mailing
list
The diff is:
https://www.ietf.org/rfcdiff?url2=dr
1 - 100 of 152 matches
Mail list logo