Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

"Alexey Melnikov"  wrote:
> Hi Martin,
> 
> On Mon, Oct 21, 2019, at 8:33 AM, Martin Bjorklund wrote:
> 
> > > This is a fine document.
> > > 
> > > Can you show and example similar to what in A.3 with 2 addressbook
> > > entries?
> > 
> > The example isn't really written to handle more than one address
> > book.  The structure defines one single address book.  But perhaps I
> > misunderstood your question?
> 
> The example in A.1 contains "list address". Can this list contain more
> than one element in it?

Aha, I see.  Yes it can.

> If yes, can you provide an example with
> multiple elements?

In XML it would be:

  
 
   Flintstone
   Fred
   301 Cobblestone Way
   Bedrock
   70777
 
 
   Root
   Charlie
   4711 Cobblestone Way
   Bedrock
   70777
 
   


> I am trying to figure out how multiple elements
> would be represented in XML (In JSON it seems more obvious to me). My
> YANG knowledge is limited, so I don't know whether or not there is an
> issue. But I couldn't tell until I see an example.

Also see section 4.2.2.4 in RFC 7950 for another example of multiple
list entries.



/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Alexey Melnikov]

Hi Martin,

On Mon, Oct 21, 2019, at 8:33 AM, Martin Bjorklund wrote:

> > This is a fine document.
> > 
> > Can you show and example similar to what in A.3 with 2 addressbook entries?
> 
> The example isn't really written to handle more than one address
> book.  The structure defines one single address book.  But perhaps I
> misunderstood your question?

The example in A.1 contains "list address". Can this list contain more than one 
element in it? If yes, can you provide an example with multiple elements? I am 
trying to figure out how multiple elements would be represented in XML (In JSON 
it seems more obvious to me). My YANG knowledge is limited, so I don't know 
whether or not there is an issue. But I couldn't tell until I see an example.

Thank you,
Alexey

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

[Andy Bierman]

On Mon, Oct 21, 2019 at 5:45 AM Martin Bjorklund  wrote:

> Jernej Tuljak  wrote:
> > Should I clarify my question?
> >
> > Jernej
> >
> > On 10/10/2019 10:36, Jernej Tuljak wrote:
> > > Hi,
> > >
> > > there is at least one YANG 1.0 standard module that imports and uses
> > > groupings from a YANG 1.1 standard module and at least one such
> > > grouping contains must/when statements referencing XPath functions
> > > that are not available in 1.0 XPath context.
> > >
> > > The modules I'm referring to are part of RFC8533 [1] and RFC8532
> > > [2]. ietf-connectionless-oam-methods (a 1.0 module) uses
> > > cl-oam:tp-address from ietf-connectionless-oam (a 1.1 module), which
> > > calls "derived-from-or-self" in a when expression of a used
> > > node. These RFCs were published in April.
> > >
> > > Our tools complain about "derived-from-or-self" not being defined in
> > > ietf-connectionless-oam-methods's XPath context:
> > >
> > > [Error];
> > > ietf-connectionless-oam-methods@2019-04-16
> :/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when;
> > > XPath function "derived-from-or-self" is not defined in the XPath
> > > context
> > >
> > > Is this correct? Or are XPath functions expected to be resolved
> > > statically, like types?
>
> I don't think it is correct to reject this construct.  The definition
> is done in a 1.1 module and can only be implemented in a server that
> supports 1.1.
>
> It seems a bit odd that "ietf-connectionless-oam-methods" is defined
> in YANG 1.0 though, but that's a different issue...
>
>
>From 7950, sec 12:

  If a YANG version 1 module A imports module B without revision and

   module B is updated to YANG version 1.1, a server MAY implement both
   of these modules (A and B) at the same time.  In such cases, a
   NETCONF server MUST advertise both modules using the rules defined in
   Section 5.6.4 ,
and SHOULD advertise module A and the latest revision
   of module B that is specified with YANG version 1 according to the
   rules defined in [RFC6020 ].

   This rule exists in order to allow implementations of existing YANG
   version 1 modules together with YANG version 1.1 modules.  Without
   this rule, updating a single module to YANG version 1.1 would have a
   cascading effect on modules that import it, requiring all of them to
   also be updated to YANG version 1.1, and so on.




This is probably not implemented, or implementable, by many servers.


