> Leaf foo {
> myext:color "red" {
> saturation "45";
> }
> myext:color "blue" {
> saturation "12";
> }
>
> Maybe another approach is to somehow allow full RFC 9195 instance data to be
> th
"Jason Sterne \(Nokia\)" wrote:
> Hi all,
>
> I'm looking for information about doing more complex YANG extensions
> that the basic type, e.g.:
> oc-ext:openconfig-version "2.5.0";
See https://github.com/netmod-wg/yang-next/issues/54 for a discussion
about one approach.
/martin
>
>
Andy Bierman wrote:
> Hi,
>
> On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia) 40nokia@dmarc.ietf.org> 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
Italo Busi wrote:
> I have some questions/doubts about whether changing a type with union
> is a BC or NBC change
>
> For example, is the following change a BC or NBC change?
>
> OLD
> type union {
>type foo;
>type bar
> }
>
>
mohamed.boucad...@orange.com wrote:
> Hi Martin,
>
> Please see inline.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Martin Björklund
> > Envoyé : jeudi 14 décembre 2023 21:48
> > À : BOUCADAIR Mohamed INNOV/NET
> > Cc : n
Hi,
mohamed.boucad...@orange.com wrote:
> Hi Martin, all,
>
> Please remember that RFC8407 includes already the following:
>
> ==
> "when" statement evaluation is generally more expensive than
> "if-feature" or "choice" statements
> ==
Yes, this is fine. It is something that the module
Hi,
mohamed.boucad...@orange.com wrote:
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Martin Björklund
> > Envoyé : vendredi 8 décembre 2023 17:35
> > À : BOUCADAIR Mohamed INNOV/NET
> > Cc : n
mohamed.boucad...@orange.com wrote:
> Re-,
>
> There was an invitation to review the changes:
> https://mailarchive.ietf.org/arch/msg/netmod/4NDzo7SLinue-CeHGRyOD6aWXHI/,
> but no follow-up.
>
> Do you have any concern with that part? Thanks.
I do, but I suspect that there is a reason for
URL_With_REV] is used
>in the following to refer to such URLs.
> ==
>
> IANA_FOO_URL can be used in the description, cross-reference purposes,
> and importing any available latest version.
>
> IANA_FOO_URL_With_REV can be used in revisions or when importing
> specific version
Hi,
rfc8407bis has this text:
Some modules use "case + when" construct such as shown in the example
below. Such a construct MUST be avoided by removing the "when"
statement or using a "container" outside the "choice".
case yang-datastore {
when
Hi,
mohamed.boucad...@orange.com wrote:
> Hi Martin,
>
> Thanks for raising these points.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : netmod De la part de Martin Björklund
> > Envoyé : jeudi 7 décembre
Hi,
There has been some discussion with IANA on the YANG doctors list
regarding this text in section 4.8 in RFC 8407:
A "revision" statement MUST be present for each published version of
the module. The "revision" statement MUST have a "reference"
substatement. It MUST identify the
What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
- As it works today; the IETF *has* published bugfixed modules that break the
rules. (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible
This would allow 6991bis to update date-and-time to
"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
> > Subject: Re: [n
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 coupling these
> goals together would be a mistake.
>
> Regards,
&
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
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
/martin
>
> Maybe it becomes more subtle if that behavior change isn't documented in the
> "description" statement (I'd argue it is still NBC if the server changes that
> behavior and they should be publishing a new revision of the YANG model/API),
> but I was proposing that
Acee Lindem wrote:
>
> > On Apr 14, 2023, at 04:39, Martin Björklund wrote:
> >
> > Hi,
> >
> > I am quite confused after reading this thread, so I had to go back to
> > this first message:
> >
> > "Jason Sterne (Nokia)" wrote:
&g
Hi,
I am quite confused after reading this thread, so I had to go back to
this first message:
"Jason Sterne (Nokia)" wrote:
> Hi Jeff,
>
> One topic that came up during the IETF 116 NETMOD meeting was
> backwards compatibility.
>
> >From what I understand, a leaf (e.g. unknown-flags) that
.18.2 of RFC7950, NEW
> (A) seems equivalent to NEW (B): if identity B (baz) is derived from A
> (foo) and C (bar) is derived from B (baz), then C (bar) is also
> derived from A (foo) ...
>
> Italo
>
> > -Original Message-
> > From: Jernej Tuljak
> > Sent:
Hi,
Jernej Tuljak wrote:
> On 30/01/2023 10:19, Italo Busi wrote:
> >
> > Yes, the intention is not to change the semantic of bar but to
> > introduce a more “restricted” identity from which bar could be derived
> >
> > Something like introducing an identity for italian-car in between car
> >
Hi,
Italo Busi wrote:
> BTW, what about using uri for key leafs (see for example RFC8345)?
>
> I think there are other cases where uri could be an appropriate type
> to use for a key …
This is fine if the leaf really is an URI. Note that no examples in
RFC 8345 have valid uris. (A uri must
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
> > are intended for import by service
tom petch wrote:
> draft-ietf-opsawg-sap-12
> defines a grouping sap-list which uses grouping sap-entry. The groupings are
> intended for import by service specific modules. The uses does not include a
> prefix; should it?
>From a YANG perspective this is correct. Since it references a
Andy Bierman wrote:
> On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> > On Mon, Dec 05, 2022 at 08:19:12PM +, Kent Watsen wrote:
> > >
> > >
> > > Hi Juergen,
> > >
> > >
> > >
> > > >> 3) There are two "time-with-zone-offset" typedefs
Hi,
Alex Huang Feng wrote:
> Dear NETMOD WG,
>
> Some time ago I sent this email to the YANG doctors to check with
> them. I would also like to have your insights on mandatory augmented
> leaves.
>
> We are working on a YANG module for the following draft:
>
Hi,
Regardless of pattern, the usage of this 'leaf language' seems
completely meaningless, and arbitrary. For example, there is one leaf
'language' per entry in 'list i2nsf-cfi-policy', which is supposed to
cover all 'leaf description' in that list entry. So I, as an operator
(i) must configure
Kent Watsen wrote:
>
>
> > On May 18, 2022, at 2:05 AM, Martin Björklund
> > wrote:
> >
> >> PS: the answer to this impacts the "crypto-types and friends" drafts
> >> in the NETCONF WG, where it is assumed (and various
Hi,
Kent Watsen wrote:
> YANG Doctors,
>
>
> Does "foo" need to be "implemented", in order for its feature to be
> define?
>
> module foo {
> yang-version 1.1;
> namespace "https://example.net/foo;;
> prefix "f";
>
> feature foo-feature;
>
>
Hi,
This errata report is obviously correct and should be verified.
/martin
RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --
> You may review the report below and at:
>
I thought the discussion was only about ipv4?
/martin
Jürgen Schönwälder wrote:
> On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote:
> > Hi,
> >
> > First of all, I agree that if we were to design this from scratch, I
> > think we should have a
rror?) on zoned IP addresses, ignore the zone (does
> that make sense), or have additional code to handle a case that for
> 99% of users will probably never happen. My point being that these is
> also a cost to keeping support for zones in the base ip-address types.
>
> Regards,
>
Jürgen Schönwälder wrote:
> On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> > Jürgen Schönwälder wrote:
> >
> > [...]
> >
> > > For me, the only sensible option (other than accepting that types are
> > > named the way t
Jürgen Schönwälder wrote:
[...]
> For me, the only sensible option (other than accepting that types are
> named the way they are) is to introduce ip-address-with-zone and to
> deprecate ip-address and stop there. Yes, this means coexistance of
> inet:ip-address and ip-address-with-zone until
Hi,
Here's another suggestion. We keep the ip-address pattern as is, but
document in the description that implementations do not have to
support the optional zone index. This would essentially document the
behavior of most current implementations. (This is actually what I
suggested in the
tom petch wrote:
> Can a YANG tree diagram contain comment lines?
>
> draft-ietf-teas-yang-te has a tree diagram of 40 pages and since the
> IETF has abolished the page number, then any reference into it could
> be a challenge. For a YANG module, this can be ameliorated by
> inserting comment
Andy Bierman wrote:
> On Thu, Apr 7, 2022 at 9:11 AM tom petch wrote:
>
> > From: Lsr on behalf of Rob Wilton (rwilton)
> >
> > Sent: 07 April 2022 10:25
> >
> > I basically agree with Acee, and I think that we should do (b):
> >
> > b) Change the types as suggested and accept that
Hi,
Chris Smiley wrote:
>
> Greetings,
>
> EID 6857 is almost identical to EID 5797. They differ in the enabled field
> (one says true, one says false). Please let me know which errata is correct.
EID 5797 is the correct one.
For some reason, EID 6857 has mistyped the *original* text
Jürgen Schönwälder wrote:
> On Tue, Mar 08, 2022 at 11:20:57AM +0100, Martin Björklund wrote:
> > Hi,
> >
> > You didn't answer my first question about what we actually mean - do
> > we mean the "URI"
>
> "The uri type represents a Uniform
odule. People on the Internet tried to literally capture the
> ABNF rules of RFC 3986 leading to regular expression monsters.
>
> I am open for concrete suggestions. ;-)
>
> /js
>
> On Tue, Mar 08, 2022 at 09:52:23AM +0100, Martin Björklund wrote:
> > Hi,
> >
&
Hi,
While reviewing draft-ietf-opsawg-sap-02, I had to study the type
inet:uri again.
I assume that the type "uri" is supposed to mean the type that is
defined by the ABNF rule "URI" in RFC 3986. If my assumption is
correct I think we should make this clear in 6991bis. If my
assumption is not
Hi,
The main reason that keys are encoded first is that it allows for
efficient streaming parsing. The reciever can act on an instance as
soon as the keys are received, w/o having to buffer the entire
document. For example, in the implementation that I used to work
with, a copy-config a
"Sterne, Jason (Nokia - CA/Ottawa)" wrote:
> Hi all,
>
> There is an interesting consequence of the wording for lists.
>
> > The list's key nodes are encoded as subelements to the list's
> > identifier element, in the same order as they are defined within the
> > "key" statement.
>
Jan Kundrát wrote:
> Hi,
> last year we published some work [1] about using IETF YANG-push for
> telemetry streaming in the context of optical networks. One of the use
> cases was continualy sending spectral scans, and for us that meant
> updating a list of roughly 15-20k items at least once per
Hi,
I didn't find any discussion about the new percent types in the list
archives. Do we really need three types for percent? We can now
express 4294967295 percent, but not 10.5 percent.
The new tables look good. s/6020/6021/g though.
/martin
Jürgen Schönwälder wrote:
> On Tue, Feb 15,
Jernej Tuljak wrote:
>
>
> On 04/02/2022 08:18, Martin Björklund wrote:
> > Tim Bray wrote:
> >> On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund
> >> wrote:
> >>
> >>> If an XML document has , won't the XML processor
> >>&g
Tim Bray wrote:
> On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund wrote:
>
> >
> > If an XML document has , won't the XML processor
> > pass the attribute "xmlns:bar" and its value to the application? This
> > should be enough even if the XML proce
Hi,
Tim Bray wrote:
> On Thu, Feb 3, 2022 at 9:46 AM Andy Bierman wrote:
>
> >
> > libxml2 has an API to get the namespace for a string node.
> >
>
> Just to get the terms correct, it's not the "namespace" you need to get,
> you need to get the XML prefix mapped to that namespace, and the
Hi,
Nick Hancock wrote:
> Hi,
>
> We need some advice on whether the following can be considered as
> valid YANG syntax and whether the behavior is that which we expect.
>
> We have a use case (simplified in the example below) where a client is
> required to define a certain concrete integer
tom petch wrote:
> From: Martin Björklund
> Sent: 14 January 2022 11:23
>
> Hi,
>
> Ok, I think I understand what he means. With this XML:
>
>
> nsfmi:memory-alarm
>
>
> the prefix "nsfmi" is present in the element data, which me
from the definition of an identityref in RFC 7950 that the namespace
mapping is needed to parse this correctly.
/martin
Ladislav Lhotka wrote:
> On 14. 01. 22 11:39, Martin Björklund wrote:
> > Hi,
> > I don't understand the problem either. He writes:
> >
> >> S
Hi,
I don't understand the problem either. He writes:
> Sorry, but this has the same problem in figure 11.1 that we've just been
> discussing with Ian.
Can you send a pointer to that discussion? Perhaps there's more
context there.
/martin
tom petch wrote:
> I see that IANA have taken to
Hi,
Ladislav Lhotka wrote:
> Carsten Bormann writes:
>
> > On 2021-12-30, at 13:29, tom petch wrote:
> >>
> >> when "../../../../../../nw:network-types/tet:te-topology/“
> >
> > I’m probably showing my ignorance about YANG again, but what is the reason
> > this is not phrased as
> >
>
Hi,
tom petch wrote:
> Any one of many, many YANG modules from such as TEAS and CCAMP have dozens
> and dozens of augment, some more than a 100, almost all controlled by 'when'.
> The 'when' are almost all performing the same test for a presence container
> for the network type but because
Hi,
Kent Watsen wrote:
> Andy, et. al.,
>
>
> >> I cannot find any RFC text that says has only nodes created
> >> by a client.
> >
> > Really? Interesting. Still, I know it’s a mantra we’ve held closely
> > for many year, right?
> >
> > No. Quite the opposite.
>
> There was a brouhaha
Hi,
"Fengchong \(frank\)" wrote:
> Hi all and martin,
>
> If I have defined a typedef a
> typedef a {
> type instance-identifier {
> require-instance false;
> }
> }
>
> And then I define another typedef b
>
> typedef b {
> type a {
> require-instance true;
> }
>
> }
>
>
Hi,
Kent Watsen wrote:
> Hi Andy,
> > I cannot find any RFC text that says system-injected config is
> > special, especially since
> > server implementations exist that treat these edits as just another
> > client
> > (although probably a 'root' user client).
>
> Very true (and Juergen’s point
Michal Vaško wrote:
> > > Michal Vaško wrote:
> > > > > Michal Vaško wrote:
> > > > > > Hello,
> > > > > > > I would like to get some input for a use-case I came across, which
> > > > > > > to>
> > > > > > > me does not seem to have any consistent rules that can be applied.
> > > > > > > module
Michal Vaško wrote:
> > Michal Vaško wrote:
> > > Hello,
> > > > I would like to get some input for a use-case I came across, which to>
> > > > me does not seem to have any consistent rules that can be applied.
> > > > module mod_b {
> > > namespace "x:example:mod_b";
> > > prefix "mb";
Hi,
Michal Vaško wrote:
> Hello,
>
> I would like to get some input for a use-case I came across, which to
> me does not seem to have any consistent rules that can be applied.
>
> module mod_b {
> namespace "x:example:mod_b";
> prefix "mb";
>
> grouping mylist_wrapper {
>
Kent Watsen wrote:
>
>
> > On Dec 12, 2021, at 5:11 PM, Michael Richardson
> > wrote:
> >
> >
> > Carsten Bormann wrote:
> >> On 2021-12-12, at 22:17, Michael Richardson
> >> wrote:
> >
> >>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it
> >>> RFC8791.
> >> […]
> >>>
Hi,
"Fengchong \(frank\)" wrote:
> Hi folks and martin,
> I’m writing a yang parser. I notice the case statement has no
> ‘notification’ and ‘action’ sub-statements, but have ‘uses’ sub-statement.
> And the ‘grouping’ statement has ‘action’ and ‘notification’ sub-statements.
> If case’s
rmative to report
> > that as origin "intended" rather than "origin" default. But I don't think
> > that RFC 8342 proscribes what is be used in these cases.
> >
> > Regards,
> > Rob
> >
> > // As a contributor
> >
> >
>
Jürgen Schönwälder wrote:
> On Wed, Nov 24, 2021 at 03:21:14AM +, maqiufang (A) wrote:
> >
> > But suppose the node is a list entry (e.g., an interface) or a leaf with
> > the same value. In this case, it is not clear which origin should be used.
> > I think it would be ok to use
Hi,
"maqiufang \(A\)" wrote:
> Hi, all
>
> There is still another issue which is about origin metadata
> annotation: should the origin="system" be required for system
> configurations copied/pasted into ?
I think the question is "if a node is present both in and
in , which origin does it have
Jernej Tuljak wrote:
>
>
> On 30/09/2021 10:48, Martin Björklund wrote:
> > Hi,
> >
> > Jernej Tuljak wrote:
> >> Hi,
> >>
> >> can someone clarify the meaning of the following bullet in Section 11,
> >> RFC7950:
> >>
Hi,
Jernej Tuljak wrote:
> Hi,
>
> can someone clarify the meaning of the following bullet in Section 11,
> RFC7950:
>
>o A "base" statement may be removed from an "identityref" type,
> provided there is at least one "base" statement left.
>
> This seems to enable the value space
Mahesh Jethanandani wrote:
> Hi Juergen,
>
> > On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder
> > wrote:
> >
> > On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:
> >
> >> As I mentioned, BBF TR-181 uses int with range -1:65535 with -1
> >> meaning NULL. So I certainly
This is clearly a typo. The errata should be verified.
/martin
RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --
> You may review the report below and at:
>
Hi,
This errata is correct and should be verified.
/martin
RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --
> You may review the report below and at:
>
Jernej Tuljak wrote:
> Hi,
>
> while re-reading RFC7950, Section 11, I noticed that adding an
> "action" to an existing "container" or "list" does not appear to be
> among the permitted changes while updating a module to a newer
> revision.
>
> Seems like an unintentional omission in text?
re is no pattern
defined. An implementation may hook up a standard uri parser to
objects of this type.
Are we discussing a real problem here?
/martin
>
> Jason
>
> > -Original Message-
> > From: tom petch
> > Sent: Tuesday, March 30, 2021 11:51 AM
> > To
Juergen Schoenwaelder wrote:
> On Tue, Mar 30, 2021 at 01:55:18AM +, Sterne, Jason (Nokia - CA/Ottawa)
> wrote:
> > Hi all,
> >
> > I took a look at section "3.1.2 Backwards-compatibility rules for config
> > false and output data" of
> >
"Rob Wilton \(rwilton\)" wrote:
> Sorry, but I wish to raise another question regarding changing types.
>
> Are you allowed to change from one type to another type that
> 'contains' the first type.
>
> typedef smallInt {
> type int8 { range "0..100"; };
> }
>
> typedef biggerInt {
> type
"Rob Wilton (rwilton)" wrote:
>
>
> > -Original Message-
> > From: Martin Björklund
> > Sent: 26 February 2021 16:30
> > To: a...@yumaworks.com
> > Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> > Subject: Re: [netmod] type equivalenc
Andy Bierman wrote:
> On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund wrote:
>
> > "Rob Wilton \(rwilton\)" wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: netmod On Behalf Of Juergen
> > Schoenwa
"Rob Wilton \(rwilton\)" wrote:
>
>
> > -Original Message-
> > From: Juergen Schoenwaelder
> > Sent: 26 February 2021 14:28
> > To: Rob Wilton (rwilton)
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
> >
> > On Fri, Feb 26, 2021 at 12:21:26PM +, Rob Wilton
"Rob Wilton \(rwilton\)" wrote:
>
>
> > -Original Message-
> > From: netmod On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
> >
> > Here is an attempt to come up with better wording. If people agree
here in RFC 7950. Anyway, if the agreement
> back then was that you can't change base types (regardless of type
> restrictions), it would have been nice if the text would say this more
> clearly.
Agreed.
/martin
>
> /js
>
> On Mon, Feb 22, 2021 at 10:49:38AM +0
Hi,
Section 11 of RFC 7950 says:
o A "type" statement may be replaced with another "type" statement
that does not change the syntax or semantics of the type. For
example, an inline type definition may be replaced with a typedef,
but an int8 type cannot be replaced by an
Hi Peter,
[Kul att se dig här!]
"Peter Lundell \(plundell\)" wrote:
> Hi all.
>
> I'm working with an issue involving a deviate replace type and the problem is
> where the type should be resolved.
>
> The scope in which the deviated property is resolved in is not explicitly
> stated in RFC
> My instinct would be to put the three identity definitions into common with a
> dhcpv6 container, which is then augmented by the three role modules, the YANG
> 'when' referring to role leaf in the common. Any better ways?
Why do augment at all? Why not just have a top-level container
Hi,
I think it is a matter of taste and perhaps future extensibility if
this model is done as one or more YANG modules. It can certainly be
done in one module, with features for client, server and relay, but it
is also ok to have 3 modules for the different functions. And once
you have these 3
Hi,
tom petch wrote:
> Sorry about the incomplete e-mail. Try again
>
> From: Teas on behalf of Martin Björklund via
> Datatracker
> Sent: 17 December 2020 18:58
>
> Reviewer: Martin Björklund
> Review result: Ready with Nits
>
>
> o Validation
>
&
he submodules.
/martin
>
> Thanks,
> Ram
>
> On 20/10/20, 7:34 PM, "Martin Björklund"
> mailto:mbj+i...@4668.se>> wrote:
>
> [External Email. Be cautious of content]
>
>
> Ram Polisetty Subbaiah
> mailto:ramas=40juniper@dmarc.ietf.org
Ram Polisetty Subbaiah wrote:
> Hi,
>
> As per RFC 6020:
>
> ===
> https://tools.ietf.org/html/rfc6020#section-5.6.4.1 Modules
>Servers indicate the names of supported modules via the
>message. Module namespaces are encoded as the base URI in the
>capability string, and the
Hi,
This errata is correct and should be accepted.
/martin
RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --
> You may review the report below and at:
>
"Rob Wilton (rwilton)" wrote:
>
>
> > -Original Message-
> > From: netmod On Behalf Of Ladislav Lhotka
> > Sent: 12 August 2020 08:43
> > To: Martin Björklund
> > Cc: jclarke=40cisco@dmarc.ietf.org; netmod@ietf.org
> > Subj
Juergen Schoenwaelder wrote:
> On Tue, Aug 11, 2020 at 05:06:13PM +0200, Martin Björklund wrote:
> >
> > I think that any change in an argument string is an editorial change.
> >
> > For example, compare these two changes:
> >
> >A1. descripti
Hi,
"Joe Clarke (jclarke)" wrote:
>
>
> > On Aug 11, 2020, at 10:45, Martin Björklund wrote:
> >
> > Hi,
> >
> > "Joe Clarke \(jclarke\)" wrote:
> >> At the IETF 108 virtual meeting, Lada asked about what would happe
Hi,
Ladislav Lhotka wrote:
>
>
> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
> > At the IETF 108 virtual meeting, Lada asked about what would happen if he
> > converted a YANG module to YIN syntax (or vice versa, or to some other
> > format). This was during the discussion of the
Hi,
"Joe Clarke \(jclarke\)" wrote:
> At the IETF 108 virtual meeting, Lada asked about what would happen if
> he converted a YANG module to YIN syntax (or vice versa, or to some
> other format). This was during the discussion of the issue of what
> should happen if a module changes and the
tom petch wrote:
> From: netmod on behalf of Martin Björklund
>
> Sent: 10 August 2020 10:24
>
> Italo Busi wrote:
> > We have found some issues with RPC XPaths when developing the YANG
> > code for
> > https://tools.ietf.org/html/draft-ietf-teas-yang-path
Italo Busi wrote:
> We have found some issues with RPC XPaths when developing the YANG
> code for
> https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation
>
> As discussed during the TEAS WG session in IETF 108, this issue has
> been raised on pyang github:
>
Hi,
This errata is correct; the must expression in the errata reflects the
intention correctly.
But the question is if this can be fixed by an RFC errata...
/martin
RFC Errata System wrote:
> The following errata report has been submitted for RFC7317,
> "A YANG Data Model for System
Martin Björklund wrote:
> "Reshad Rahman (rrahman)" wrote:
> > Hi,
> >
> > On 2020-05-08, 5:12 PM, "Martin Björklund" wrote:
> >
> > Hi,
> >
> > "Reshad Rahman (rrahman)" wrote:
> > > Hi
"Reshad Rahman (rrahman)" wrote:
> Hi,
>
> On 2020-05-08, 5:12 PM, "Martin Björklund" wrote:
>
> Hi,
>
> "Reshad Rahman (rrahman)" wrote:
> > Hi,
> >
> > This came up during this week's meetin
We've opened issues to track your review comments (see below). Will
> kick off separate therads for each issue.
>
>
> https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
>
> Reg
Michal Vaško wrote:
> Hi,
> when we were implementing support for NMDA, we came across the section
> about actions and RPCs [1]. What I understood from it is that,
> effectively, all RPCs and actions are validated against the data in
> the operational datastore. So, for example,
1 - 100 of 134 matches
Mail list logo
