specific
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
___
netmod mailing list
netmod@ie
pattern right.
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
___
netmod mailing list
host' in your private list archive
(I can't find it in the IETF archive)
- I can't tell for sure that Lada's proposal is (i) correct and (ii)
not breaking anything
- Proposal: ?
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200
gue seems to be down. :-(
- Proposal: do not add a percentage type since it is trivial to
define a context specific percentage type that matches range and
precision requirements (and there is already a definition in RFC
8294 for those who need exactly that definition).
--
Juergen Schoenwael
, perhaps the Universal Postal Union.
- Options: (i) do nothing or (ii) add a country code definition
only or (iii) add both a country code definition and a postal
code definition (which might be to some extend vague)
- Proposal: do nothing
--
Juergen Schoenwaelder Jacobs
definition of node-instance-identifier.
- Options: (i) Leave this definition as it is. (ii) Detail how this
type work with encodings that use module names instead of prefixes
to qualify names.
- Proposal: ?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49
the user of the current session.")
- This interacts with the definition of xpath1.0 concerning the
context and the use of module names as prefixes.
- Proposal: ?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28
re
the timezone is implicit.
- Proposal: Make the timezone optional (adding text describing the
implications, i.e., comparisons may be surprising). Align as much
as possible with the XML schema definition concerning the
canonical format.
/js
--
Juergen Schoenwaelder
resentation time" probably is
not a good thing.)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
___
tells
> how to parse it and interpret. So either the text representation
> conforms to that precise type or otherwise it is an error. There is no
> ambiguity.
>
An annotation that is only understood by some tools and not by others
is creating a new problem since different tools now start to
out it, it is not ideal, but
> it will stay the way it is". I was hoping for something better.
>
> Regards,
> Michal
>
> On Thursday, July 16, 2020 17:55 CEST, Juergen Schoenwaelder
> wrote:
>
> > On Thu, Jul 16, 2020 at 04:24:43PM +0200, Michal Vaško wrote:
nd I can see
> this having possibly quite nasty consequences.
>
This is known and has already be known when the JSON format was
standardized. Whether it is a feature or a bug (and if so where
the bug is) depends on whom you talk to.
/js
--
Juergen Schoenwaelder Jacobs Unive
On Wed, Jul 08, 2020 at 04:53:52PM +, Rob Wilton (rwilton) wrote:
>
>
> > -Original Message-
> > From: Juergen Schoenwaelder
> > Sent: 08 July 2020 17:44
> > To: Rob Wilton (rwilton)
> > Cc: Christian Hopps ; NetMod WG
> > Subject: Re:
g
> for them, and a JSON/XML encoding of them is seemingly trivial.
>
> Regards,
> Rob
>
>
> > -Original Message-
> > From: netmod On Behalf Of Juergen Schoenwaelder
> > Sent: 07 July 2020 12:25
> > To: Christian Hopps
> > Cc: NetMod WG
alluding to plain JSON where you encode a number as a number
until you realize that some numbers must be encoded as strings to
avoid surprises. RFC 7951 does this for YANG defined data.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Ca
uch newer) has numbers that start to become interesting
when you need more precision, a simple 64-bit counter starts falls
apart in JSON.
I can't tell how many of the "backward incompatible" changes are due
to picking too restrictive types.
/js
--
Juergen Schoenwaelder J
ents what he/she likes? That would be a big
step backward since every implementation will then interpret the
numbers differently.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fa
ring
representation. But what matters is how the strings are interpreted
since computers internally often do not use strings when it comes to
numbers or addresses or ...
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen
_____
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacob
nternet-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 : Common YANG Data Types
> > Author : Juergen Schoenwaelder
> > Filename : draft-ietf-netmod-rfc6991-bi
nally follows the following rules:
o The leftmost (top-level) data node name is always in the
namespace-qualified form.
o Any subsequent schema node name is in the namespace-qualified
form if the node is defined in a module other than its parent
node, and the s
On Wed, Jun 24, 2020 at 09:56:11AM +0200, Ivaylo Petrov wrote:
> Hi Juergen,
>
> Thank you very much for your new comments! Please find my answers below.
>
> On Tue, Jun 23, 2020 at 6:59 PM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>
ier also includes prefixes
> > instead of module names.
> >
>
> [IP]: I might be misunderstanding your statement or the text in RFC 7951,
> but if I read sec 6.11. from RFC 7951 correctly,
>
> The leftmost (top-level) data node name is always in the
> namespace-qualifi
eems to be needed, the most important thing is for
the profile SDO to talk to the other SDO. Modularity and reuse can
often be improved if SDOs talk to each other and work together.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 |
1.1.0
> in this case.
>
> The main problems covered:
> - ensure all intermediate versions have a unique identifier (in case there
> are pre-release implementations, etc)
> - ensure the final version has the correct YANG Semver
>
/js
--
Juergen Schoenwaelder Jaco
e selected for modules
> in IETF RFCs that are being updated (e.g. a "bis" version is under
> development).
>
> (should we drop the "in IETF RFCs" ? )
>
> Jason
>
> ___
> netmod mailing list
> netmod@iet
ly the names bound to
the position). All other bits default to 0.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-univ
On Tue, May 05, 2020 at 12:06:34PM +0200, Per Hedeland wrote:
> 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,
> >>>
> &
> So, no rpc statement, and thereby no possibility to extend NETCONF
> with new RPCs? (Or to be precise, YANG would extend NETCONF with
> exactly one RPC, called "operation"?)
>
OLD
rpc foo {}
list something { action bar {} }
NEW
operation foo {}
list something { oper
On Tue, May 05, 2020 at 11:00:11AM +0200, 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.
>
+1
/js
--
Juergen Schoenwaelder Jacobs University Br
ta node in the operational state datastore. It specifies
> > >>> from where the node originated. If not specified for a given
> > >>> configuration data node, then the origin is the same as the
> > >>> origin of its parent node in the data t
___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 2875
probably be documented in
> section 3, with a sentence in section 6 to explain that is how it is
> protected.
>
Why would a factory-default datastore be more sensitive than ?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus
alue as two 3-octet values in YANG.
> I wonder whether it would make sense to provide something like:
>
> type uint24 {
>type uint32;
>range 0..16777215;
> }
>
> in ietf-inet-types as a common base type for such definitions.
If we add such a definition, it lik
On Fri, Apr 17, 2020 at 03:16:58PM +, Kent Watsen wrote:
> [changing subject line]
>
> > On Apr 17, 2020, at 4:16 AM, Juergen Schoenwaelder
> > wrote:
> >
> > On Fri, Apr 17, 2020 at 01:13:54AM +, Kent Watsen wrote:
> >>
> >>>>&g
sorts, whereby having whitespace didn’t make
> sense.
>
This type does not eliminate whitespace, it only reduces multiple
consecutive whitespaces to one.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587
schema node identifier? Or is
> > the difference between the two how namespaces are represented?
> >
>
> [IP]: I might have misunderstood something, but my understanding is that
> the prefix related to a module could be changed during an import, whereas
> here we really want
t; True, but there is a related DISCUSS under "typedef xpath1.0”...
>
I know.
> >> PS: the "token” type add discussion from before never completed (again,
> >> modeled after xsd:token)
>
> What about this?
>
What would this type be good for
;nacm:node-instance-identifier”. This typedef seems
> generally useful, would it make sense to move to rrc6991-bis?
>
> PS: the "token” type add discussion from before never completed (again,
> modeled after xsd:token)
>
> Kent // contributor
>
--
Juergen Schoenwae
yslog-model-26).
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
___
netmod mailing
BOR but only in the context of another document detailing how
SIDs are allocated and managed. Perhaps this is what you have in mind?
Whatever we conclude, it would be nice to get things properly
documented so that we recall the grand plan in N years from now.
/js
--
Juergen Schoenwaelder
cbor. I thought we settled on
yang-cbor defines what sids are and the sid id details how they are
assigned and how the number space is managed. This way, yang-cbor is
the base document and the sid document has a normative reference to
yang-cbor and comi has a normative reference to yang-cbor. Is t
On Tue, Apr 07, 2020 at 10:55:28PM +0200, Carsten Bormann wrote:
> On 2020-04-07, at 21:47, Juergen Schoenwaelder
> wrote:
> >
> > For me, the question is whether this ID defines SIDs and the other ID
> > details how they are managed or this ID imports the definition of
d come to some common understanding how we
handle things in the future. One option is that NETMOD agrees to take
care of CBOR as a third encoding in the future like it does take care
of XML and JSON today. What I like to avoid is that YANG evolves and
the various encodings start to work with
ld
> exist in the future. If this is the case, I am not aware how one could
> interoperate (I would guess based on the content format), but I will let my
> coauthors comment on that.
Such a different mapping would most likely have to use separate SID
allocations
the other type restrictions).
If people were to agree that the default here is wrong, can the
problem be fixed? Likely not since changing the default (even in say
YANG 2.0) could have drastic consequences and would essentially
require to be always explicit about the require-instance property to
be o
t; > > > > values
> > > > >
> > > > > And this text in section 7.3.4 implies that derived types only do
> > > > > further restriction:
> > > > >
> > > > > If the type's default value is not valid
On Thu, Apr 02, 2020 at 06:51:41PM +0200, Martin Björklund wrote:
>
> I think it quite clear that such a label should not be used in I-Ds.
>
I agree.
Yesterday, com.example-1.2.3m+1 would have made sense to me. ;-)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gG
oth formats as valid inputs.
Given that the colon format has been around for way more than 20 years
(see for example RFC 2579, STD 58), this exercise seems like a waste
of energy, it might take multiple decades to get changes widely
implemented and deployed.
/js
--
Juergen Schoenwaelder Jac
x27; type MUST be
encoded using a CBOR text string data item (major type 3) and MUST
contain one of the names assigned by 'enum' statements in YANG.
There is similar text on page 31 in the context of bits encoding
that will also benefit from a rewrite.
- Third example B
mplex, I have some doubts
this process will work in practice...
- Incomplete sentence:
RFC7120] also says
Or is the following paragraph a quote? In that case, add a colon.
- There are likely more normative references, e.g., RFC 6991 and RFC
8040.
- Why does the example in appendix A not
On Fri, Mar 27, 2020 at 04:35:44PM +0100, Martin Björklund wrote:
> [re-sent w/ correct address]
>
> Juergen Schoenwaelder wrote:
> > Hi,
> >
> > two comments:
> >
> > - It is unclear to me whether this really qualifies as an errata.
> >
> >
: M. Bjorklund, Ed.
> Category : PROPOSED STANDARD
> Source : Network Modeling
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
> ___
>
ike that the two specs
differ in the definition of the -00:00 semantics. I would call this a
bug and fix it but then others may claim this is an non-backwards
compatible change...
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587
will be embedded into a container together with the metadata
describing the instance data.
(I prefer to avoid NETCONF GET and the RESTCONF unified datastore
since they have issues. But if people insist on an example using
operations that have issues, I will keep my mouth shu
address before this
> document is approved.
>
> The discussion of how a factory-reset RPC may isolate a device, is good, as
> is the warning about not relying on this RPC to prevent recovery of
> security-sensitive data from NV storage.
>
>
>
> ___
On Mon, Mar 09, 2020 at 04:17:40PM +, Balázs Lengyel wrote:
> See BALAZS4 below
>
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 2020. március 9., hétfő 10:44
> To: Balázs Lengyel
> Subject: Re: [netmod] WG Last Call:
> draft-ietf-netmod-yang
schema formats are mandatory to
> > implement and whether the simplification is worth the extra code and
> > possible interoperability issues.
> > BALAZS2:
> > Compare:
> > INLINE method:
> >
> >
> > ietf-yang
ould be relatively
> small.
>
Yes, I stand corrected, you can probably even map everything somehow.
Whether such mappings result in _usable_ MIB module is going to be a
question for which answers will be subjective.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Ph
le. My
recommendation is to not spent time on this.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-univ
om the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network Modeling WG of the IETF.
>
> Title : Common YANG Data Types
> Author : Juergen Schoenwaelder
> Filename: draft-ietf-netmod-rfc6991-bis-01.txt
an option). But it is in my view not OK to simply
implement a different behavior since clients may rightfully expect
recursive deletion as this is what the specs says.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen
On Wed, Jul 24, 2019 at 07:10:23AM -0700, Andy Bierman wrote:
> On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka wrote:
>
> > Juergen Schoenwaelder writes:
> >
> > > On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
> > >>
> > >>
; >
> > "The domain-name type represents a DNS domain name. The
> > name SHOULD be fully qualified whenever possible. This
> > type does not support wildcards (see RFC 4592) and
> > classless in-addr.arpa delegations (see RFC 2317).
> >
> >
ence you wanted to remove since the above
more clearly explains when to use / not to use this type.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49
e we are all
much better off if we have a common baseline language and tools that
support the common baseline language. Again, if done right, YANG next
will mostly affect compiler writers and tool makers and not so much
module authors and implementors.
/js
--
Juergen Schoenwaelder Jacob
to X.25 and pigeon based IP.
>
> Regards Balazs
>
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
them in a reasonable amount of time.
/js
On Tue, Jul 23, 2019 at 02:11:23PM +, Balázs Lengyel wrote:
> Hello Jürgen,
> Could the etag and last-modified annotations be moved to 6991bis?
> Regards Balazs
>
> -Original Message-
> From: Juergen Schoenwaelder
>
On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> Juergen Schoenwaelder writes:
>
> > Lada,
> >
> > I do not think we can simply enlarge the value set of inet:domain-name,
> > existing implementations using inet:domain-name may (rightfully) not
>
fic with these definitions. So if the annotations are defined
elsewhere, the ID is as complete as before. If entity-tag and
last-modified are actually seen as datastore properties, it would be
nice to have them defined in the NMDA documents (and it seems we
overlooked this when we did the NMDA w
olete" in YANG.
> >
> > Lada
> >
> > [1]
> > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
> >
> > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
> >
> > _
0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)'
> + '|\.';
>
> Lada
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
> ___
> netmod mailing list
>
...
> }
> }
>
> Lada
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> netmod mailing list
> netmod@ietf.org
&g
c version number in a package
> without this.
Well, this sounds a bit like a tooling issue. You are likely better
off with a tool that can do a semantic comparison for you instead of
working with "fully expanded YANG" modules and generic diff tools.
/js
--
Juergen Schoenwaeld
based on comparing
schema trees internal to a compiler and that sounds to me more robust
than producing "fully expanded YANG".
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +4
e, i.e.,"there MUST be at least one digit before and after
> the decimal point".
> One digit before the decimal point and one digit after the decimal point at
> the same time cover 0.500?, I still don't get it.
> Maybe I am wrong, but this is not a big deal.
>
>
b Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2019年7月17日 17:20
> 收件人: Qin Wu ; Juergen Schoenwaelder
>
> 抄送: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata System
>
> 主题: RE: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)
>
> Hi Qin,
>
&
9 at 08:11:41AM +, Qin Wu wrote:
> What about "0.5000"? based on original text, is it legal or illegal?
> It seem original text exclude the case where one digit before or after the
> decimal point?
>
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun..
: Network Modeling
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
> ___
> netmod mailing list
> netmod@ietf.org
> ht
at the client would first try to use NMDA
> and, if not supported, fallback to non-NMDA.
>
> Kent // contributor
> _______
> netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
--
Juergen Schoenwa
TF YANG model is not reasonable,
> because published IETF standard YANG should not be changed, moreover, this is
> not friendly to the client or the server.
> -邮件原件-
> 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2019年6月28日 17:18
> 收件人: Fengchong (fran
y to get the information of system-controlled data
> according a NMDA-style YANG module(because has no config false copy ) unless
> we implement NMDA.
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2019年6月28日 16:50
> 收
g
>
>
>
>If client issued get operation to retrieve ribs from non-NMDA device,
> rib instance created by routing protocols should be returned?
>
>Another associated question: If client issued get-config operation
> from non-NMDA device, only user-control
On Fri, Jun 28, 2019 at 10:14:28AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder wrote:
> > On Fri, Jun 28, 2019 at 09:52:20AM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder wrote:
> > > > On Thu, Jun 27, 2019 at 10:04:50PM +0200, Martin Bjor
On Fri, Jun 28, 2019 at 09:52:20AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder wrote:
> > On Thu, Jun 27, 2019 at 10:04:50PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder wrote:
> > > > On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bj
On Thu, Jun 27, 2019 at 10:04:50PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder wrote:
> > On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bjorklund wrote:
> > > > Yes, good point, I think the phrase "by a different hardware
> > > > component&qu
."
>
The question is whether every implementor will figure out that if the
component found in some slot x-y-z is different from what is expected
to be in slot x-y-z, this must be seen as a remove + add combination.
If we include 'replace', then it may be clearer that even in the cas
#x27;/hardware/component' list, or a hardware component has been
removed from the '/hardware/component' list, or a hardware
component in the '/hardware/component' list has been
replaced."
/js
--
Juergen Schoenwaelder Jacobs Universit
sh < current
> 1) fold-sourcecode.sh
> 2) fold-text.sh
> 3) fold.sh
> 4) rfc.sh // where "" is replaced by RFC Editor
>
> Any preferences or other suggestions?
Since we have rfcdiff, perhaps rfcfold.sh or something like that. I
t
ardware component."
The point is to define this based on the events that cause the set of
components to change instead of discussing leaf value changes.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ri
(not a
> configuration change) this list is changed, and last-change is
> updated.
I think the ambiguity is 'list changed' - does this mean that list
entries are added/removed or does it include also the case where a
property of a list entry has changed. The relationship to
entLastCha
rrect, then an entry in the table "YANG
Data Nodes and Related ENTITY-MIB Objects" is missing. Anyway, the
description of ietf-hardware:last-change is obviously not precise
enough and this thread should perhaps lead to an errata if we find
agreement what the intention here was.
/js
--
Juerge
On Thu, Jun 13, 2019 at 03:31:49PM +0200, Robert Varga wrote:
> On 12/06/2019 11:25, Juergen Schoenwaelder wrote:
> > That said, they do seem to declare something like
> > oc-ext:regexp-posix; but it would have been much smarter to use for
> > example oc-posix:regex in
uld rather see OpenConfig adopting the standard or fixing their
POSIX regular expression solution so that it avoids changing the
semantics of YANG statements. Having statements mean different things
depending on some context is pretty bad design.
/js
--
Juergen Schoenwaelder Jacobs Univ
ntended name clashes
A prefix only helps a little. Once you have multiple clients creating
entries, you will have to handle collisions again. Sometimes solving
the more general case leads to solutions that also work nicely in
simpler special cases.
/js
--
Juergen Schoenwaelder Jacob
hat have a high probability to clash.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_
ution, it is good to have an explicit definition
of which entry takes priority if there is a name clash.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacob
64 (the default value), so the value 250 can never take effect as
> intended in the above quoted Section 2.3.
>
>
> Is my understanding correct?
>
>
> Since this is a generic question, I am CC’ing NETMOD WG too.
>
>
> Thanks,
>
> - Xufeng
> ___
e being able to
> read from the factory-default datastore, and having an RPC to reset the
> device back to the factory-default state. I would probably defer updating
> copy-config until it can be fixed properly in NETCONF.
>
> Thanks,
> Rob
>
>
> > -Original
ion, I think factory default data may have be encrypted
> already.
> We could reuse it.
>
You can reuse something you dream up. Security considerations need to
be factual not handwaving.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587
101 - 200 of 1273 matches
Mail list logo
