On Fri, May 17, 2024 at 2:46 AM Qin Wu wrote:
> *发件人:* Andy Bierman [mailto:a...@yumaworks.com]
> *发送时间:* 2024年5月14日 1:28
> *收件人:* Qin Wu
> *抄送:* Kent Watsen ; netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
&g
On Sat, May 11, 2024 at 11:01 PM Qin Wu wrote:
> *发件人:* Andy Bierman [mailto:a...@yumaworks.com]
> *发送时间:* 2024年5月11日 1:10
> *收件人:* Qin Wu
> *抄送:* Kent Watsen ; netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
&
ystem.
-Qin
>
Andy
> *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2024年2月21日 8:18
> *收件人:* Kent Watsen
> *抄送:* netmod@ietf.org
> *主题:* Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
>
>
>
>
>
>
>
> On
Hi,
"No, I'm not aware of any IPR that applies to this draft”
Andy
On Mon, Apr 29, 2024 at 3:05 PM Kent Watsen wrote:
> Authors, Contributors, WG,
>
> As a prerequisite for the WGLC on this document:
>
> Guidelines for Authors and Reviewers of Documents Containing YANG
> Data Models
On Tue, Apr 16, 2024 at 7:01 AM Benoit Claise
wrote:
> Hi Andy,
>
>
> On 3/21/2024 5:35 PM, Andy Bierman wrote:
>
> Hi,
>
> The presentation yesterday helped me understand the motivation for this
> work.
> Seems simple enough, but rife with unintended consequenc
config files to mean 'comment to end
of line', so this syntax would be a problem.
The "module-name@revision-date" pattern is used by several tools already.
I don't think changing the file-naming convention for YANG 1.1 is a good
idea.
It should be in a separate Experimental RFC.
Reg
ine a file naming scheme for
YANG 2.0
since it does not exist and will probably never exist.
> Regards,
> Rob
>
Andy
>
>
>
>
> *From: *netmod on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Date: *Wednesday, 3 April 2024 at 19:07
> *To: *Joe Clarke (j
Hi,
On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke)
wrote:
>
>
>
>
> *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 Versio
On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke)
wrote:
> 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
Hi,
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 tools is OK.
I do not
ools must support.
> Best,
>
> Jean
>
Andy
>
>
> *From:* netmod *On Behalf Of *Andy Bierman
> *Sent:* Thursday, March 21, 2024 4:35 PM
> *To:* NetMod WG
> *Subject:* [netmod] comments on draft-jouqui-netmod-yang-full-include
>
>
>
> Hi,
>
>
>
Hi,
The presentation yesterday helped me understand the motivation for this
work.
Seems simple enough, but rife with unintended consequences.
RFC 8528 does a good job of dealing with most of these issues, but it is
not a design-time
modification like this draft is proposing.
I would like to see
> ([1], see [2], where also the issues were created) and in
> draft-ietf-core-comi-17.
>
> [1]: https://github.com/core-wg/comi
> [2]: https://github.com/core-wg/comi/commits/main/
>
> On 2023-09-07, at 22:28, Andy Bierman wrote:
> >
> > Hi,
> >
> > I have
On Sat, Mar 16, 2024 at 2:41 AM Christian Hopps wrote:
>
>
> > On Mar 15, 2024, at 19:13, Per Andersson (perander)
> wrote:
> >
> > Christian Hopps on Friday, March 15, 2024 20:10:
> >>> On Mar 15, 2024, at 13:26, mohamed.boucad...@orange.com wrote:
> >>>
> >>> Re-,
> >>> I’m not sure to agree
ince the
YANG compiler does not care which prefix is used.
The naming convention already established is that the SDO prefix (ietf or
iana) is not used.
It would not help readers to change it now.
/js
>
Andy
>
> On Fri, Mar 15, 2024 at 08:22:03AM -0700, Andy Bierman wrote:
> &g
that have been
> >previously published.
> >
> > NEW:
> >Prefix values SHOULD be prefixed with “ietf-“ for IETF modules and
> >“iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
> >too long and SHOULD NOT conflict with known modules that have
Hi,
I cannot find this email wrt/ short prefixes
- (short/uniqueness of prefixes
Other SDOs are using a prefix in their prefixes (e.g. openconfig).
It is common for servers to have both "if:interfaces" and
"oc-if:interfaces" subtrees.
It might be a good idea to have a guideline that all
On Tue, Mar 12, 2024 at 9:15 AM Jan Lindblad (jlindbla) wrote:
> Qiufang,
>
> I'm sorry to say I'm strongly against WGLC at this time because of point
> #2 below.
>
> One of the great contributions to network automation that YANG has brought
> is that clients now have a fair chance at computing
On Tue, Mar 12, 2024 at 7:28 AM Per Andersson (perander)
wrote:
> Andy Bierman on Tuesday, March 12, 2024 15:14:
> > On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad j...@tail-f.com>> wrote:
> >> Then we have the other thing with RESTCONF where the module names are
&g
On Tue, Mar 12, 2024 at 6:58 AM Jan Lindblad wrote:
> Jürgen,
>
> You have been in the YANG circles long enough to remember the basic
> tenets.
>
>YANG values the time and effort of the
>readers of models above those of modules writers and YANG tool-chain
>developers.
>
> In this
On Thu, Feb 22, 2024 at 9:42 AM Kent Watsen wrote:
> NETMOD WG,
>
> This email begins a 2-week adoption poll for:
>
> YANG Metadata Annotation for Immutable Flag
> https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09
>
>
I support the problem statement.
The solution has minor
default. In my experience, one of the most common YANG
> modeling issues is when people model a leaf foo, which isn't mandatory, has
> no default and the description statement does not say what happens if the
> leaf is not set. In many cases, there is a sort of natural meaning, but
> with b
On Tue, Mar 5, 2024 at 1:39 AM Jürgen Schönwälder
wrote:
> Hi Med,
>
> I believe it is a misconception that text not written in capital letters
> is not normative. I also believe we need _guidelines_ on the choice of
> identifiers like prefixes and not hard rules.
>
> Prefixes do not have to be
s-for-authors-and-reviewers-of-documents-containing-yang-data-models-00
>
>
> -Message d'origine-
> De : I-D-Announce De la part de
> internet-dra...@ietf.org
> Envoyé : mercredi 28 février 2024 10:01
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D
/datatracker.ietf.org/meeting/117/materials/slides-117-netmod-7-guidelines-for-authors-and-reviewers-of-documents-containing-yang-data-models-00
>
>
> -Message d'origine-
> De : I-D-Announce De la part de
> internet-dra...@ietf.org
> Envoyé : mercredi 28 févri
erent than the config. In that case a on would
be useful.
If not, then the foo-state module is not even relevant.
Andy
On Tue, Feb 20, 2024 at 10:34 PM wrote:
> Hi Andy,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Andy
On Tue, Feb 20, 2024 at 8:03 AM Kent Watsen wrote:
> Juergen, Tom, Andy,
>
> Gentle reminder.
>
>
I read draft-11. It is an improvement. No objections.
There are 4 IETF tags defined: metrics, logs, traces, info
I do not see much value in these standard tags, but more guidance and
explanation
n-NMDA 'state' module? Most deployments (90%?) are non-NMDA.
The motivation will always be to allow this 90% to retrieve the operational
values of specific configuration data.
Cheers,
>
> Med
>
>
>
Andy
> *De :* Andy Bierman
> *Envoyé :* lundi 19 février 2024 19:58
> *À :*
/B4TUQZf7jud5wqrBwzEqEND6-rw/
>
>
> *De :* netmod *De la part de* Kent Watsen
> *Envoyé :* vendredi 16 février 2024 21:55
> *À :* Andy Bierman
> *Cc :* netmod@ietf.org
> *Objet :* Re: [netmod] Rfc8407 - what does this text mean?
>
> Hi Andy,
>
> Thanks for the speed
On Fri, Feb 16, 2024 at 12:07 PM Kent Watsen wrote:
> NETMOD,
>
> An IESG member reviewing one of my drafts flagged a section I had written
> to satisfy this text from
> https://datatracker.ietf.org/doc/html/rfc8407#section-3.5:
>
>If the document contains a YANG module(s) that is
On Tue, Jan 30, 2024 at 8:55 AM Jason Sterne (Nokia) wrote:
> Hi WG,
>
> (and in particular to those who attended the interim).
>
>
>
> The summary below mostly matches my memory of the discussions, but I don’t
> really remember us concluding on this:
>
>
>
> The WG agreed to let 7950-bis
ot a valid state data tree, so this section does not apply.
o If the constraint is defined on state data, it MUST be true in a
valid state data tree.
Andy
Thanks.
>
>
> No?
>
> Cheers,
> Med
>
> *De :* netmod *De la part de* Acee Lindem
> *Envoyé
On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem wrote:
> Along the same lines, what is the sentiment for “mandatory true” data
> nodes for operational state (i.e., “config false” nodes)? Does this make
> sense to identify data nodes the must be returned if the parent node is
> returned?
>
>
What
y, January 19, 2024 9:16 AM
> *To:* Andy Bierman
> *Cc:* netmod@ietf.org; Italo Busi
> *Subject:* Re: [netmod] Is changing the type with union a BC change?
>
>
>
> You don't often get email from jason.sterne=40nokia@dmarc.ietf.org. Learn
> why this is important <http
Hi,
On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia) wrote:
> Hi Italo,
>
>
>
> IMO RFC7950 Section 11 makes the second case NBC (and I remember it being
> confirmed on this list in the past). It may not turn out to be impactful
> depending on the client design (and if only XML is used)
t; >
> > Recommended-min does not affect conformance and is not mandatory. So a
> server, toolchain, etc can continue to select the "most recent revision"
> even if that revision is older than the recommended-min.
> >
> > Jason
> >
> >
> > > -
this work make it better (IMO).
Look forward to implementing the RFC.
> If anyone feels that you can’t live without the new filename format
> specified (e.g. my-mod...@3.0.1.yang) now is the time to speak up.
> Otherwise we’ll remove it from the next iteration of Module Versioning.
>
On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke) wrote:
> 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
On Wed, Oct 25, 2023 at 11:49 AM Jürgen Schönwälder
wrote:
> I strongly disagree. You can add additional file names, you can't
> soften the existing SHOULD to a conditional SHOULD.
>
>
+1
Getting tools to handle the file naming patterns defined in RFC 7950 took a
long time.
It would be
On Thu, Sep 14, 2023 at 11:46 AM Jürgen Schönwälder
wrote:
> If the poll does not say what you want it to say, then the poll is
> broken.
>
> Right now, I see the following solution proposals floating around:
>
> 1) We change a single sentence in RFC 7950 and put an end to a
>multi-year
On Thu, Sep 14, 2023 at 10:09 AM Acee Lindem wrote:
>
>
> On Sep 14, 2023, at 12:40, Andy Bierman wrote:
>
>
>
> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem wrote:
>
>>
>>
>> > On Sep 13, 2023, at 10:36, Ladislav Lhotka > 40nic...@dmarc.ietf.org
On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem wrote:
>
>
> > On Sep 13, 2023, at 10:36, Ladislav Lhotka 40nic...@dmarc.ietf.org> wrote:
> >
> >
> >
> > Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):
> >> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:
> >>> Jernej,
> >>>
> >>> Hat off for
On Tue, Sep 12, 2023 at 4:09 PM Kent Watsen wrote:
> [All, don’t forget to vote, discussion here doesn’t count!
> https://notes.ietf.org/netmod-2023-sept-poll]
>
>
> On Sep 12, 2023, at 12:06 PM, Andy Bierman wrote:
>
> So there is choice between:
>
> (A) YANG 1.1
On Tue, Sep 12, 2023 at 8:54 AM Reshad Rahman wrote:
>
>
> On Tuesday, September 12, 2023, 11:23:55 AM EDT, Andy Bierman <
> a...@yumaworks.com> wrote:
>
>
>
>
> On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen wrote:
>
> WG,
>
> Please help the YANG-ve
On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen wrote:
> WG,
>
> Please help the YANG-versioning effort move forward by participating in
> the following poll:
>
> - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login
> required)
>
>
The draft proposed to change many specific MUST and
On Sun, Sep 10, 2023 at 11:59 AM Michael Richardson
wrote:
>
> Andy Bierman wrote:
> > I do not have time to do another full review of this draft.
> > These are high-level comments.
>
> > ## document scope is too large
>
> > The draf
On Tue, Sep 5, 2023 at 5:42 AM Kent Watsen wrote:
> NETMOD WG,
>
> This email begins a 2-week adoption poll for:
> https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08
>
> There is no known IPR on this draft (IPR call
>
Hi,
I do not have time to do another full review of this draft.
These are high-level comments.
## document scope is too large
The draft should be split into 2 or 3 drafts.
1) SID File Definition
2a) SID Management Procedures
2b) Initial SID File Definitions
## document scope is not
Hi,
I have some minor comments about this draft.
I did not find any major issues. It is almost ready for publication.
Andy
# comments on draft-ietf-core-comi-16
## sec 2.3
Examples of each media type would be helpful here
## sec 2.4
It is not clear how any interoperability would be
SHOULD NOT is confusing and unnecessary. "SHOULD
> NOT" allows a thing while discouraging it.
>
> Thanks,
> Chris.
>
>
Andy
> >
> > be agreeable?
> >
> > Regards Balazs
> >
> >
> >
> > From: Andy Bierman
>
On Sun, Jul 23, 2023 at 6:52 PM Balázs Lengyel wrote:
> Hello,
>
> While I fully agree with Jason’s comments, I would like to state both as
> an Ericsson guy and as a 3GPP delegate that for us Key issue 2 (multiple
> label schemes) is not important. The only important point is that it should
>
d role out a new version of the modules every few months. These can not
>
> live without some NBC changes.
>
> A more fine grained versioning system is required.
>
>
>
> Regards Balazs
>
>
>
> *From:* netmod *On Behalf Of *Andy Bierman
> *Se
ll of the YANG
update rules.
Changing the normative text to SHOULD NOT instead of MAY does not require
any specification of a bugfix.
Regards Balazs
>
Andy
>
>
> *From:* netmod *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, 19 July, 2023 10:13
> *To:* Martin Björklund
>
ck using the current "MAY" (3.1, para 2) is not a good idea.
Jason
>
Andy
>
>
> *From:* Andy Bierman
> *Sent:* Wednesday, July 19, 2023 1:13 PM
> *To:* Martin Björklund
> *Cc:* Jason Sterne (Nokia) ; netmod@ietf.org
> *Subject:* Re: [netmod] Y
On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund wrote:
> What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
>
>
This is the approach I also suggested on the mailing list.
> - As it works today; the IETF *has* published bugfixed modules that break
> the
> rules. (and many
On Mon, Jun 26, 2023 at 2:34 AM Qin Wu wrote:
> Andy:
>
> Sorry for late followup, please see my reply inline below.
>
>
>
> *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2023年4月20日 2:39
> *收件人:* Kent Watsen
> *抄送:* netmod@ietf.org
>
Hi,
It is not really clear how this extension works.
This extension is used to specify the format and semantics of the 'label'
and 'recommended-min'
argument string contents.
Q1) What specific requirements (if any) are being addressed by this
solution?
On Wed, Jun 14, 2023 at 3:00 AM Martin Björklund wrote:
> "Rob Wilton (rwilton)" wrote:
> > 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
> >
ules.
If YANG 1.2 is ever developed then the module update rules can officially
change.
Jason
>
>
>
Andy
> *From:* Andy Bierman
> *Sent:* Tuesday, June 13, 2023 12:45 PM
> *To:* Jason Sterne (Nokia)
> *Cc:* Martin Björklund ; rwilton=
> 40cisco@dmarc.ietf.org; net
by seeing where that grouping is used,
> whether the client uses those nodes, etc).
>
Perhaps an example showing an NBC change to an imported module should be
added.
>
> Jason
>
Andy
>
>
> *From:* netmod *On Behalf Of *Andy Bierman
> *Sent:* Friday, June
ions are useful to YANG 1.0 and YANG 1.1
> modules.
>
>
>
> I still feel the work is a good practical step forward for the YANG
> ecosystem.
>
>
>
> Jason
>
>
>
> *From:* netmod *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, June 7, 2023 4:49 PM
> *
ing A(2.0.0) == sid-file-version=2
It is valid for a server to use any 1 of the 3 revisions of module A.
Of course, this is a "hello world" example. A "real world" example will be
much more complicated.
Allowing NBC changes to YANG makes the problem more complicated
Hi,
It is not clear how the new drafts work for changes in imported groupings.
This is a very common design pattern.
module A {
// version 1.0.0
grouping A {
leaf one { type string; }
leaf two { type string; }
}
}
module A {
// version 1.1.0
grouping A {
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
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"
On Thu, Jun 1, 2023 at 1:55 PM Kent Watsen wrote:
> Hi Quifang,
>
> The latest update looks very good to me - IMO, ready for adoption.
>
> Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been
> addressed?
>
>
IMO the problem statement and solution are still rough and unclear.
Hi,
No changes are needed.
The notification definition says each leaf will be set to a value that
matches an instance of the leafref path.
The 'current()' linkage in your example links the sibling 'ifname' leaf to
select a matching instance.
That is not relevant to this notification example.
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:
>> > >
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
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
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
odule versioning draft also updates that the change from current or
> deprecated to obsolete is NBC. Going “obsolete” is an impact to a client.
>
>
>
> Jason
>
>
>
>
>
> *From:* netmod *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, May 9, 2023 2:06 PM
> *To:
Hi,
On Sat, May 13, 2023 at 12:02 PM Jason Sterne (Nokia) <
jason.ste...@nokia.com> wrote:
> Hi Frank,
>
>
>
> The table just after the text has this:
>
>
>
> +--+--+-+
>
>| substatement | section | cardinality |
>
>
Hi,
Most of the document focuses on the administrative details that will
be required to update a YANG module. (Lots of them).
My concern is with YANG 1.1 Co-existence and deployment of this new RFC.
(Sec 3.1)
On Tue, Apr 25, 2023 at 6:15 AM Jürgen Schönwälder
wrote:
> On Tue, Apr 25, 2023 at 12:46:05PM +, Kent Watsen wrote:
> >
> >
> > > Which merge fails?
> >
> > + =
>
> So far this merge step does not exist (and it may be bad if it would
> exist). The WGs need to think very careful about
On Mon, Apr 24, 2023 at 7:48 AM Carsten Bormann wrote:
> On 2023-04-24, at 14:20, Michal Vasko wrote:
> >
> > canonical
>
> Hi Michal,
>
> I don’t know what exactly “canonical” means here.
>
>From the date-and-time typedef:
The canonical format for date-and-time values with a known time
Hi,
Adding a couple missed comments inline...
On Wed, Apr 19, 2023 at 11:38 AM Andy Bierman wrote:
>
>
> On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen wrote:
>
>> This email begins a two-week WGLC on:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-i
On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen wrote:
> This email begins a two-week WGLC on:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>
> Please take time to review this draft and post comments by May 2nd.
> Favorable comments are especially welcomed.
>
>
I have
On Fri, Apr 14, 2023 at 11:45 AM Jürgen Schönwälder
wrote:
> On Fri, Apr 14, 2023 at 03:23:03PM +, Jason Sterne (Nokia) wrote:
>
> > IETF and vendor models are already doing NBC changes. The versioning
> > work is mostly just adding a way to indicate that to users/clients
> > when it
On Fri, Apr 14, 2023 at 7:33 AM Italo Busi wrote:
> Hi Jeff,
>
>
>
> I agree with you on the preference for hex-string versus binary in YANG
>
>
>
> I also agree with you concerns with hexdump, but parsing has some issues
> when something is unknown (these are the issues that have triggered your
hing to make an NBC change to fix a mistake.
Quite another to use NBC changes are part of the data model design.
Jason
>
Andy
>
> > -Original Message-
> > From: Jürgen Schönwälder
> > Sent: Friday, April 14, 2023 2:12 AM
> > To: Andy Bierman
> > Cc: Ja
On Thu, Apr 13, 2023 at 2:00 PM Jason Sterne (Nokia)
wrote:
> Hi Jeff,
>
>
>
> We avoided getting into subtleties about “severity” of an NBC change (hard
> enough to just get agreement on basic rules). But I do think it is useful
> to come up with changes and approaches that have lower impact on
On Thu, Apr 13, 2023 at 1:48 PM Jeffrey Haas wrote:
> Andy,
>
> On Apr 13, 2023, at 4:42 PM, Andy Bierman wrote:
>
>>
>> Repeating my question to Acee... did you read the draft? This isn't a
>> theoretical use case.
>>
>
> Seeing no response, I'll assu
On Thu, Apr 13, 2023 at 1:27 PM Jeffrey Haas wrote:
>
>
> On Apr 13, 2023, at 3:59 PM, Andy Bierman wrote:
> It is somewhat strange to model "unknown-bits" as if it was a property of
> the data model.
> Protocols generally have version detection or rules (e.g. rec
On Thu, Apr 13, 2023 at 12:17 PM Jeffrey Haas wrote:
> Andy,
>
>
> > On Apr 12, 2023, at 1:27 PM, Andy Bierman wrote:
> > I unclear on the "ease of use" gained by using YANG bits to define bit
> positions.
> > IMO is would be much easier to use a proto
On Wed, Apr 12, 2023 at 10:04 AM Jeffrey Haas wrote:
> Tom,
>
>
> > On Apr 12, 2023, at 12:44 PM, tom petch wrote:
> >> The reason to disconsider it is that within the same leaf, the value
> "changes meaning" once you end up with the new identity for the value when
> it's assigned and then end
idnits would not be very
interesting.
What is cited here are excerpt from RFC8407.
>
>
>
> Cheers,
>
> Med
>
Andy
>
>
> *De :* Andy Bierman
> *Envoyé :* vendredi 7 avril 2023 17:36
> *À :* RFC Errata System
> *Cc :* BOUCADAIR Mohamed INNOV/
Hi,
This errata cites a documentation convention that was created after RFC
8407 was published.
It is unfortunate that this RFC is an ad-hoc mix of YANG Usage Guidelines
and IETF Documentation Guidelines. The latter is much less stable.
Andy
On Fri, Apr 7, 2023 at 5:50 AM RFC Errata System
On Thu, Apr 6, 2023 at 4:09 AM tom petch wrote:
> I do not know what we are talking about. Perhaps I will know if and when
> I see minutes from the last IETF meeting. Meanwhile
>
> From: netmod on behalf of Jürgen Schönwälder
>
> Sent: 05 April 2023
On Tue, Mar 28, 2023 at 2:37 PM Kent Watsen wrote:
> Hi Andy,
>
> No customer would ever let us take away this tenet, no matter what RFC
> comes out.
>
>
> What tenet? That is valid or that the representation returned
> to clients is valid?
>
both. But I think the expectation is for non-NMDA
On Sun, Mar 26, 2023 at 7:04 PM Jan Lindblad wrote:
> Rob, Jürgen, Kent, WG,
>
> I am strongly opposed to giving up the idea that running must always be
> valid. This is one of the landmark properties that has made NETCONF the
> most useful management interface for network automation ever. For
On Thu, Mar 23, 2023 at 5:11 AM tom petch wrote:
> From: netmod on behalf of Jürgen Schönwälder
>
> Sent: 23 March 2023 11:13
>
> On Wed, Mar 22, 2023 at 01:31:43PM +, Rob Wilton (rwilton) wrote:
> > Hi Jürgen,
> >
> > Thanks for the draft. Please see my AD review comments below, except
>
other cases where uri could be an appropriate type to
> use for a key …
>
>
>
It's just another 'pattern' to check to the YANG compiler.
If 'uri' is appropriate then use it. Same goes for 'uuid'.
> Thanks, Italo
>
Andy
>
>
> *From:* Andy Bierman
> *Sent:*
On Fri, Jan 13, 2023 at 9:31 AM Michael Richardson wrote:
>
> Andy Bierman wrote:
> >> Fengchong (frank) wrote:
> >> > Hi Michael,
> >> > You can use augment-structure to extend a yang structure.
> >>
> >> You can't
e and the length sub-
> > statement is optional
> > >
> > > While it is true that unrestricted strings can cause an implementation
> to run
> > out of memory, it is also true that in some cases it is not trivial to
> define the
> > maximum length for a string
er SHOULD be used instead of string for key
leafs.
That does not mean yang-identifier is always the most appropriate type to
use for a key.
>
>
> I think that what I have understood would make sense
>
>
>
> Any other opinion or suggestion?
>
>
>
> Thanks, Italo
On Thu, Jan 12, 2023 at 8:10 AM Michael Richardson
wrote:
>
> Fengchong (frank) wrote:
> > Hi Michael,
> > You can use augment-structure to extend a yang structure.
>
> You can't use augment-structure to extend in-place an existing yang
> structure
> Augment-structure produces a new
On Thu, Jan 12, 2023 at 8:33 AM Jürgen Schönwälder <
j.schoenwael...@jacobs-university.de> wrote:
> On Thu, Jan 12, 2023 at 07:08:05AM -0800, Andy Bierman wrote:
> >
> > Just because the escaped string is "safe" inside a NETCONF protocol
> message
> >
;
>
>
> What is your view/opinion about using the string type in IETF standard
> YANG models?
>
>
>
> Thanks, Italo
>
>
>
> *From:* Andy Bierman
> *Sent:* mercoledì 21 dicembre 2022 00:30
> *To:* Martin Björklund
> *Cc:* ie...@btconnect.com; netmod@ietf.org
&
On Mon, Dec 19, 2022 at 5:15 AM Martin Björklund wrote:
> tom petch wrote:
> > From: Martin Björklund
> > Sent: 19 December 2022 12:18
> > To: tom petch
> >
> > tom petch wrote:
> > > draft-ietf-opsawg-sap-12
> > > defines a grouping sap-list which uses grouping sap-entry. The
> groupings
1 - 100 of 1099 matches
Mail list logo