1) what if module 'B' has no latest YANG 1.0 revision?
This can happen if A is updated to import B, but yang-version is not
changed in A

2) What if NBC changes have been made in module B?
How does the cited text work with SEMVER and new versioning rules?

3) What if the server implements some new definitions in B that are not  in
the latest YANG 1.0 version of B?
New YANG library does not allow more than 1 revision of an implemented
module to be represented in a module-set.

4) What if a leafref in A points to a leaf using a typedef in B, yet the
type is not allowed in YANG 1.0?
   (e.g., empty type in a union)?  How much YANG 1.1 is allowed to leak
into a YANG 1.0 module?)

5) Isn't module A parsed under YANG 1.0 rules, because its
yang-version-stmt is set to "1"?




> /martin
>
>
Andy


> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

On Mon, 2019-10-21 at 14:54 +, Kent Watsen wrote:
> Hi Lada, 
> 
> > Another option, also suggested in DNSOP WG, was to enable YANG to refer
> > directly to the IANA registry.
> 
> For crypto types, I don’t know if this it possible, as there may be many
> registries involved. 
> 
> Regardless, what is it that is doing the referring?  an identityref?  there
> needs to be a module update, not just a ref, right?  or do you mean that the
> type is “string” and the values are documented to be from said IANA
> registries?

This is of course a good question. I think an implicit enumeration could be a
good fit for many registries.

> 
> 
> > The problem with this is that we have no formalism for writing such
> > templates.
> 
> True. 
> 
> > > How about preparing an initial revision of the module, without writing any
> > > RFC, and hand it over to IANA to be published as a
> > > supplement to the registry?
> 
> I don’t understand.  Can you give a sketch of what you have in mind?

Just prepare the module and run it through some defined approval procedure. The
module will become official as soon as IANA publishes it on the "YANG
Parameters" page [1]. After that, IANA will update the module each time the
registry changes - the instructions for updates may be a part of the module
description. But there will be no RFC connected to the module.

Lada

[1] https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

> 
> 
> 
> Kent 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Kent Watsen]

Hi Lada, 

> Another option, also suggested in DNSOP WG, was to enable YANG to refer 
> directly to the IANA registry.

For crypto types, I don’t know if this it possible, as there may be many 
registries involved. 

Regardless, what is it that is doing the referring?  an identityref?  there 
needs to be a module update, not just a ref, right?  or do you mean that the 
type is “string” and the values are documented to be from said IANA registries?


> The problem with this is that we have no formalism for writing such templates.

True. 

>> How about preparing an initial revision of the module, without writing any 
>> RFC, and hand it over to IANA to be published as a
>> supplement to the registry?

I don’t understand.  Can you give a sketch of what you have in mind?



Kent 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Last Call: (YANG Data Structure Extensions) to Proposed Standard

[The IESG]

The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'YANG Data Structure Extensions'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2019-11-04. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document describes YANG mechanisms for defining abstract data
   structures with YANG.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/ballot/


No IPR declarations have been submitted directly on this I-D.




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA registries

[Ladislav Lhotka]

Kent Watsen  writes:

> All,
>
>>> That's a bit odd.  But perhaps it can be solved by actually not
>>> filling in all values in this module, but rather make it a template
>>> and instruct IANA to fill it in with the contents of the registry at
>>> the time of publication.
>> 
>> OK, so the module template in the RFC couldn't be used at all - this might
>> indeed help.
>
> This is an interesting proposal indeed, and one that may help with the 
> crypto-types "algorithm" discussion as well.
>
> Having IANA be able to automatically publish revisions for select
> module is something that has been discussed in the past, partially
> in NETCONF wrt crypto-types, to eliminate the need for expensive RFC
> cycles, for updates that needed as a reaction to other RFCs being
> published, which should also have the effect of shortening the time
> it takes for those updates to be made.

Another option, also suggested in DNSOP WG, was to enable YANG to refer 
directly to the IANA registry.

>
> AFAIK, no such relationship with IANA exists currently anywhere
> within the IETF.  To move this idea forward, the chairs need to
> discuss with the AD.  It might aid that discussion if there were an
> example template module...anyone want to a stab at one?

The problem with this is that we have no formalism for writing such templates.

>
> Should there be an I-D that lays out the framework for the agreement
> with IANA, or would each draft (e.g., crypto-types) lay it out just
> for itself?  Actually, this sounds like what might come out of the
> discussion with the AD, but thoughts now are welcome to.

