On 2020-05-05 11:55, Juergen Schoenwaelder wrote:
> On Tue, May 05, 2020 at 11:45:41AM +0200, Per Hedeland wrote:
>> On 2020-05-05 11:00, Martin Björklund wrote:
>>> Hi,
>>>
>>> If we were to redo YANG, I would prefer to have a single statement
>>> &qu
On 2020-05-05 11:00, Martin Björklund wrote:
> Hi,
>
> If we were to redo YANG, I would prefer to have a single statement
> "operation", either on the top-level, or tied to a node.
So, no rpc statement, and thereby no possibility to extend NETCONF
with new RPCs? (Or to be precise, YANG would exten
On 2020-02-17 23:14, Christian Hopps wrote:
>
>
>> On Feb 17, 2020, at 4:42 PM, Randy Presuhn
wrote:
>>
>> Hi -
>>
>> On 2/17/2020 11:47 AM, Christian Hopps wrote:
On Feb 17, 2020, at 11:51 AM, Randy Presuhn
wrote: Hi - On 2/17/2020 3:15 AM, Christian Hopps
wrote: ...
> BTW, I did lo
On 2020-02-17 20:47, Christian Hopps wrote:
>
>
>> On Feb 17, 2020, at 11:51 AM, Randy Presuhn
wrote:
>>
>> Hi -
>>
>> On 2/17/2020 3:15 AM, Christian Hopps wrote:
>> ...
>>> BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once
dealing with LFs and CRs which lucky for us is
On 2019-11-04 14:46, Schönwälder, Jürgen wrote:
Hi,
what about this wording :
[...]
A node-instance-identifier value is an unrestricted
YANG instance-identifier expression or the special
value '/', which refers to the entire accessible tree.
[...]
Yes, that
On 2019-11-04 11:32, Schönwälder, Jürgen wrote:
Hi,
this may be resolved by adding
The special value '/' refers to the entire accessible tree.
to the description statement. Does this work for you?
Hm, it seems to me that this would conflict with this part of the
description:
A
On 2019-07-17 14:34, Juergen Schoenwaelder wrote:
Its the first half of the sentence in my copy of RFC 7950.
It believe that there is a problem with English language both in Qin's
understanding of the original text (which is correct also in my
opinion) and in his explanation of his (mis)underst
the 'default'
statement.
You should of course still *describe* the behavior, and text in a
'description' statement is just as "normative" as a 'default' statement,
"just" not machine-readable.
--Per
Regards,
- Xufeng
[Forwarding Per's r
On 2019-06-09 17:28, Juergen Schoenwaelder wrote:
YANG does not have 'levels'. This seems to be an ISIS specific
question you should ask on the ISIS list.
AFAIK, this list is not restricted to discussions of what YANG "is" or
"has", but also covers (at least) how YANG can be used, and what the
On 2019-04-18 10:41, Ladislav Lhotka wrote:
On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote:
On 2019-04-18 09:40, Ladislav Lhotka wrote:
Juergen Schoenwaelder writes:
On Wed, Apr 17, 2019 at 09:35:51PM +0200, Kristian Larsson wrote:
I wonder though, isn't ipX-address-and-prefix-l
o your (original) question would in that case be
"yes" (at least for YANG 1.1 modules...).
--Per Hedeland
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
On 2018-11-22 16:37, Ladislav Lhotka wrote:
> On Thu, 2018-11-22 at 15:31 +, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>> From what I can understand below, none of this debate affects the conclusion
>> that choice & case identifiers do *not* appear in:
>> - leafref paths
>> - must statements
>>
On 2018-11-07 16:56, Qin Wu wrote:
> -®öö-
> Ñöº: netmod [mailto:netmod-boun...@ietf.org] ãh Per Hedeland
> Ñöô: 2018t117å 15:57
> 6öº: Juergen Schoenwaelder
> : NETMOD WG
> ;: Re: [netmod] for a future rfc6991bis
>
> On 2018-11-07 09:34, Juergen Schoen
On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:
For the range, if the defintion can cover the our range(0..99.),
it will be acceptable. In your suggestion below, does that mean the
base defintion is without range, while refined
On 2018-07-15 13:11, Robert Wilton wrote:
Hi Kent,
I don't think that this is a valid use of augment - I thought that augment can
only add news data nodes, not add extra sub statements to existing ones.
Well, it is valid (though not if "foo" is a leaf), but you are right,
and it doesn't do wh
On 2018-03-05 16:06, Ladislav Lhotka wrote:
> On Mon, 2018-03-05 at 15:49 +0100, Per Hedeland wrote:
>> On 2018-03-05 15:41, Ladislav Lhotka wrote:
>>> On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
>>>> Juergen Schoenwaelder wrote:
>>>>
On 2018-03-05 15:41, Ladislav Lhotka wrote:
> On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder wrote:
>>> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
>
> So it seems the running code got it right. ;-)
As the author of that
On 2018-02-26 23:02, Mahesh Jethanandani wrote:
On Feb 26, 2018, at 1:31 PM, Per Hedeland wrote:
On 2018-02-26 20:20, Mahesh Jethanandani wrote:
On Feb 26, 2018, at 9:01 AM, Per Hedeland mailto:p...@tail-f.com>> wrote:
[Adding Cc todraft-ietf-netmod-acl-mo...@ietf.org
<mailto:d
On 2018-02-26 20:20, Mahesh Jethanandani wrote:
On Feb 26, 2018, at 9:01 AM, Per Hedeland mailto:p...@tail-f.com>> wrote:
[Adding Cc todraft-ietf-netmod-acl-mo...@ietf.org
<mailto:draft-ietf-netmod-acl-mo...@ietf.org>]
On 2018-02-26 14:24, Ladislav Lhotka wrote:
Per Hedel
[Adding Cc to draft-ietf-netmod-acl-mo...@ietf.org]
On 2018-02-26 14:24, Ladislav Lhotka wrote:
> Per Hedeland writes:
>
>> Hi,
>>
>> A customer of ours using one of the draft versions of the
>> ietf-access-control-list module reported that it was not possible t
ot;;
- and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
there shouldn't be any element either, but that's another thing.)
So, is it the case that the derived-from()s should actually be
derived-from-or-self()s, or is the example wrong?
--Per Hedeland
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
tunnel and all
supporting te-tunnels and just pointers for supporting connections?
I really appreciate your help,
Igor
-Original Message-
From: Per Hedeland [mailto:p...@tail-f.com]
Sent: Monday, October 09, 2017 5:21 PM
To: Igor Bryskin
Cc: m...@tail-f.com; xufeng.liu.i...@gmail.
ot to a singls entity, but to a list
of entities, and the client might want to expand all of them into the joint get
response.
Igor
*From:*Per Hedeland
*To:*Martin Bjorklund,
*Cc:*Igor Bryskin,xufeng.liu.i...@gmail.com,netc...@ietf.org,netmod@ietf.org,
*Date:*2017-10-09 15:12:22
*Subjec
d allow for the client to optimize the number
of request-response iterations depending on application/use case.
Regards,
Igor
/martin
-Original Message-
From: Per Hedeland [mailto:p...@tail-f.com]
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin;
o the get request the server needs to
> provide the entire body of a datastore node pointed
> to by a leafref or just a pointer to said node, so that the node's body could
> be retrieved by a subsequent separate request. This is requested by
> implementors who want to optimise rhe n
On 2017-10-06 23:11, Xufeng Liu wrote:
During the design team discussion for TE and MPLS YANG modeling, we have received a request from implementers: How to minimize the number of NETCONF/RESTCONF RPCs to improve operation efficiency?
Especially for the case when the operator or client software n
On 2017-08-29 15:40, Lou Berger wrote:
>
>
> On August 29, 2017 9:03:22 AM Per Hedeland wrote:
>
>> On 2017-08-29 14:34, Lou Berger wrote:
>>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>>>> Lou Berger wrote:
>>>>> Lada,
>>
On 2017-08-29 14:34, Lou Berger wrote:
> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>> Lou Berger wrote:
>>> Lada,
>>>
>>>
>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
Lou Berger píae v Po 28. 08. 2017 v 09:40 -0400:
> Lada,
>
> On 8/28/2017 9:30 AM, Ladislav Lhotka wrot
On 2017-08-24 17:54, Ladislav Lhotka wrote:
> Per Hedeland writes:
>
>> I strongly agree with all of Juergen's statements, and disagree also
>> with the suggestion to include the parts of the text that he didn't
>> specifically disagree with. And I'd like
I strongly agree with all of Juergen's statements, and disagree also
with the suggestion to include the parts of the text that he didn't
specifically disagree with. And I'd like to add that the "lack of XSD
support" argument is pretty weak - there exists at least one freely
available implementatio
On 2017-08-23 20:09, Vladimir Vassilev wrote:
On 08/23/2017 03:36 PM, Juergen Schoenwaelder wrote:
On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
1) Email address. I understand that the full regex to validate all email
addresses is very complex, but checking that it at least c
On 2016-09-05 12:34, Martin Bjorklund wrote:
> RFC Errata System wrote:
>> The following errata report has been submitted for RFC7317,
>> "A YANG Data Model for System Management".
>>
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/
On 2016-09-02 00:14, Phil Shafer wrote:
> Martin Bjorklund writes:
>> See Section 1.1 (Summary of Changes from RFC 6020)
>
> I may be missing something but it says:
>
> o Allow "choice" as a shorthand "case" statement (see
> Section 7.9.2).
>
> which is definitely in 6020.
No, it isn'
On 2016-06-08 09:48, Martin Bjorklund wrote:
> Andy Bierman wrote:
>> On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder <
>> j.schoenwael...@jacobs-university.de> wrote:
>>
>>> On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote:
On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwael
On 2016-04-29 17:07, Ladislav Lhotka wrote:
>
>> On 29 Apr 2016, at 16:32, Per Hedeland wrote:
>>
>> On 2016-04-29 16:15, Ladislav Lhotka wrote:
>>>
>>>> On 29 Apr 2016, at 15:51, Per Hedeland wrote:
>>>>
>>>> On 2016-04-29 1
On 2016-04-29 16:15, Ladislav Lhotka wrote:
>
>> On 29 Apr 2016, at 15:51, Per Hedeland wrote:
>>
>> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>>
>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder
>>>> wrote:
>>>>
&g
On 2016-04-29 15:28, Ladislav Lhotka wrote:
>
>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder
>> wrote:
>>
>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>
>>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>>
>>
>> Yes, "type foo {}" has a restri
(it is the same there), if it isn't
too late.
--Per Hedeland
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
On 2016-04-05 22:33, Ladislav Lhotka wrote:
>
>> On 05 Apr 2016, at 16:32, Martin Bjorklund wrote:
>>
>> Ladislav Lhotka wrote:
>>>
On 05 Apr 2016, at 11:09, Martin Bjorklund wrote:
Andy Bierman wrote:
> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote:
>
>>
>>
parties" to define unique identities with a
common base, without the need for having a "global registry".
--Per Hedeland
module a {
namespace urn:a;
prefix a;
identity id;
identity x {
base id;
}
}
module b {
namespace urn:b;
prefix b;
import a {
pr
On 2015-05-21 19:46, Andy Bierman wrote:
> On Thu, May 21, 2015 at 10:38 AM, Per Hedeland wrote:
>> On 2015-05-21 19:14, Andy Bierman wrote:
>>> On Thu, May 21, 2015 at 7:37 AM, Ladislav Lhotka wrote:
>>>>
>>>> RFC 6020 also states that must and when
t have one for that, but these are:
A member type can be of any built-in or derived type, except it MUST
NOT be one of the built-in types "empty" or "leafref".
I believe they're described as CLR in the issues doc...
--Per Hedeland
_
42 matches
Mail list logo