Bal?zs Lengyel writes:
>https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00
[I've moved to a "deep lurker" role here, but ...]
Can we ensure this model contains a "format" leaf in the RPC's input
so that future (and proprietary) formats can be supported? That
leaf can be an identityref
Juergen Schoenwaelder writes:
>Frankly, carrying the different basic modes over to
>sounds like a mistake. Complexity for no real value.
+1
Thanks,
Phil
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Andy Bierman writes:
>The draft avoids discussion of any useful operations based on tags.
Nor does it really clearly say "what" is being tagged. The absract
talks about "used to help classify and organize modules", but the
Introduction lacks any expansion on this. There's really no clear
"Sterne, Jason (Nokia - CA/Ottawa)" writes:
>The DS needs to have both the template itself in the schema as well
>as
>whatever nodes are used to hold 'exploded' data. But what about intended and
>operational ?
For JUNOS, we carry both the raw and expanded views, though nothing
in JUNOS is
required to support this sort of thing?
>I doubt it.
>
>
>Andy
>
>
>
>
>On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer <p...@juniper.net> wrote:
>
>> Robert Wilton writes:
>> >ii) However, as far as I can see, it doesn't make sense for an action to
>>
Robert Wilton writes:
>ii) However, as far as I can see, it doesn't make sense for an action to
>directly affect the contents of any configuration datastore, that should
>be done via a purpose built rpc (like edit-config).
An example action would be to retrieve the fingerprint of an ssh
key.
Andy Bierman writes:
>I think text() and node() are just filter tests.
>
> /foo/*[text()] would return all the child nodes of /foo that are leaf or
>leaf-list
>
>text() returns a boolean (0 or 1). Do not use it for value testing:
>
> /foo/*[text() =3D 'fred'] // wrong!
>
> /foo/*[. =3D
Andy Bierman writes:
>But this means if any clients use the disable-node feature then all clients
>need to know about the feature as well, or they will mistake these nodes
>for enabled nodes (i.e., plain configuration according to the standard) .
The alternative would be removing inactive config
"t.petch" writes:
>Inactive appears a dozen times but is not defined, except in the course
>of those appearances it effectively is, but is sometimes 'inactive',
>sometimes 'inactive configuration', sometimes 'inactive data'.
Agree. Consistent terms are good things.
>I would find it clearer if
Kent Watsen writes:
>The NETMOD chairs need your on-list response to this email.
>- all the other authors have already replied...
I know of no IPR related to this draft.
Thanks,
Phil
___
netmod mailing list
netmod@ietf.org
Mahesh Jethanandani writes:
>What happens if I have a 'must' statement that is written for
>validating configuration? Will it be enforced on operational datastore?
The last paragraph of 4.7 of the NMDA draft talks about constraints
in operational:
As a result of remnant configuration, the
Andy Bierman writes:
>The YANG definitions defined for NETCONF and RESTCONF operations do not
>actually
>require the "real" datastore identities to be used by a server.
The identities are defined in the YANG modules contained in the
NMDA draft (draft-ietf-netmod-revised-datastores). The
"Sterne, Jason (Nokia - CA/Ottawa)" writes:
> OK - so the same leaf (in the schema) has the same value space in the
> conventional datastores and in the operational datastore. That probably
> makes sense since a single schema describes the model for that leaf
> whether it is accessed in
Andy Bierman writes:
>It has always been OK for a config=false data node's XPath expression to
>point at a config=true data node.
>But this has always meant the configured value. RD changes this behavior
>because the new opstate datastore
>contains only the operational values of config=true nodes.
Andy Bierman writes:
>I think the remnant configuration text needs clarification.
>I thought the whole point of the operational datastore for config=true
>nodes was to
>provide the intended and applied values using the exact same
>instance-identifier.
Instance names are the same. Remnant
Andy Bierman writes:
>IMO it is more robust not to assume people never see the real YANG
>statements.
Exactly. We made YANG readable so that we wouldn't _need_ to view
it using tools. This was one of the "insta-death" factors for UML.
Thanks,
Phil
Ladislav Lhotka writes:
>leaf foo {
>description "This is my *favourite* leaf.";
>type string;
>}
>
>you may not like it, but it is absolutely legal and IMO also readable by
>humans. As William previously mentioned, some communities are already doing
>similar things. The principal aim of
William Ivory writes:
>Yes, I'd noticed that. Does this make the behaviour 'undefined' in YANG 1.0?
No, this was a clarification. The text in 6020 was reasonably clear:
The "when" statement makes its parent data definition statement
conditional. The node defined by the parent data
Phil Shafer writes:
>Juergen Schoenwaelder writes:
>> is one of:
Apologies. My brain's still in "low".
Thanks,
Phil
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Juergen Schoenwaelder writes:
> is one of:
>rw for configuration data
>ro for non-configuration data
Given that these are really "config true" and "config false" and
that ephemeral data may well be writable and "config false", should
we change the names? Writable read-only data would
The considerations should say more about how we delegate encryption
and authentication to the underlaying protocols, whatever they may
be. We don't need details, just an understanding of the role of
each layer.
Thanks,
Phil
Kent Watsen writes:
>
>A couple comments:
>
>1) drilling down on the
Robert Wilton writes:
>> But I don't think it can be done in an errata.
>Does this just leave the behaviour as undefined then? I.e. it is up to
>the implementation to decide whether they error the augmentation.
Which is an unacceptable outcome. Errata are an acceptable
means of addressing this.
Martin Bjorklund writes:
>It explicitly says that server's *implementation* of the augmented
>module contains the additional nodes.
>
>If you don't advertise a certain module, I don't think you can claim
>that your implementation contains that module.
The issue is that the module is
Martin Bjorklund writes:
>Phil Shafer <p...@juniper.net> wrote:
>> Martin Bjorklund writes:
>> >> What are your thoughts on this? Surely, an augment should not have to
>> >> contain if-feature statements of all parents of the augmented node.
>> &
Martin Bjorklund writes:
>> What are your thoughts on this? Surely, an augment should not have to
>> contain if-feature statements of all parents of the augmented node.
>
>The spec says:
>
> When a server implements a module containing an "augment" statement,
> that implies that the server's
+1.
As someone who does internal code review for Juniper changes, having
an example is a huge help to the reviewer (me). It also helps to
convince the module author (them) that what they are advocating
will look horrible.
Thanks,
Phil
Juergen Schoenwaelder writes:
>Hi,
>
>my experience is
Robert Wilton writes:
>Wouldn't you just write this without the back reference to the
>deprecated/obsolete leaf.
>E.g. wouldn't the following be sufficient to enforce the desired constraint?
> leaf old-stuff {
> status deprecated;
> must not(../new-stuff);
> }
> leaf
Andy Bierman writes:
>mandatory for config=false means it must exist in an for a
>operation retrieval. It is by definition "server-supplied", so there is no
>server validation to worry about.
>
>YANG constraints are used on clients.
>Not that we are super-server-centric here, but client
lso top-level, if your server fails to provide
>that data,
> then your server is not compliant with the YANG.
>
>If the data is sometimes not needed, then the module author should not have
>marked it as
> mandatory.
>
>Alex
>
>
>F
Martin Bjorklund writes:
>But marking definition as obsolete in one module cannot automatically
>make definitions in *other* modules obsolete.
>
>(*) _maybe_ 7950 can be interpreted in this way when it says:
>
> If a definition is "current", it MUST NOT reference a "deprecated" or
> "obsolete"
Ladislav Lhotka writes:
>>> 6087bis says in sec. 5.10:
>>> Top-level database data definitions MUST NOT be mandatory.
>Right - I think the following should do:
>OLD
> Top-level database data definitions MUST NOT be mandatory.
>NEW
> Top-level data nodes that represent configuration MUST NOT be
Robert Wilton writes:
>> The server is buggy if it is sending data that violates YANG constraints.
>> If any of these statements need to be different for config and oper
>> then the old style YANG has to be used instead.
>You just have a separate state leaf. These are still allowed in a
Balazs Lengyel writes:
>We already have a radius model part in ietf-system; but are there any
>plans to develop a TACACS+ model for YANG?
>
>How widely is TACACS+ used for remote authorization/accounting ? As an
>outsider I would guess that remote authorization could really slow down
Ladislav Lhotka writes:
>Which doesn't mean that inconsistent (format of) state data is
>acceptable. My colleague develops a BGP looking glass, and it is
>really a terrible work because he has to do a lot of screen-scraping.
>Each time a vendor changes the data format, he has to update his
Lou Berger writes:
>"No, I'm not aware of any IPR that applies to this draft"
No, I'm not aware of any IPR that applies to this draft
Thanks,
Phil
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Ladislav Lhotka writes:
>So let's say we have a list with min-elements = 1 (such as the list of RIBs),
>and there
>is already one entry provided by the system. what has to be done in order to
>make ded> valid? Should the system-controlled entry permeate up to ?
We should update the draft to
"Acee Lindem (acee)" writes:
>It may take more than one to reach consensus
It's sure to be a "rough consensus" ;^)
Great work gents!
Thanks,
Phil
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
>Title : A YANG Data Model for Syslog Configuration
I've a few questions:
- The description says that the "facility/no-facility" case/leaf
is used "o effectively disable a particular log-action". Why not
make an explicit "disable" leaf instead? Using no-facilities like
this
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.
Thanks,
Phil
___
rfc-edi...@rfc-editor.org writes:
>A new Request for Comments is now available in online RFC libraries.
>RFC 7950
>Title: The YANG 1.1 Data Modeling Language
I don't see a "changes since YANG-1.0" section. Is this information
recorded somewhere?
Thanks,
Phil
Juergen Schoenwaelder writes:
>I believe it is worth to move to a terminology
>that is far easier to understand and use; as long as the relationship
>to the old MIB modules is clearly documented we are fine I think.
+1
Thanks,
Phil
___
netmod mailing
Ladislav Lhotka writes:
>If it is still possible, it would IMO make a good sense to remove that comment
>from the
>ABNF in 6020bis, and make this change in sec. 7.1.4:
>
>OLD
>
> A prefix is an identifier (see Section 6.2).
>
>NEW
>
> A prefix is an identifier (see Section 6.2), and it MUST
Kent Watsen writes:
>If a line card is missing, then (as I understand it), the server would not
>wait for the line-card to show up. That said, if the client requested
>transactional/atomic update, a missing line-card would cause an immediate
>failure/rollback.
We have to avoid the scenario when
Semi-in-reply-to: <560aa471.3050...@cisco.com>
I keep thinking the terms in the draft somewhat confusing. Okay,
confusing isn't exactly right. I find the terms have a lot of
background that needs to be explained that's not obvious from the
simple explanations in the draft. The reader will see
Andy Bierman writes:
>Perhaps the operational requirements are not that clear, so
>the terminology is also not that clear?
Are we trying to agree on the former without the later?
>Is there really a requirement to know detailed info about the
>differences between intended and applied config?
I'm
Juergen Schoenwaelder writes:
And my understanding is that the list foo defined above will never
have an instance, correct? I assume decent compilers will continue to
create warnings when they can decide that a list will never have any
instances. (And yes, there are other ways to construct such
46 matches
Mail list logo