How about preparing an initial revision of the module, without writing any RFC, 
and hand it over to IANA to be published as a supplement to the registry?

Lada

>
> Kent // as co-chair

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref and identityref

[Ladislav Lhotka]

On Mon, 2019-10-21 at 14:01 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Mon, 2019-10-21 at 13:40 +0200, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > consider the following situation:
> > > > 
> > > > module A {
> > > >   ...
> > > >   prefix a
> > > >   identity X;
> > > >   leaf foo {
> > > > type identityref {
> > > >   base X;
> > > > }
> > > >   }
> > > > }
> > > > 
> > > > module B {
> > > >   ...
> > > >   import A {
> > > > prefix a;
> > > >   }
> > > >   leaf fooref {
> > > > type leafref {
> > > >   path "/a:foo";
> > > > }
> > > >   }
> > > > }
> > > > 
> > > > What is now a correct lexical form of fooref's value? Could it be just
> > > > 'X', or is the prefix required, i.e. 'a:X'?
> > > > 
> > > > This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am
> > > > inclined to require the prefix.
> > > 
> > > 9.10.3 says:
> > > 
> > >If the prefix is not
> > >present, the namespace of the identityref is the default namespace
> > >in effect on the element that contains the identityref value.
> > > 
> > > 
> > > so the interpretation of a missing prefix in "fooref" is that the
> > > identity is defined in module B.
> > > 
> > > (a missing prefix in "foo" means that the identity is defined in
> > > module A)
> > 
> > To be more specific, here is an example instance:
> > 
> > X
> > X
> > 
> > It can be argued that this is correct because (sec. 9.9.4):
> > 
> >A leafref value is lexically represented the same way as the leaf it
> >references represents its value.
> > 
> > That is, the same lexical representation is assumed, which is exactly what
> we
> > have in the example.
> 
> It doesn't say that the lexical value is exactly the same, but
> "represented the same way" - so when the lexical representation is
> context dependent we have this situation.

OK, but still: foo represents its value using the default namespace on ,
which is "...namespace of A...". That's why

X

is correct. And if the fooref value is LEXICALLY represented the same way, then
it has to be "X" as well (this is what lexical space value means in XML).

What we probably mean is something like

   The rules for a leafref value are obtained by pretending that the leaf has 
   the same type as the referenced leaf.

Lada  

> 
> > It seems that we agree that it is incorrect, but then sec. 9.9.4 should be
> > clarified.
> 
> 
> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

[Martin Bjorklund]

Jernej Tuljak  wrote:
> Should I clarify my question?
> 
> Jernej
> 
> On 10/10/2019 10:36, Jernej Tuljak wrote:
> > Hi,
> >
> > there is at least one YANG 1.0 standard module that imports and uses
> > groupings from a YANG 1.1 standard module and at least one such
> > grouping contains must/when statements referencing XPath functions
> > that are not available in 1.0 XPath context.
> >
> > The modules I'm referring to are part of RFC8533 [1] and RFC8532
> > [2]. ietf-connectionless-oam-methods (a 1.0 module) uses
> > cl-oam:tp-address from ietf-connectionless-oam (a 1.1 module), which
> > calls "derived-from-or-self" in a when expression of a used
> > node. These RFCs were published in April.
> >
> > Our tools complain about "derived-from-or-self" not being defined in
> > ietf-connectionless-oam-methods's XPath context:
> >
> > [Error];
> > ietf-connectionless-oam-methods@2019-04-16:/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when;
> > XPath function "derived-from-or-self" is not defined in the XPath
> > context
> >
> > Is this correct? Or are XPath functions expected to be resolved
> > statically, like types?

I don't think it is correct to reject this construct.  The definition
is done in a 1.1 module and can only be implemented in a server that
supports 1.1.

It seems a bit odd that "ietf-connectionless-oam-methods" is defined
in YANG 1.0 though, but that's a different issue...


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

[Jernej Tuljak]

Should I clarify my question?

Jernej

On 10/10/2019 10:36, Jernej Tuljak wrote:

Hi,

there is at least one YANG 1.0 standard module that imports and uses 
groupings from a YANG 1.1 standard module and at least one such 
grouping contains must/when statements referencing XPath functions 
that are not available in 1.0 XPath context.


