WG,
The chairs want to follow up on this Last Call.
We had some excellent discussion and wanted to ensure that that discussion had
time to play out. We think think that there is still a path forward for "rough
consensus" on the these drafts. To help move the discussion to closure and aid
in
On 13/06/2023 17.21, Ladislav Lhotka wrote:
Dne 13. 06. 23 v 17:07 Robert Varga napsal(a):
On 05/06/2023 11.46, Martin Björklund wrote:
- introduce new instance-identifier data type based on RFC 7951
definition
- introduce new identityref data type based on RFC 7951 definition
... but I
> -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
state that changes MUST be backwards compatible,
> > > whereas this draft states SHOULD be backwards compatible, without a
> > > change to the YANG version number. Is that correct?
> > >
> > > If the existing deployment and evolution of YANG modules among
> &g
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
g
> > widely honoured anyway, and instead is being treated as a goal or
> > aspiration. What these documents attempt to do is to move YANG module
> > evolution from what we currently have now where clients don't have any
> > way of really knowing how a module has evolved an
rwilton=40cisco@dmarc.ietf.org
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > > drafts
> > >
> > > Hi,
> > >
> > > But the two drafts go way beyond fixing
; versioning draft is around the updates to section 11 of RFC 7950,
> > > which effectively state that changes MUST be backwards compatible,
> > > whereas this draft states SHOULD be backwards compatible, without a
> > > change to the YANG version number. Is that correct?
> >
On Tue, Jun 13, 2023 at 05:54:40PM +, Joe Clarke (jclarke) wrote:
> > - I prefer to have non-backwards compatible changes marked and
> > explained in the modules instead of relying on some schema
> > comparison algorithm.
> >
> > [JMC] IMHO, the algorithm is useful in addition to any per-m
On Tue, Jun 13, 2023 at 05:31:26PM +, Jason Sterne (Nokia) wrote:
> Its too late. The industry is already ignoring parts of 7950 in cases where
> many people agree that is the most practical thing to do.
>
> This work gives a common format for an author to explicitly indicate “hey –
> look o
> 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
> scoping changes). I think it would be a mistake to only put this new YANG
> versioning work into a YANG 1.2 (which would be cumulative of YANG 1.1 +
> additional changes). The extensions are useful to YANG 1.0 and YANG 1.1
> modules.
>
>
>
> I still feel the wor
From: Andy Bierman
Sent: Tuesday, June 13, 2023 12:45 PM
To: Jason Sterne (Nokia)
Cc: Martin Björklund ; rwilton=40cisco@dmarc.ietf.org;
netmod@ietf.org
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
CAUTION: This is an external email. Please
as this draft states SHOULD be backwards compatible, without a
> > change to the YANG version number. Is that correct?
> >
> > If the existing deployment and evolution of YANG modules among
> > vendors, OpenConfig, IETF, and other SDOs strictly followed the rules
> > in R
Hi Martin,
> -Original Message-
> From: netmod On Behalf Of Martin Björklund
> Sent: 07 June 2023 08:22
> To: rwilton=40cisco@dmarc.ietf.org
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
&
Bierman
Sent: Wednesday, June 7, 2023 4:49 PM
To: Martin Björklund
Cc: rwilton=40cisco@dmarc.ietf.org; netmod@ietf.org
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
CAUTION: This is an external email. Please be very careful when clicki
Dne 13. 06. 23 v 17:07 Robert Varga napsal(a):
On 05/06/2023 11.46, Martin Björklund wrote:
- introduce new instance-identifier data type based on RFC 7951
definition
- introduce new identityref data type based on RFC 7951 definition
... but I do agree with these!
I am not sure I follo
On 05/06/2023 11.46, Martin Björklund wrote:
- introduce new instance-identifier data type based on RFC 7951 definition
- introduce new identityref data type based on RFC 7951 definition
... but I do agree with these!
I am not sure I follow... is this about providing
instance-identifier
On Mon, Jun 12, 2023 at 03:45:41PM +, Joe Clarke (jclarke) wrote:
> 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 do
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
ot; is being
> > widely honoured anyway, and instead is being treated as a goal or
> > aspiration. What these documents attempt to do is to move YANG module
> > evolution from what we currently have now where clients don't have any
> > way of really knowing how a module has e
From: netmod on behalf of Jürgen Schönwälder
Sent: 06 June 2023 06:06
On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> >
> > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > does not
shape where they
> achieve rough consensus and are acceptable to the WG to be published
> now, in the short term, as a good enough solution. After that point,
> then I think that it would be great for some folks to form an idea on
> a what YANG 1.2/2.0 could look like, but I think that c
w which hat he is wearing for this comment, but is
only trying to do the right thing for the wider industry ...
> -Original Message-
> From: netmod On Behalf Of Jürgen Schönwälder
> Sent: 06 June 2023 06:07
> To: Martin Björklund
> Cc: netmod@ietf.org
> Subject: Re:
On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> >
> > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > does not add any other new features, then having agreement on such a
> > statement
Jürgen Schönwälder wrote:
> On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
> >
> > Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next
> > design team, asked to produce a limited-scope I-D they think best.
> > WG-objections of the form "my pet-issue isn't picked
On Mon, Jun 5, 2023 at 5:32 AM Jürgen Schönwälder
wrote:
> On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
> >
> > Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next
> design team, asked to produce a limited-scope I-D they think best.
> WG-objections of the form "m
On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
>
> Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next design
> team, asked to produce a limited-scope I-D they think best. WG-objections of
> the form "my pet-issue isn't picked-up" should not be used to fail adopt
Hi Martin!
> I think you meant https://github.com/netmod-wg/yang-next/issues/49.
Yes but, in spirit of the idea, I suppose both would be in play, if at all.
>> IMO the parsing of YANG files to produce a conceptual data model
>> is a critical component of the language itself. Any statements th
Andy Bierman wrote:
> On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen wrote:
>
> > As an individual contributor and faithful YANG custodian, I cannot
> > support work that changes YANG-semantics without versioning YANG itself.
> > As Andy wrote before:
> >
> > The only correct way to remove MUST/
On 2023-06-04, at 19:42, Jürgen Schönwälder
wrote:
>
>>
>> I’m not sure I understand the current discussion, but wouldn't
>>
>> curl -s https://www.rfc-editor.org/rfc/rfc9127.xml | xmlstarlet sel -T -t -v
>> "//sourcecode[@name='ietf-bfd-ty...@2021-10-21.yang']/text()”
>>
>> be considered an
From: netmod on behalf of Jürgen Schönwälder
Sent: 04 June 2023 18:42
On Sun, Jun 04, 2023 at 07:01:16PM +0200, Carsten Bormann wrote:
> On 2023-06-02, at 18:37, Jürgen Schönwälder
> wrote:
> >
> > I am not aware of an official authoritative source of YANG files.
>
> I’m not sure I understand
On Sun, Jun 04, 2023 at 07:01:16PM +0200, Carsten Bormann wrote:
> On 2023-06-02, at 18:37, Jürgen Schönwälder
> wrote:
> >
> > I am not aware of an official authoritative source of YANG files.
>
> I’m not sure I understand the current discussion, but wouldn't
>
> curl -s https://www.rfc-edito
On 2023-06-02, at 18:37, Jürgen Schönwälder
wrote:
>
> I am not aware of an official authoritative source of YANG files.
I’m not sure I understand the current discussion, but wouldn't
curl -s https://www.rfc-editor.org/rfc/rfc9127.xml | xmlstarlet sel -T -t -v
"//sourcecode[@name='ietf-bfd-ty
On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen wrote:
> As an individual contributor and faithful YANG custodian, I cannot
> support work that changes YANG-semantics without versioning YANG itself.
> As Andy wrote before:
>
> The only correct way to remove MUST/MUST NOT from the "YANG contract"
>
As an individual contributor and faithful YANG custodian, I cannot support work
that changes YANG-semantics without versioning YANG itself. As Andy wrote
before:
The only correct way to remove MUST/MUST NOT from the "YANG contract"
is to introduce a new YANG language version (1.2), and
On Fri, Jun 02, 2023 at 06:13:08PM +0200, Robert Varga wrote:
> On 31/05/2023 09.50, Jürgen Schönwälder wrote:
> > On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
> > > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> > > > It is unclear what "identical" means here. If two people
On 31/05/2023 17.22, Andy Bierman wrote:
I checked some recent YANG modules, and the extra newline problem has
been fixed.
Great :)
I am finding a different issue where trailing whitespace in the author's
YANG file on github
is removed from the YangModels repo version. E.g.
ietf-netconf-ser
On 31/05/2023 09.50, Jürgen Schönwälder wrote:
On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
On 30/05/2023 20.28, Jürgen Schönwälder wrote:
It is unclear what "identical" means here. If two people extract a
module from an RFC, they may not end up with identical byte
On Wed, May 31, 2023 at 3:12 AM Andy Bierman wrote:
>
>
> On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder
> wrote:
>
>> On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
>> > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
>> > >It is unclear what "identical" means here. If tw
On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder
wrote:
> On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
> > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> > >It is unclear what "identical" means here. If two people extract a
> > >module from an RFC, they may not end u
On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
> On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> >It is unclear what "identical" means here. If two people extract a
> >module from an RFC, they may not end up with identical byte
> >sequences. So does white space matter wh
On Tue, May 30, 2023 at 5:13 PM Robert Varga wrote:
> On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> >It is unclear what "identical" means here. If two people extract a
> >module from an RFC, they may not end up with identical byte
> >sequences. So does white space matter when we ta
On 30/05/2023 20.28, Jürgen Schönwälder wrote:
It is unclear what "identical" means here. If two people extract a
module from an RFC, they may not end up with identical byte
sequences. So does white space matter when we talk about MUST be
identical? What about comments? The problem is
On Mon, May 08, 2023 at 10:49:15PM +, Kent Watsen wrote:
> Dear NETMOD WG,
>
> This message begins a joint two-week WGLC for
> draft-ietf-netmod-yang-semver-11 and
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd. Neither draft has IPR declared. Here are the
> d
/5081c8af42a3d93a6e25d0106bf80e483c960c08.
Joe
From: netmod on behalf of Alex Huang Feng
Date: Monday, May 22, 2023 at 12:58
To: netmod@ietf.org
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
Dear NETMOD,
I have read both draft and they look good. One minor
On Tue, May 16, 2023 at 11:10 AM Robert Varga wrote:
> On 09/05/2023 00.49, Kent Watsen wrote:
> > Dear NETMOD WG,
> >
> > This message begins a joint two-week WGLC for
> draft-ietf-netmod-yang-semver-11 and
> draft-ietf-netmod-yang-module-versioning-09
> > ending on Monday, May 22nd. Neither
NETMOD WG,
The chairs are extending this WGLC by two weeks (now ending June 5) in order to
ensure adequate review, since this is important work, and a solid consensus is
needed.
Kent and Lou
> On May 8, 2023, at 6:49 PM, Kent Watsen wrote:
>
> Dear NETMOD WG,
>
> This message begins a joi
Dear NETMOD,
I have read both draft and they look good. One minor comment.
On the last iterations of the versioning draft, the "revision-or-derived”
extension was changed to “recommended-min”.
Though, in the semver draft, "revision-or-derived” is still being used. Can you
change that to remain
On 09/05/2023 00.49, Kent Watsen wrote:
Dear NETMOD WG,
This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11
and draft-ietf-netmod-yang-module-versioning-09
ending on Monday, May 22nd. Neither draft has IPR declared. Here are the
direct links to the HTML version f
Dear NETMOD WG,
This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11
and draft-ietf-netmod-yang-module-versioning-09
ending on Monday, May 22nd. Neither draft has IPR declared. Here are the
direct links to the HTML version for these drafts:
- https://datatracker.
51 matches
Mail list logo
