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
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
Med provided some process issues in the -31, so we minted -32 ahead of the
netmod meeting to sort those out and get it in order for LC.
Joe
From: netmod on behalf of internet-dra...@ietf.org
Date: Wednesday, March 20, 2024 at 22:44
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject:
Mahesh and I have been tracking the crypto collection of drafts. This update
tracks the latest now that they are in LC. The only other change is to bump
the copyright year to 2024.
Joe
From: netmod on behalf of internet-dra...@ietf.org
Date: Tuesday, March 19, 2024 at 03:23
To:
NETMOD WG,
In conjunction with Reshad’s email on module versioning, this updated YANG
Semver draft covers a lot of ground and is complimentary with that work. Many
of these changes were raised on-list as part of our key issues. They were also
discussed at IETF 118.
NOTE: Due to some changes
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
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
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
This new revision does a couple of things:
* Bumps revision number to -10 to keep document from expiring (was slated
to expire Thursday)
* Addresses Key Issue #1 by changing MAY to SHOULD NOT and adding examples
of when NBC changes might be required
Note: this does NOT short-circuit
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.
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
This revision is a resurrection of the expired I-D to help frame the LC
discussions around module versioning and YANG Semver.
Joe
From: netmod on behalf of internet-dra...@ietf.org
Date: Monday, June 26, 2023 at 11:49
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D
> 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,
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
This revision addresses concern over the contributors vs. acknowledging those
that have provided feedback and input. The former should be included in the
IPR responses whereas the latter need not be.
The intent of this change is not to remove anyone from the overall list of
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
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
This new version takes into account Reshad’s review based on his attempt to use
this model for Linux rsyslog. We changed the action leaf to an identityref
instead of an enum, and added a “stop” action to discard and halt processing on
the message.
Additionally, line length reduction was done
This quick update chases the change from revision-label to label as the
revision-label extension in ietf-yang-revisions.yang. The reason for this
change was that the revision-label extension was typically used as
rev:revision-label in modules, and we felt that was redundant and could be
"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: IPR Pol
) to 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 -
This revision does a few things:
* Addresses comment from 114 to use
ct:asymmetric-key-pair-with-cert-grouping instead of
ct:asymmetric-key-pair-with-certs-grouping
* Fix Mahesh’s email
* Replace obsolete RFC references
* Adjust some line lengths
This passes YANG validation
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
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
, will add them to the appendix.
> Thanks again for good comment.
>
> -Qin
> -邮件原件-
> 发件人: Joe Clarke (jclarke) [mailto:jclarke=40cisco@dmarc.ietf.org]
> 发送时间: 2022年4月14日 5:09
> 收件人: Qin Wu ; netmod@ietf.org
> 主题: Re: Feedback on Self-Describing Data Object Tags
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)
>
Thanks to Mahesh and his build system, we have resurrected this draft
from the archive.
This new -27 revision does the following:
* Modernizes the references
* Fixes some linting errors in both the doc and the YANG module
* Changes the use of the old certificate and private-key groupings from
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
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
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
"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
"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
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,
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 Wilton (rwilton) wrote:
> Hi Joe,
>
hen 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
>> Subject: Re: [netm
> 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
riginal Message-
>> From: netmod On Behalf Of Joe Clarke (jclarke)
>> Sent: 14 September 2021 15:56
>> To: netmod@ietf.org
>> Subject: [netmod] Revision-labels within filenames
>>
>> Carsten raised a point at the mic at IETF111 that the chosen character '
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
The only change here is a revision bump to keep the draft alive as work
continues on the overall solution documents.
Joe
On 7/6/21 09:40, 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
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: Saturday, Febru
/?
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 (Nokia - CA/
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:
No changes in this. Just bumping to keep this active while the other drafts
are being refined.
Joe
> On Jan 5, 2021, at 09:17, 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
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
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
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
This represents a lot of work taken from weekly meeting discussions, list
items, and GitHub issues:
* Change the ‘m’ and ‘M’ to ‘_compatible’ and ‘_non_compatible’
* Present guidelines on how to do semver revision-labels for module development
(including examples)
* Define a revision-label
Since I didn’t get any other feedback, I bumped this one again to avoid
expiration. @chairs, what you would like to do with this? Can we move it to
WG LC?
Thanks.
Joe
Begin forwarded message:
From: mailto:internet-dra...@ietf.org>>
Subject: New Version Notification for
> 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
> 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
>>
>> ###
>> 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
>
>
>> On 12 May 2020, at 21:55, Joe Clarke (jclarke)
>> wrote:
>>
>> 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 re
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
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
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
> 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
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.
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
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
[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
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
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
> 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,
This draft is an updated version of the YANG semantic versioning work to bring
it in line with the design team’s YANG module versioning proposal. That is,
this document describes a semver labeling scheme to accompany the
revision-based lineage.
One notable change is that in order to support
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
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
This new version changes the text around requirement 1.4 based on feedback from
IETF 104. The new requirement reads:
1.4 The solution MUST be able to express when non-backwards-compatible changes
have occurred between two revisions of a given YANG module.
Joe
> On Jul 3, 2019, at 12:28,
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
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:
92 matches
Mail list logo