The modules I'm referring to are part of RFC8533 [1] and RFC8532 [2]. 
ietf-connectionless-oam-methods (a 1.0 module) uses cl-oam:tp-address 
from ietf-connectionless-oam (a 1.1 module), which calls 
"derived-from-or-self" in a when expression of a used node. These RFCs 
were published in April.


Our tools complain about "derived-from-or-self" not being defined in 
ietf-connectionless-oam-methods's XPath context:


[Error]; 
ietf-connectionless-oam-methods@2019-04-16:/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when; 
XPath function "derived-from-or-self" is not defined in the XPath context


Is this correct? Or are XPath functions expected to be resolved 
statically, like types?


Jernej

[1] - https://tools.ietf.org/html/rfc8533
[2] -https://tools.ietf.org/html/rfc8532

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref and identityref

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Mon, 2019-10-21 at 13:40 +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > Ladislav Lhotka  wrote:
> > > Hi,
> > > 
> > > consider the following situation:
> > > 
> > > module A {
> > >   ...
> > >   prefix a
> > >   identity X;
> > >   leaf foo {
> > > type identityref {
> > >   base X;
> > > }
> > >   }
> > > }
> > > 
> > > module B {
> > >   ...
> > >   import A {
> > > prefix a;
> > >   }
> > >   leaf fooref {
> > > type leafref {
> > >   path "/a:foo";
> > > }
> > >   }
> > > }
> > > 
> > > What is now a correct lexical form of fooref's value? Could it be just
> > > 'X', or is the prefix required, i.e. 'a:X'?
> > > 
> > > This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am
> > > inclined to require the prefix.
> > 
> > 9.10.3 says:
> > 
> >If the prefix is not
> >present, the namespace of the identityref is the default namespace
> >in effect on the element that contains the identityref value.
> > 
> > 
> > so the interpretation of a missing prefix in "fooref" is that the
> > identity is defined in module B.
> > 
> > (a missing prefix in "foo" means that the identity is defined in
> > module A)
> 
> To be more specific, here is an example instance:
> 
> X
> X
> 
> It can be argued that this is correct because (sec. 9.9.4):
> 
>A leafref value is lexically represented the same way as the leaf it
>references represents its value.
> 
> That is, the same lexical representation is assumed, which is exactly what we
> have in the example.

It doesn't say that the lexical value is exactly the same, but
"represented the same way" - so when the lexical representation is
context dependent we have this situation.

> It seems that we agree that it is incorrect, but then sec. 9.9.4 should be
> clarified.




/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref and identityref

[Ladislav Lhotka]

On Mon, 2019-10-21 at 13:40 +0200, Martin Bjorklund wrote:
> Hi,
> 
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > consider the following situation:
> > 
> > module A {
> >   ...
> >   prefix a
> >   identity X;
> >   leaf foo {
> > type identityref {
> >   base X;
> > }
> >   }
> > }
> > 
> > module B {
> >   ...
> >   import A {
> > prefix a;
> >   }
> >   leaf fooref {
> > type leafref {
> >   path "/a:foo";
> > }
> >   }
> > }
> > 
> > What is now a correct lexical form of fooref's value? Could it be just
> > 'X', or is the prefix required, i.e. 'a:X'?
> > 
> > This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am
> > inclined to require the prefix.
> 
> 9.10.3 says:
> 
>If the prefix is not
>present, the namespace of the identityref is the default namespace
>in effect on the element that contains the identityref value.
> 
> 
> so the interpretation of a missing prefix in "fooref" is that the
> identity is defined in module B.
> 
> (a missing prefix in "foo" means that the identity is defined in
> module A)

To be more specific, here is an example instance:

X
X

It can be argued that this is correct because (sec. 9.9.4):

   A leafref value is lexically represented the same way as the leaf it
   references represents its value.

That is, the same lexical representation is assumed, which is exactly what we
have in the example.

It seems that we agree that it is incorrect, but then sec. 9.9.4 should be
clarified.

Lada
 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] leafref and identityref

[Martin Bjorklund]

Hi,

Ladislav Lhotka  wrote:
> Hi,
> 
> consider the following situation:
> 
> module A {
>   ...
>   prefix a
>   identity X;
>   leaf foo {
> type identityref {
>   base X;
> }
>   }
> }
> 
> module B {
>   ...
>   import A {
> prefix a;
>   }
>   leaf fooref {
> type leafref {
>   path "/a:foo";
> }
>   }
> }
> 
> What is now a correct lexical form of fooref's value? Could it be just
> 'X', or is the prefix required, i.e. 'a:X'?
> 
> This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am
> inclined to require the prefix.

9.10.3 says:

   If the prefix is not
   present, the namespace of the identityref is the default namespace
   in effect on the element that contains the identityref value.


so the interpretation of a missing prefix in "fooref" is that the
identity is defined in module B.

(a missing prefix in "foo" means that the identity is defined in
module A)



/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] leafref and identityref

[Ladislav Lhotka]

Hi,

consider the following situation:

module A {
  ...
  prefix a
  identity X;
  leaf foo {
type identityref {
  base X;
}
  }
}

module B {
  ...
  import A {
prefix a;
  }
  leaf fooref {
type leafref {
  path "/a:foo";
}
  }
}

What is now a correct lexical form of fooref's value? Could it be just 'X', or 
is the prefix required, i.e. 'a:X'?

This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am inclined 
to require the prefix.

Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Genart telechat review of draft-ietf-netmod-yang-data-ext-04

[Martin Bjorklund]

Hi,

Brian Carpenter via Datatracker  wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Nits
> 
> Gen-ART Last Call & telechat review of draft-ietf-netmod-yang-data-ext-04
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-netmod-yang-data-ext-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2019-10-20
> IETF LC End Date: TBD
> IESG Telechat date: 2019-10-31
> 
> Summary: Ready with nits
> 
> 
> Comments: 
> -
> 
> This was accidentally put on the IESG agenda without an IETF Last Call,
> so this review serves both purposes.
> 
> The draft seems very clear and I have no technical comments.
> 
> Nits:
> -
> 
> > Updates: 8340 (if approved)
> > Intended status: Standards Track
> 
> RFC 8340 is a BCP, so can this really be Standards Track?
> Shouldn't it also be BCP, extending BCP 215? It's tricky,
> because it also effectively extends RFC 8040, which is
> Standards Track rather than BCP. Sadly it doesn't seem that
> a document can be both BCP and Standards Track.

Hmm, the main contribution in this document (the "structure"
extension), is not suitable as a BCP.  It is really just section 3
that updates 8340.  I don't know to to resolve this, and will look at
the document shepard for guidance!

> Also, this draft says:
> 
> >   The "yang-data" extension from [RFC8040] has been copied here,
> >   renamed to "structure", and updated to be more flexible.
> 
> That reads as if RFC 8040 is also updated, and it leaves the
> status of "yang-data" unclear. Is it now deprecated? Perhaps the
> sentence would be clearer like this:
> 
>   This document defines a new YANG extension statement called
>   "structure", which is similar to but more flexible than the
>   "yang-data" extension from [RFC8040].


Thank you, this is better!


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

Alexey Melnikov via Datatracker  wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-netmod-yang-data-ext-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/
> 
> 
> 
> --
> COMMENT:
> --
> 
> This is a fine document.
> 
> Can you show and example similar to what in A.3 with 2 addressbook entries?

The example isn't really written to handle more than one address
book.  The structure defines one single address book.  But perhaps I
misunderstood your question?


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Barry Leiba's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

Hi,

Barry Leiba via Datatracker  wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-netmod-yang-data-ext-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/
> 
> 
> 
> --
> COMMENT:
> --
> 
> A fine extension.  Just three editorial nits:
> 
> -- Section 1 —
> 
>There is no
>assumption that a YANG data structure can only be used as a top-level
>abstraction, instead of nested within some other data structure.
> 
> It’s a little odd to use “instead of” after “there is no assumption”; I can’t
> explain it fully, but it feels odd to this native English speaker.  I suggest
> this:
> 
> NEW
>There is no
>assumption that a YANG data structure can only be used as a top-level
>abstraction, and it may also be nested within some other data structure.
> END
> 
>similar to the existing YANG "augment" statement.
> 
> Make it “similarly”.
> 
> — Section 1.1.1 —
> 
>The following terms are defined in the Network Management Datastore
>Architecture (NMDA) [RFC8342].  and are not redefined here:
> 
> The period after the citation should be a comma.

Thanks for these suggestions, I have applied them all.


/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod