Re: [netmod] Adding system configuration to running

[Martin Bjorklund]

Andy Bierman  wrote:
> On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen  wrote:
> > > Maybe it is too early for NMDA to be making lots of rules about how
> >
> > > YANG works with new (and unimplemented) datastores.
> >
> >
> >
> > Juniper has the equivalent of  already.  I think others said
> > they had
> >
> > something like it as well.

Yes, we have that as well.  (No template expansion, but removal of
inactive nodes).

> If I can only do YANG validation on expanded templates in , does
> that mean
> it is impossible to do YANG validation on the templates themselves in
> ?
> The template subtree can only use YANG constraints on external structures
> in 
> and not refer to itself in anyway (in )?

Note that the architecture draft does not specify any templating
mechanism, it merely points out that templating is a mechanism that
_can_ influence intended.  When/if such a mechanism is designed, it
needs to work out all these details.


/martin


> 
> The RD draft sure has a lot of normative details for something that does
> not use RFC 2119
> terminology at all. I didn't know a Standards Track document could omit
> these terms.
> Architecture documents are usually Informational.
> 
> IMO the RD draft should not mention YANG or XPath at all.
> That should be moved to an update to RFC 7950.
> Those parts need more work anyway. The ARCH can move forward
> without any dependence on YANG details.
> 
> 
> 
> > Kent // contributor
> >
> >
> >
> >
> >
> 
> Andy

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

Re: [netmod] WGLC for draft-ietf-tictoc-1588v2-yang

[Alex Campbell]

Hi,
I've reviewed the draft and found the following issues.

* YANG enumeration values are conventionally lowercase, but the 
delay-mechanism-enumeration and port-state-enumeration types in the draft have 
uppercase values.
* Similarly, hyphens should be used rather than underscores (pre-master instead 
of PRE_MASTER)
* number-ports doesn't read naturally in English; I suggest renaming it to 
number-of-ports.
* The description of port-ds-list contains a typo - "memer" instead of "member".
* There's no need to have groupings that are only used once (such as 
parent-ds-entry, current-ds-entry, default-ds-entry, 
transparent-clock-default-ds-entry, port-ds-entry, 
transparent-clock-default-ds-entry, and so on) unless this is for 
futureproofing or some other reason I'm not aware of.
* Is it necessary to include -ds in the name of every leaf, container and 
grouping?

Note I'm not familiar with IEEE 1588, apart from a brief look through it just 
now.

Alex



From: netmod  on behalf of Jiangyuanlong 

Sent: Friday, 15 September 2017 1:42 p.m.
To: netmod@ietf.org
Cc: tic...@ietf.org
Subject: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang

Hi netmoders,

This draft does not tackle the general YANG problem, but provide a generic time 
synchronization module of 1588.
Some of you may have interests in time synchronization, some definitely not. 
But as experts in YANG, could you please have a review of this YANG module and 
give an expert opinion?

Thanks,
Yuanlong

-Original Message-
From: TICTOC [mailto:tictoc-boun...@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, September 14, 2017 3:16 AM
To: tic...@ietf.org
Cc: n...@ietf.org
Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

Folks,

This message begins a 2 week working group last call (WGLC) for the following 
document:

YANG Data Model for IEEE 1588v2
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

Please review the referenced document and send any comments to the mailing list 
including your assessment of whether this document is mature enough to proceed 
to the IESG. Please note that these messages of support for progression to the 
mailing list are important and will be used to determine WG consensus to 
proceed.

Please send all comments in by Thursday 28 September 2017.

Thank you!
Karen
___
TICTOC mailing list
tic...@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

___
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] Adding system configuration to running [was: Re: Comments on NMDA-04]

[Andy Bierman]

On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen  wrote:

>
>
>
>
>
>
> > I agree with Balazs that system-created nodes in running are quite
> common and
>
> > the vendors doing it have no intention of changing it.
>
>
>
> Of course, what else were they going to do pre-NMDA…and also before
> require-instance
>
> false?  Green-field deployments wouldn't be encumbered with
> backwards-compatibility.
>
> Existing implementations are in a bind, but I'd recommend following
> nmda-guidelines.
>
>
>


This might break non-NMDA clients expecting to see the system-created config
in retrieval responses. I think vendors will decide their own transition
plans
and decide how much disruption at once is OK.



> For UC1: the loopback would only show in  (as an applied
> instance of a
>
> config true leaf), and the leafref would be require-instance false.  When
> committing
>
> configuration that referenced loopback, the server sees that the
> referenced leaf is not in
>
> /, but it could see that it is or is-not in
> .  And, if it
>
> is not in , the server might return a warning to the client,
> or not, assuming
>
> the  client will use other mechanisms to discover what configuration was
> not applied.
>
>
>
> For UC2: similar response.  The server could return a warning (e.g., a
> synchronous
>
> update) or the client can discover the unapplied config afterwards using
> other
>
> mechanisms.
>
>
>
>
>
> > If the added nodes need to be saved in non-volatile storage then then
> definitely
>
> > belong in .
>
>
>
> Neither of Balazs's use-cases regard persisted data, at least I didn't
> read it that way.
>
>
>
>
>
> > IMO the architecture is rather opaque wrt/ the interactions between
> datastores,
>
> > especially the interactions between  and . Now it not
> only
>
> > prunes inactive nodes, it adds system nodes?
>
>
>
> A template in  could be flattened, which has the apparent
> side-effect
>
> of creating nodes, but not any nodes, just those per the input from
> .
>
> As the draft says:  does not persist across reboots; its
> relationship
>
> with  makes that unnecessary.   Generically speaking, 
>
> can contain processing instructions that are consumed at commit time to
>
> simultaneously create the  view, and these PIs are the only thing
>
> that can cause a deviation between the two datastores.
>
>
>
>
>
> > Maybe it is too early for NMDA to be making lots of rules about how
>
> > YANG works with new (and unimplemented) datastores.
>
>
>
> Juniper has the equivalent of  already.  I think others said
> they had
>
> something like it as well.
>
>
>
>
>

If I can only do YANG validation on expanded templates in , does
that mean
it is impossible to do YANG validation on the templates themselves in
?
The template subtree can only use YANG constraints on external structures
in 
and not refer to itself in anyway (in )?

The RD draft sure has a lot of normative details for something that does
not use RFC 2119
terminology at all. I didn't know a Standards Track document could omit
these terms.
Architecture documents are usually Informational.

IMO the RD draft should not mention YANG or XPath at all.
That should be moved to an update to RFC 7950.
Those parts need more work anyway. The ARCH can move forward
without any dependence on YANG details.



> Kent // contributor
>
>
>
>
>

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

Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]

[Kent Watsen]

> I agree with Balazs that system-created nodes in running are quite common and
> the vendors doing it have no intention of changing it.

Of course, what else were they going to do pre-NMDA…and also before 
require-instance
false?  Green-field deployments wouldn't be encumbered with 
backwards-compatibility.
Existing implementations are in a bind, but I'd recommend following 
nmda-guidelines.

For UC1: the loopback would only show in  (as an applied instance 
of a
config true leaf), and the leafref would be require-instance false.  When 
committing
configuration that referenced loopback, the server sees that the referenced 
leaf is not in
/, but it could see that it is or is-not in .  
And, if it
is not in , the server might return a warning to the client, or 
not, assuming
the  client will use other mechanisms to discover what configuration was not 
applied.

For UC2: similar response.  The server could return a warning (e.g., a 
synchronous
update) or the client can discover the unapplied config afterwards using other
mechanisms.


> If the added nodes need to be saved in non-volatile storage then then 
> definitely
> belong in .

Neither of Balazs's use-cases regard persisted data, at least I didn't read it 
that way.


> IMO the architecture is rather opaque wrt/ the interactions between 
> datastores,
> especially the interactions between  and . Now it not only
> prunes inactive nodes, it adds system nodes?

A template in  could be flattened, which has the apparent side-effect
of creating nodes, but not any nodes, just those per the input from .
As the draft says:  does not persist across reboots; its relationship
with  makes that unnecessary.   Generically speaking, 
can contain processing instructions that are consumed at commit time to
simultaneously create the  view, and these PIs are the only thing
that can cause a deviation between the two datastores.


> Maybe it is too early for NMDA to be making lots of rules about how
> YANG works with new (and unimplemented) datastores.

Juniper has the equivalent of  already.  I think others said they had
something like it as well.


Kent // contributor


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

Re: [netmod] upcoming adoptions

[Juergen Schoenwaelder]

On Thu, Sep 14, 2017 at 01:06:28PM -0400, Lou Berger wrote:
> 
> Actually, strictly speaking, any text in a Standards Track
> RFC that doesn't include RFC2119 language is just informative.
>

I very doubt this is true. But then, I have seen so many different
interpretations of RFC 2119 language over the years that I personally
believe that RFC 2119 usage is to a large extend random and in most
cases practically pointless.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Proposal to enhance the YANG tree output

[Joe Clarke]

On 9/14/17 13:50, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> Hi,
>>
>>
>> Actually I liked the early pyang output that was concise and easy to
>> remember.
>> The current format gets very cluttered and there are too many little symbols
>> to remember them all.
> 
> I agree with Andy.  I also did some experiments with printing
> enumerations, and they work ok for small enums.  But once you have
> more than a handful they do tend to clutter the output.  Even worse so
> for trees that go into RFCs (where lines need to be < 70 characters).

What about protecting this with an optional parameter?  I certainly
appreciate the output could be large, but I think it does have its uses
sometimes.

Joe

> 
> Lada is sometimes using a format with even less information, where he
> has removed all type information, focusing more on the structure.
> 
> 
> /martin
> 
> 
> 
>>
>>
>> Andy
>>
>>
>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
>>
>>> I've been hacking on pyang, and I changed tree.py to add the enum values
>>> for enumeration types and identiyref bases for identityref types.  Here
>>> is an example:
>>>
>>> module: yang-catalog
>>> +--rw catalog
>>>+--rw modules
>>>|  +--rw module* [name revision organization]
>>>| +--rw name yang:yang-identifier
>>>| +--rw revision union
>>>| +--rw organization string
>>>| +--rw ietf
>>>| |  +--rw ietf-wg?   string
>>>| +--rw namespaceinet:uri
>>>| +--rw schema?  inet:uri
>>>| +--rw generated-from?  enumeration [mib, code,
>>> not-applicable, native]
>>>| +--rw maturity-level?  enumeration [ratified,
>>> adopted, initial, not-applicable]
>>> ...
>>>+--rw protocols
>>>|  +--rw protocol* [name]
>>>| +--rw name
>>> identityref -> protocol
>>> ...
>>>
>>> My questions are:
>>>
>>> 1. Is this useful?
>>>
>>> 2. If so, can this be added to pyang (happy to submit a PR) and
>>> draft-ietf-netmod-yang-tree-diagrams?
>>>
>>> 3. What changes to the output format would you recommend?
>>>
>>> Thanks.
>>>
>>> Joe
>>>
>>> ___
>>> 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] Proposal to enhance the YANG tree output

[Martin Bjorklund]

Andy Bierman  wrote:
> Hi,
> 
> 
> Actually I liked the early pyang output that was concise and easy to
> remember.
> The current format gets very cluttered and there are too many little symbols
> to remember them all.

I agree with Andy.  I also did some experiments with printing
enumerations, and they work ok for small enums.  But once you have
more than a handful they do tend to clutter the output.  Even worse so
for trees that go into RFCs (where lines need to be < 70 characters).

Lada is sometimes using a format with even less information, where he
has removed all type information, focusing more on the structure.


/martin



> 
> 
> Andy
> 
> 
> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
> 
> > I've been hacking on pyang, and I changed tree.py to add the enum values
> > for enumeration types and identiyref bases for identityref types.  Here
> > is an example:
> >
> > module: yang-catalog
> > +--rw catalog
> >+--rw modules
> >|  +--rw module* [name revision organization]
> >| +--rw name yang:yang-identifier
> >| +--rw revision union
> >| +--rw organization string
> >| +--rw ietf
> >| |  +--rw ietf-wg?   string
> >| +--rw namespaceinet:uri
> >| +--rw schema?  inet:uri
> >| +--rw generated-from?  enumeration [mib, code,
> > not-applicable, native]
> >| +--rw maturity-level?  enumeration [ratified,
> > adopted, initial, not-applicable]
> > ...
> >+--rw protocols
> >|  +--rw protocol* [name]
> >| +--rw name
> > identityref -> protocol
> > ...
> >
> > My questions are:
> >
> > 1. Is this useful?
> >
> > 2. If so, can this be added to pyang (happy to submit a PR) and
> > draft-ietf-netmod-yang-tree-diagrams?
> >
> > 3. What changes to the output format would you recommend?
> >
> > Thanks.
> >
> > Joe
> >
> > ___
> > 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] Adding system configuration to running [was: Re: Comments on NMDA-04]

[Andy Bierman]

On Thu, Sep 14, 2017 at 10:08 AM, Robert Wilton  wrote:

>
>
> On 14/09/2017 16:35, Balazs Lengyel wrote:
>
> See below!
> On 2017-09-14 16:32, Martin Bjorklund wrote:
>
> Hi Balazs,
>
> Thanks for your review.  Comments inline.
>
> Balazs Lengyel   
> wrote:
>
> Hello,
>
> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
>
> General) The system often adds data to the  or 
> datastore already not just to : e.g.
>
> UC1: I have a server configured in running. I need to bind it to an
> ip-address. The ip-address might be the local loopback address,
> however if that is only added to , validation will
> fail indicating that the server is bound to a non-existent
> address. How to handle this?
>
> UC2: I have a set of capabilities set by the system
> e.g. supported-reporting-intervals. I need to configure a job that
> MUST use one of these intervals. If the supported-reporting-intervals
> are only added to  I can not validate the
> selected-interval in my configured job.
>
> My proposal is to allow the system to add data to running as
> well. Actually I think that is a more relevant case then adding
> configuration just to .
>
> I think the consensus is that in general it is a bad idea if servers
> (spontaneously) add data to .  However, there is nothing in
> the new or old architectures that prohibits this.
>
> BALAZS: I strongly disagree.  I know others are also adding stuff to
> running as well.
> IMHO the above use cases are real and used and actually important for us.
> I would like to see them included in some way.
>
> I basically agree with Martin here.
>
> The architecture is cleaner if  is only written by the client.
> This avoid requiring clients tracking unexpected changes to running, and
> opens up the possibility of validating configuration off the box.  Ideally
> extra stuff should be added into  and then become visible in
> .
>
> I understand that some systems add data to , and this is fine.
> But I think that it is better for an architecture document to be silent on
> this point.
>
>
I agree with Balazs that system-created nodes in running are quite common
and
the vendors doing it have no intention of changing it.

If the added nodes need to be saved in non-volatile storage then then
definitely belong in .

IMO the architecture is rather opaque wrt/ the interactions between
datastores,
especially the interactions between  and . Now it not
only
prunes inactive nodes, it adds system nodes?

Maybe it is too early for NMDA to be making lots of rules about how YANG
works
with new (and unimplemented) datastores.



Thanks,
> Rob
>
>
Andy


>
>
> regards Balazs
>
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
>
>
> ___
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> ___
> 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] Adding system configuration to running [was: Re: Comments on NMDA-04]

[Robert Wilton]

On 14/09/2017 16:35, Balazs Lengyel wrote:


See below!

On 2017-09-14 16:32, Martin Bjorklund wrote:

Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel  wrote:

Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the  or 
datastore already not just to : e.g.

UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to , validation will
fail indicating that the server is bound to a non-existent
address. How to handle this?

UC2: I have a set of capabilities set by the system
e.g. supported-reporting-intervals. I need to configure a job that
MUST use one of these intervals. If the supported-reporting-intervals
are only added to  I can not validate the
selected-interval in my configured job.

My proposal is to allow the system to add data to running as
well. Actually I think that is a more relevant case then adding
configuration just to .

I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to .  However, there is nothing in
the new or old architectures that prohibits this.
BALAZS: I strongly disagree.  I know others are also adding stuff to 
running as well.

IMHO the above use cases are real and used and actually important for us.
I would like to see them included in some way.

I basically agree with Martin here.

The architecture is cleaner if  is only written by the client.  
This avoid requiring clients tracking unexpected changes to running, and 
opens up the possibility of validating configuration off the box.  
Ideally extra stuff should be added into  and then become 
visible in .


I understand that some systems add data to , and this is fine.  
But I think that it is better for an architecture document to be silent 
on this point.


Thanks,
Rob




regards Balazs
--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email:balazs.leng...@ericsson.com  



___
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] upcoming adoptions

[Lou Berger]

On 9/14/2017 12:36 PM, t.petch wrote:
> Appendices are Normative if they say that they are Normative.  The
> default is that they are not so say that they are and they are.  This is
> well established practice.

Hi Tom,
    My memory (I haven't checked recently) is there is nothing in or
defined process that says if an Appendix is normative or not.  Other
SDOs certainly have formal definitions here.  Within the IETF, my view
has been that if an appendix includes RFC2119 language, it is
normative.  Actually, strictly speaking, any text in a Standards Track
RFC that doesn't include RFC2119 language is just informative.

Lou
 

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

Re: [netmod] Comments on NMDA-04

[Robert Wilton]

Hi Balazs,

Thanks for the review and comments.


On 14/09/2017 16:44, Balazs Lengyel wrote:

See below !


On 2017-09-14 16:32, Martin Bjorklund wrote:


CH 4.4.)  "Validation is performed on the contents of ."
This to me means that default data is not considered at validation

Note that RFC 7950, section 6.4.1, says:

    In the accessible tree, all leafs and leaf-lists with default values
    in use exist (see Sections 7.6.1 and 7.7.2).

So defaults are taken into account when intended is validated.
BALAZS: Yes the two seem to contradict each other. This can be 
understood in your way, however the current text is not clear enough. 
I would add:
Validation is performed on the contents of  (EXTENDED WITH 
DEFAULT CONFIGURATION).
As an alternative suggestion, rather than saying contents of , 
we could instead say something like "must always be a valid 
configuration data tree.". Is that better?  I would rather not talk 
about "defaults for  since that may imply that they are not 
applicable to other configuration datastores".  E.g. if  is 
validated then you would also expect defaults to be considered. Ditto 
for startup, candidate.


Thanks,
Rob



which would be a backwards incompatible change. Also if validation
does not consider system configured data that would allow cases like
multiple interfaces named lo0. One from  one from system
configuration. IMHO while it is OK to violate uniqueness because of
remnant data, the above violation of uniqueness seems a bad idea.

If your system adds data to , or to , it will be
validated.


Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
should not be.

Agreed.  Note that the draft explicitly lists the constraints that can
be violated, and uniqueness of keys is not listed.
BALAZS: If that is the intent I would propose to explicitly state it. 
For me it was non-trivial.
Can a a choice statement be violated? Having to existing branches at 
the same time? It seems a semantic constraint to me. IMHO yes.
Can an if-feature be violated? If  support has just changed and we 
have some remnant config, I can very well imagine it violated.


Also here could you change
If a node in   does not meet the syntactic constraints 
then it cannot   be returned

to
If a node in   does not meet the syntactic constraints 
then it MUST NOT be returned

/martin




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

Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton

[t.petch]

Lou

I am proposing that the text I included would go more or less as is into
the beginning of section 3.  I think that it makes sense even before we
get into the historic definitions of configuration etc.  I want to spell
out the problem - two different values of the one conceptual object,
originally handled with two schema nodes in one store of data, now
handled with one schema node in two datastores.  Thus start section 3
with

NEW

Some data objects can take two different values, the one configured by
the user (configuration), the other the one that the device is using
(operational state),
perhaps as a result of interactions with hardware, with protocols, with
other devices and so on.

 The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and, since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach, such as can be seen in RFC7277 or RFC7223.

This duplication of definitions and separation of operationsl state from
configuration leads to a number of problems.  Having them in
 separate branches in the data model is operationally
complicated and impacts the readability of module
 definitions.  The relationship between
 the branches is not machine readable and filter expressions operating
on configuration and on related operational state are different.

With revised datastores,  the data object appears once in the model
but can appear in two datastores, one for the
configured value, one for the operational state value.

 Instead of two YANG data nodes there is one data node in two
datastores, a more elegant and simpler solution to the problem.

/NEW

I would make minor changes to the last three paragraphs of Section 3
mostly excising where I have already included that material

Tom Petch

> >
> > The problem that is hinted at but never explicitly stated is that
data
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >separate branch in the data model has been found to be
operationally
> >complicated and impacts the readability of module
> >definitions.  The relationship between
> >the branches is not machine readable and filter expressions
operating
> >on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >
ta
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >separate branch in the data model has been found to be
operationally
> >complicated and impacts the readability of module
> >definitions.  The relationship between
> >the branches is not machine readable and filter expressions
operating
> >on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >

Tom Petch

- Original Message -
From: "Lou Berger" 
To: "t.petch" ; "netmod WG" 
Cc: ;

Sent: Wednesday, September 13, 2017 5:56 PM
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-revised-datastores-04 duplicaiton


> > I believe that text such as this would make the I-D much easier to
> > follow.  As it stands, you have to read between the lines and
speculate.
> Tom,
>
> Thank you for the comments. Do you have a specific change in mind,
> or could your propose text, 

Re: [netmod] Proposal to enhance the YANG tree output

[Joe Clarke]

On 9/14/17 12:13, Balazs Lengyel wrote:
> Did you consider to have a concise and a verbose tree output selected by
> an option?

I did.  I wanted to get some broader feedback, but I figured people
would want something like --tree-print-expanded-types or the like.

Joe

> 
> regards Balazs
> 
> 
> On 2017-09-14 17:58, Joe Clarke wrote:
>> On 9/14/17 11:43, Andy Bierman wrote:
>>> Hi,
>>>
>>>
>>> Actually I liked the early pyang output that was concise and easy to
>>> remember.
>>> The current format gets very cluttered and there are too many little
>>> symbols
>>> to remember them all.
>> I just went with text for these changes.  Yes, it adds more verbiage to
>> the output, but it doesn't add any cryptic symbols; plus I think it
>> makes it easier to comprehend the types.
>>
>> Joe
>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke >> > wrote:
>>>
>>>  I've been hacking on pyang, and I changed tree.py to add the
>>> enum values
>>>  for enumeration types and identiyref bases for identityref
>>> types.  Here
>>>  is an example:
>>>
>>>  module: yang-catalog
>>>  +--rw catalog
>>>     +--rw modules
>>>     |  +--rw module* [name revision organization]
>>>     | +--rw name yang:yang-identifier
>>>     | +--rw revision union
>>>     | +--rw organization string
>>>     | +--rw ietf
>>>     | |  +--rw ietf-wg?   string
>>>     | +--rw namespace    inet:uri
>>>     | +--rw schema?  inet:uri
>>>     | +--rw generated-from?  enumeration [mib, code,
>>>  not-applicable, native]
>>>     | +--rw maturity-level?  enumeration [ratified,
>>>  adopted, initial, not-applicable]
>>>  ...
>>>     +--rw protocols
>>>     |  +--rw protocol* [name]
>>>     | +--rw name
>>>  identityref -> protocol
>>>  ...
>>>
>>>  My questions are:
>>>
>>>  1. Is this useful?
>>>
>>>  2. If so, can this be added to pyang (happy to submit a PR) and
>>>  draft-ietf-netmod-yang-tree-diagrams?
>>>
>>>  3. What changes to the output format would you recommend?
>>>
>>>  Thanks.
>>>
>>>  Joe
>>>
>>>  ___
>>>  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
> 

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

Re: [netmod] syslog-model-17 shepherd writeup issues -references

[Kent Watsen]

I meant to say something about the .1 vs .2 difference.  My comment
assumes that it's supposed to be .1, but we of course should use
whatever is correct.

I also don't know much about that standards body.

K.



- Original Message -
From: "Kent Watsen" 
Sent: Wednesday, September 13, 2017 6:08 PM

> Hi Tom,
>
> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
> to also list Std-1003.1-2008 as a draft-level reference.

and I am unfamiliar with that standards body so am looking for a little
more.

Is STD- always Posix or do we need to say Posix 1003 or Posix
Std-1003 or is Std-1003 completely unrelated to Posix 1003?

Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
.1 or .2 significant?  You want Std-1003.1; the description contains
Posix 1003.2; the normative Reference is to Std-1003.1-2008.

You pointed out that the Normative Reference is not used; well if we can
sort out what the standard is and get the right label in Normative
References then we can - must - include this in Section 4.1 which will
resolve that comment of yours.

The discussions last July had Clyde saying he wants Posix 1003.2 so if
Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
you are asking for a semantic change against Clyde's wishes.

I hope my confusion is sufficiently clear, at least to Clyde!

Tom Petch

>
> I was going to point out the typo "the the" as well, but figured
> that the RFC Editor would get it.
>
> K. // shepherd
>
>
> --
>
> Kent
>
> You flag Std-1003.1-2008 as listed as a normative reference but not
used
> anywhere in the document.  In the Descriptions, but not in the s.4.1
> references, I see
>
> This leaf describes a Posix 1003.2 regular expression ...
>
> twice, which may, or may not, relate to this issue.
>
> Back in July, clyde said
> "I will insert a normative reference to POSIX 1003.2 in the next
> revision of the draft."
>
> In a similar vein, RFC6991 appears in a reference statement but
nowhere
> else.
>
> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
> should not be.
>
> And in a slightly different vein,
>
>registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>
> looks odd for plain text and for the repetition of 'the'..
>
> Tom Petch
>
> - Original Message -
> From: "Kent Watsen" 
> To: 
> Cc: 
> Sent: Tuesday, September 12, 2017 10:50 PM
> Subject: [netmod] syslog-model-17 shepherd writeup issues
>
>
> > Clyde, all,
> >
> > In reviewing the draft for Shepherd writeup, I found the following
> issues that I think need to be addressed before the document can be
sent
> to Benoit for AD review:
> >
> >
> > 1. Idnits found the following:
> >
> >   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
> (--).
> >
> > ** There are 2 instances of too long lines in the document, the
> longest one
> >  being 3 characters in excess of 72.
> >
> > ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC
6991)
> >
> > ** Downref: Normative reference to an Historic RFC: RFC 6587
> >
> > == Missing Reference: 'RFC5425' is mentioned on line 359, but
not
> defined
> >  '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'
> >
> >  == Unused Reference: 'RFC7895' is defined on line 1406, but no
> explicit
> >   reference was found in the text
> >   '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen,
"YANG
> Module L...'
> >
> >  == Unused Reference: 'RFC6242' is defined on line 1435, but no
> explicit
> >   reference was found in the text
> >   '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol
over
> Secure Sh...'
> >
> >
> > 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
> "@-mm-dd" in its name
> >
> > 3.  neither `pyang` nor `yanglint` found any errors with
> ietf-syslog.yang.pyang says
> >   for vendor-syslog-types-example: statement "identity" must
have
> a "description"
> >   substatement.
> >
> > 4. testing the examples in the draft against yanglint:
> >   - for both examples: Missing element's "namespace". (/config)
> >   - just removing the "" element envelop resolves this
> error.
> >
> > 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
> SHOULD be a
> >  domain name (e.g., foo.example.com)
> >
> > 6. in the YANG module, anywhere you have an RFC listed in a
> 'description' statement,
> >  there should be a 'reference' statement for that RFC.
> >
> > 7. in the tree diagram, the leafrefs no longer indicate what they
> point at, they now all
> >  just say "leafref".  Did you do this on purpose, or are you
using
> a different tree
> >  output generator from -15?
> >
> > 8. RFC6536 is listed as a normative reference, but it probably
should
> be informative.
> >
> > 

Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04

[Ladislav Lhotka]

Phil Shafer  writes:

> +
> +The implication of the existence of templating mechanisms is that
> + is now explicitly allowed to be invalid, since the
> +templating mechanism may be supplying additional data that satisfies
> +constraints that may be satisfied by  itself.
> +

Section 8.1 in RFC 7950 identifies some constraints that "are true in
all data trees". If they are violated in , it means that the
content is not a data tree as defined by YANG.

The same section also says that  MUST always be valid. This is
probably intended to be removed, but constraints that are supposed to
hold in all data trees should IMO stay no matter what.

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] syslog-model-17 shepherd writeup issues -references

[t.petch]

- Original Message -
From: "Kent Watsen" 
Sent: Wednesday, September 13, 2017 6:08 PM

> Hi Tom,
>
> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
> to also list Std-1003.1-2008 as a draft-level reference.

and I am unfamiliar with that standards body so am looking for a little
more.

Is STD- always Posix or do we need to say Posix 1003 or Posix
Std-1003 or is Std-1003 completely unrelated to Posix 1003?

Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
.1 or .2 significant?  You want Std-1003.1; the description contains
Posix 1003.2; the normative Reference is to Std-1003.1-2008.

You pointed out that the Normative Reference is not used; well if we can
sort out what the standard is and get the right label in Normative
References then we can - must - include this in Section 4.1 which will
resolve that comment of yours.

The discussions last July had Clyde saying he wants Posix 1003.2 so if
Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
you are asking for a semantic change against Clyde's wishes.

I hope my confusion is sufficiently clear, at least to Clyde!

Tom Petch

>
> I was going to point out the typo "the the" as well, but figured
> that the RFC Editor would get it.
>
> K. // shepherd
>
>
> --
>
> Kent
>
> You flag Std-1003.1-2008 as listed as a normative reference but not
used
> anywhere in the document.  In the Descriptions, but not in the s.4.1
> references, I see
>
> This leaf describes a Posix 1003.2 regular expression ...
>
> twice, which may, or may not, relate to this issue.
>
> Back in July, clyde said
> "I will insert a normative reference to POSIX 1003.2 in the next
> revision of the draft."
>
> In a similar vein, RFC6991 appears in a reference statement but
nowhere
> else.
>
> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
> should not be.
>
> And in a slightly different vein,
>
>registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>
> looks odd for plain text and for the repetition of 'the'..
>
> Tom Petch
>
> - Original Message -
> From: "Kent Watsen" 
> To: 
> Cc: 
> Sent: Tuesday, September 12, 2017 10:50 PM
> Subject: [netmod] syslog-model-17 shepherd writeup issues
>
>
> > Clyde, all,
> >
> > In reviewing the draft for Shepherd writeup, I found the following
> issues that I think need to be addressed before the document can be
sent
> to Benoit for AD review:
> >
> >
> > 1. Idnits found the following:
> >
> >   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
> (--).
> >
> > ** There are 2 instances of too long lines in the document, the
> longest one
> >  being 3 characters in excess of 72.
> >
> > ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC
6991)
> >
> > ** Downref: Normative reference to an Historic RFC: RFC 6587
> >
> > == Missing Reference: 'RFC5425' is mentioned on line 359, but
not
> defined
> >  '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'
> >
> >  == Unused Reference: 'RFC7895' is defined on line 1406, but no
> explicit
> >   reference was found in the text
> >   '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen,
"YANG
> Module L...'
> >
> >  == Unused Reference: 'RFC6242' is defined on line 1435, but no
> explicit
> >   reference was found in the text
> >   '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol
over
> Secure Sh...'
> >
> >
> > 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
> "@-mm-dd" in its name
> >
> > 3.  neither `pyang` nor `yanglint` found any errors with
> ietf-syslog.yang.pyang says
> >   for vendor-syslog-types-example: statement "identity" must
have
> a "description"
> >   substatement.
> >
> > 4. testing the examples in the draft against yanglint:
> >   - for both examples: Missing element's "namespace". (/config)
> >   - just removing the "" element envelop resolves this
> error.
> >
> > 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
> SHOULD be a
> >  domain name (e.g., foo.example.com)
> >
> > 6. in the YANG module, anywhere you have an RFC listed in a
> 'description' statement,
> >  there should be a 'reference' statement for that RFC.
> >
> > 7. in the tree diagram, the leafrefs no longer indicate what they
> point at, they now all
> >  just say "leafref".  Did you do this on purpose, or are you
using
> a different tree
> >  output generator from -15?
> >
> > 8. RFC6536 is listed as a normative reference, but it probably
should
> be informative.
> >
> > 9. Std-1003.1-2008 is listed as a normative reference, but it is not
> used anywhere in the document.
> >
> > 10. RFC6242 is listed as an informative reference, but it is not
used
> anywhere in the document.
> >
> 

Re: [netmod] Proposal to enhance the YANG tree output

[Balazs Lengyel]

Did you consider to have a concise and a verbose tree output selected by 
an option?


regards Balazs


On 2017-09-14 17:58, Joe Clarke wrote:

On 9/14/17 11:43, Andy Bierman wrote:

Hi,


Actually I liked the early pyang output that was concise and easy to
remember.
The current format gets very cluttered and there are too many little symbols
to remember them all.

I just went with text for these changes.  Yes, it adds more verbiage to
the output, but it doesn't add any cryptic symbols; plus I think it
makes it easier to comprehend the types.

Joe



Andy


On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke > wrote:

 I've been hacking on pyang, and I changed tree.py to add the enum values
 for enumeration types and identiyref bases for identityref types.  Here
 is an example:

 module: yang-catalog
 +--rw catalog
+--rw modules
|  +--rw module* [name revision organization]
| +--rw name yang:yang-identifier
| +--rw revision union
| +--rw organization string
| +--rw ietf
| |  +--rw ietf-wg?   string
| +--rw namespaceinet:uri
| +--rw schema?  inet:uri
| +--rw generated-from?  enumeration [mib, code,
 not-applicable, native]
| +--rw maturity-level?  enumeration [ratified,
 adopted, initial, not-applicable]
 ...
+--rw protocols
|  +--rw protocol* [name]
| +--rw name
 identityref -> protocol
 ...

 My questions are:

 1. Is this useful?

 2. If so, can this be added to pyang (happy to submit a PR) and
 draft-ietf-netmod-yang-tree-diagrams?

 3. What changes to the output format would you recommend?

 Thanks.

 Joe

 ___
 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


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] Proposal to enhance the YANG tree output

[Joe Clarke]

On 9/14/17 11:43, Andy Bierman wrote:
> Hi,
> 
> 
> Actually I liked the early pyang output that was concise and easy to
> remember.
> The current format gets very cluttered and there are too many little symbols
> to remember them all.

I just went with text for these changes.  Yes, it adds more verbiage to
the output, but it doesn't add any cryptic symbols; plus I think it
makes it easier to comprehend the types.

Joe

> 
> 
> Andy
> 
> 
> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  > wrote:
> 
> I've been hacking on pyang, and I changed tree.py to add the enum values
> for enumeration types and identiyref bases for identityref types.  Here
> is an example:
> 
> module: yang-catalog
>     +--rw catalog
>        +--rw modules
>        |  +--rw module* [name revision organization]
>        |     +--rw name                     yang:yang-identifier
>        |     +--rw revision                 union
>        |     +--rw organization             string
>        |     +--rw ietf
>        |     |  +--rw ietf-wg?   string
>        |     +--rw namespace                inet:uri
>        |     +--rw schema?                  inet:uri
>        |     +--rw generated-from?          enumeration [mib, code,
> not-applicable, native]
>        |     +--rw maturity-level?          enumeration [ratified,
> adopted, initial, not-applicable]
> ...
>                                +--rw protocols
>                                |  +--rw protocol* [name]
>                                |     +--rw name
> identityref -> protocol
> ...
> 
> My questions are:
> 
> 1. Is this useful?
> 
> 2. If so, can this be added to pyang (happy to submit a PR) and
> draft-ietf-netmod-yang-tree-diagrams?
> 
> 3. What changes to the output format would you recommend?
> 
> Thanks.
> 
> Joe
> 
> ___
> 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] Proposal to enhance the YANG tree output

[Andy Bierman]

Hi,


Actually I liked the early pyang output that was concise and easy to
remember.
The current format gets very cluttered and there are too many little symbols
to remember them all.


Andy


On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:

> I've been hacking on pyang, and I changed tree.py to add the enum values
> for enumeration types and identiyref bases for identityref types.  Here
> is an example:
>
> module: yang-catalog
> +--rw catalog
>+--rw modules
>|  +--rw module* [name revision organization]
>| +--rw name yang:yang-identifier
>| +--rw revision union
>| +--rw organization string
>| +--rw ietf
>| |  +--rw ietf-wg?   string
>| +--rw namespaceinet:uri
>| +--rw schema?  inet:uri
>| +--rw generated-from?  enumeration [mib, code,
> not-applicable, native]
>| +--rw maturity-level?  enumeration [ratified,
> adopted, initial, not-applicable]
> ...
>+--rw protocols
>|  +--rw protocol* [name]
>| +--rw name
> identityref -> protocol
> ...
>
> My questions are:
>
> 1. Is this useful?
>
> 2. If so, can this be added to pyang (happy to submit a PR) and
> draft-ietf-netmod-yang-tree-diagrams?
>
> 3. What changes to the output format would you recommend?
>
> Thanks.
>
> Joe
>
> ___
> 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] Comments on NMDA-04

[Balazs Lengyel]

See below !


On 2017-09-14 16:32, Martin Bjorklund wrote:


CH 4.4.)  "Validation is performed on the contents of ."
This to me means that default data is not considered at validation

Note that RFC 7950, section 6.4.1, says:

In the accessible tree, all leafs and leaf-lists with default values
in use exist (see Sections 7.6.1 and 7.7.2).

So defaults are taken into account when intended is validated.
BALAZS: Yes the two seem to contradict each other. This can be 
understood in your way, however the current text is not clear enough. I 
would add:
Validation is performed on the contents of  (EXTENDED WITH 
DEFAULT CONFIGURATION).

which would be a backwards incompatible change. Also if validation
does not consider system configured data that would allow cases like
multiple interfaces named lo0. One from  one from system
configuration. IMHO while it is OK to violate uniqueness because of
remnant data, the above violation of uniqueness seems a bad idea.

If your system adds data to , or to , it will be
validated.


Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
should not be.

Agreed.  Note that the draft explicitly lists the constraints that can
be violated, and uniqueness of keys is not listed.
BALAZS: If that is the intent I would propose to explicitly state it. 
For me it was non-trivial.
Can a a choice statement be violated? Having to existing branches at the 
same time? It seems a semantic constraint to me. IMHO yes.
Can an if-feature be violated? If  support has just changed and we have 
some remnant config, I can very well imagine it violated.


Also here could you change
If a node in   does not meet the syntactic constraints then 
it cannot   be returned

to
If a node in   does not meet the syntactic constraints then 
it MUST NOT be returned

/martin


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] upcoming adoptions

[Acee Lindem (acee)]

Hi Rob, 

On 9/14/17, 9:37 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>Hi Kent & Lou,
>
>When do you think that it will be possible to start the adoption process
>on these drafts?
>
>I think that the first two at least would seem to be ready for
>adoption.  For the 3rd draft, there still seems to be an open question
>of what to do with the old state tree, but presumably that could be
>solved after the draft has been adopted?

This is prefect timing. We discussed this issue at some length in the YANG
Routing Design Team and the course we on is publishing a new model which
is unencumbered from the current ietf-routing model. Refer to:

https://datatracker.ietf.org/doc/draft-acee-netmod-rfc8022bis/

Thanks,
Acee 


>
>Thanks,
>Rob
>
>
>On 30/08/2017 00:46, Kent Watsen wrote:
>> Hey folks,
>>
>> As discussed at the last meeting, we are heading to revising existing
>>RFCs to align them with NMDA.  The first batch have been published as
>>individual drafts:
>>
>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>
>> Please take a look (comments welcome!) and stay tuned for the related
>>adoption calls.
>>
>> Thanks,
>> Kent (and Lou)
>>
>>
>> ___
>> 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

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

[netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]

[Balazs Lengyel]

  
  
See below!

On 2017-09-14 16:32, Martin Bjorklund
  wrote:


  Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel  wrote:

  
Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the  or 
datastore already not just to : e.g.

UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to , validation will
fail indicating that the server is bound to a non-existent
address. How to handle this?

UC2: I have a set of capabilities set by the system
e.g. supported-reporting-intervals. I need to configure a job that
MUST use one of these intervals. If the supported-reporting-intervals
are only added to  I can not validate the
selected-interval in my configured job.

My proposal is to allow the system to add data to running as
well. Actually I think that is a more relevant case then adding
configuration just to .

  
  I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to .  However, there is nothing in
the new or old architectures that prohibits this.

BALAZS: I strongly disagree.  I know others are also adding stuff to
running as well. 
IMHO the above use cases are real and used and actually important
for us. 
I would like to see them included in some way.

regards Balazs
-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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

[netmod] Proposal to enhance the YANG tree output

[Joe Clarke]

I've been hacking on pyang, and I changed tree.py to add the enum values
for enumeration types and identiyref bases for identityref types.  Here
is an example:

module: yang-catalog
+--rw catalog
   +--rw modules
   |  +--rw module* [name revision organization]
   | +--rw name yang:yang-identifier
   | +--rw revision union
   | +--rw organization string
   | +--rw ietf
   | |  +--rw ietf-wg?   string
   | +--rw namespaceinet:uri
   | +--rw schema?  inet:uri
   | +--rw generated-from?  enumeration [mib, code,
not-applicable, native]
   | +--rw maturity-level?  enumeration [ratified,
adopted, initial, not-applicable]
...
   +--rw protocols
   |  +--rw protocol* [name]
   | +--rw name
identityref -> protocol
...

My questions are:

1. Is this useful?

2. If so, can this be added to pyang (happy to submit a PR) and
draft-ietf-netmod-yang-tree-diagrams?

3. What changes to the output format would you recommend?

Thanks.

Joe

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

Re: [netmod] upcoming adoptions

[Kent Watsen]

> So rfc8022bis-02 publishes the v2 module, and the the deprecated version 
> of the v1 module as an appendix?

Lou and I were just discussing if appendix can be normative or not.  I always
thought no, but I haven't checked.  This is a grey area, in that understanding
that the old module is deprecating is not needed in order to understand the
new module, and we really just to ensure extraction tools work...


> I see "kind of ugly" as a feature in the this case, someone looking at 
> the updated v1 module isn't going to be able to miss that whatever they 
> are looking at is deprecated. ;-)

Funny, and true


K.


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

Re: [netmod] upcoming adoptions

[Robert Wilton]

On 14/09/2017 15:52, Kent Watsen wrote:

rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy module, 
but does it actually say it?  (I can't find it)

The draft does say that it obsoletes 8022, but I'm unsure if that's going to 
have a meaningful impact in the wild.  I think Juergen said they had this issue 
with MIB2 and only after a couple years of misuse did they republish the legacy 
MIBs with deprecated status.
So rfc8022bis-02 publishes the v2 module, and the the deprecated version 
of the v1 module as an appendix?




I'm okay with this change being made after adoption, so long as there's general 
agreement to do it.  Are the authors okay with it, or are there any better 
suggestions?

PS: Sadly, the 'module' statement does not have 'status' as a substatement [I just added 
this omission to the yang-next tracker].  I think the only way to "deprecate a 
module" is to instead deprecate the all the nodes/rpcs/notifications in the module.  
Kind of ugly, but it's for a deprecated module, so who care, right?  ;)
I see "kind of ugly" as a feature in the this case, someone looking at 
the updated v1 module isn't going to be able to miss that whatever they 
are looking at is deprecated. ;-)


Rob




Kent


--

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:

Hi Kent & Lou,

When do you think that it will be possible to start the adoption process
on these drafts?

I think that the first two at least would seem to be ready for
adoption.  For the 3rd draft, there still seems to be an open question
of what to do with the old state tree, but presumably that could be
solved after the draft has been adopted?

I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
clarifies the intent is to replace the current modules, and presumably
obsolete 8022.  And now that this intended direction is clear in the
draft we could poll it.

I think this still doesn't address if we need to indicate that the
rfc8022 defined modules are deprecated by some other mechanisms than
just replacing the RFC, e.g., by updating the old modules with all nodes
marked as deprecated.  I think you're right that this could be done post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou


Thanks,
Rob


On 30/08/2017 00:46, Kent Watsen wrote:

Hey folks,

As discussed at the last meeting, we are heading to revising existing RFCs to 
align them with NMDA.  The first batch have been published as individual drafts:

1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

Please take a look (comments welcome!) and stay tuned for the related adoption 
calls.

Thanks,
Kent (and Lou)


___
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] upcoming adoptions

[Kent Watsen]

rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy module, 
but does it actually say it?  (I can't find it)

The draft does say that it obsoletes 8022, but I'm unsure if that's going to 
have a meaningful impact in the wild.  I think Juergen said they had this issue 
with MIB2 and only after a couple years of misuse did they republish the legacy 
MIBs with deprecated status.

I'm okay with this change being made after adoption, so long as there's general 
agreement to do it.  Are the authors okay with it, or are there any better 
suggestions?

PS: Sadly, the 'module' statement does not have 'status' as a substatement [I 
just added this omission to the yang-next tracker].  I think the only way to 
"deprecate a module" is to instead deprecate the all the 
nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a 
deprecated module, so who care, right?  ;)

Kent


--

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:
> Hi Kent & Lou,
>
> When do you think that it will be possible to start the adoption process 
> on these drafts?
>
> I think that the first two at least would seem to be ready for 
> adoption.  For the 3rd draft, there still seems to be an open question 
> of what to do with the old state tree, but presumably that could be 
> solved after the draft has been adopted?
I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
clarifies the intent is to replace the current modules, and presumably
obsolete 8022.  And now that this intended direction is clear in the
draft we could poll it.

I think this still doesn't address if we need to indicate that the
rfc8022 defined modules are deprecated by some other mechanisms than
just replacing the RFC, e.g., by updating the old modules with all nodes
marked as deprecated.  I think you're right that this could be done post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou

>
> Thanks,
> Rob
>
>
> On 30/08/2017 00:46, Kent Watsen wrote:
>> Hey folks,
>>
>> As discussed at the last meeting, we are heading to revising existing RFCs 
>> to align them with NMDA.  The first batch have been published as individual 
>> drafts:
>>
>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>
>> Please take a look (comments welcome!) and stay tuned for the related 
>> adoption calls.
>>
>> Thanks,
>> Kent (and Lou)
>>
>>
>> ___
>> 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] Comments on NMDA-04

[Martin Bjorklund]

Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel  wrote:
> Hello,
> 
> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
> 
> General) The system often adds data to the  or 
> datastore already not just to : e.g.
> 
> UC1: I have a server configured in running. I need to bind it to an
> ip-address. The ip-address might be the local loopback address,
> however if that is only added to the , validation will
> fail indicating that the server is bound to a non-existent
> address. How to handle this?
> 
> UC2: I have a set of capabilities set by the system
> e.g. supported-reporting-intervals. I need to configure a job that
> MUST use one of these intervals. If the supported-reporting-intervals
> are only added to  I can not validate the
> selected-interval in my configured job.
> 
> My proposal is to allow the system to add data to running as
> well. Actually I think that is a more relevant case then adding
> configuration just to .

I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to .  However, there is nothing in
the new or old architectures that prohibits this.

Also note that the draft says:

  Currently there are no standard mechanisms defined that affect
   so that it would have different contents than ,
  but this architecture allows for such mechanisms to be defined.

which means that you can also define your own mechanisms for adding
things to , before validation.

> CH 4.4.)  "Validation is performed on the contents of ."
> This to me means that default data is not considered at validation

Note that RFC 7950, section 6.4.1, says:

   In the accessible tree, all leafs and leaf-lists with default values
   in use exist (see Sections 7.6.1 and 7.7.2).

So defaults are taken into account when intended is validated.

> which would be a backwards incompatible change. Also if validation
> does not consider system configured data that would allow cases like
> multiple interfaces named lo0. One from  one from system
> configuration. IMHO while it is OK to violate uniqueness because of
> remnant data, the above violation of uniqueness seems a bad idea.

If your system adds data to , or to , it will be
validated.

> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
> should not be.

Agreed.  Note that the draft explicitly lists the constraints that can
be violated, and uniqueness of keys is not listed.

> Ch 5.1) IMHO actions and rpcs should be allowed to include other
> datastores in their XPath evaluation. My suggestion is that they need
> to specify it somehow. (Yang extension?)

This is something that the WG has discussed in the past as well, but
so far no concrete proposal has been made.  I think such extensions
can be done in a separate document in the future, or maybe if we do a
new version of YANG.

But note that for rpc and action, this section only talks about
XPath in input/output parameters.

> UC1) I want to define a convinience action that allows me to do a big
> modification in  in one step. I wan't to validate what it is
> doing based on the current contents of running. E.g. configure the OAM
> settings for the system including SNMP/Netconf/FTP in one step, but
> for each step I need to check that I am putting the relevant server on
> an existing interface.

I think this is covered.  If you have an rpc that modifies ,
the result will be valdiated according to the must expression in the
data models.

> If specifying the datastore is an overkill, I would still rather chose
> runing as the accessible datastore. XPath is mostly use for
> checks. Checks are done against configuration.
> 
> Appendix B)
> 
> "4. How applied : automatic" This is definitely not enough to
> understand what happens even as an example. I propose:
> Changes are automatically propagated to 

I agree this is better.

> C.1)  During the example the
> 2001:db8::10
>  32
> is changed to 64 its. Is that intentional? It is not mentioned in the
> text.

No this is a bug, will be fixed!


/martin

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

Re: [netmod] syslog-model-17 shepherd writeup issues -references

[Kent Watsen]

Good suggestion, Rob.  This might also have come up in the SecDir review.

Separately, Juergen had a suggestion to add an "observation" (since a "warning" 
seems too strong) that use of POSIX regex precludes UTF8 support.  Makes sense? 
 FWIW, the module is fine as is, since the regex is under a feature statement, 
which allows a future effort add another regex-feature if ever needed.

Clyde, since these are not technical changes, and assuming that there is no 
objection, you can make these two tweaks as well.  Otherwise, I can add notes 
about these in the shepherd writeup.

Kent

--

Hi Kent, Clyde,

Does the "pattern-match" leaf need to be explicitly pulled out in 
security considerations?  Allowing a client to provide an arbitrary 
regex could potentially cause a regex engine to overflow its stack and 
crash.

An example of an regex overflow is described here: 
http://www.regular-expressions.info/catastrophic.html

Thanks,
Rob


On 13/09/2017 18:08, Kent Watsen wrote:
> Hi Tom,
>
> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
> to also list Std-1003.1-2008 as a draft-level reference.
>
> I was going to point out the typo "the the" as well, but figured
> that the RFC Editor would get it.
>
> K. // shepherd
>
>
> --
>
> Kent
>
> You flag Std-1003.1-2008 as listed as a normative reference but not used
> anywhere in the document.  In the Descriptions, but not in the s.4.1
> references, I see
>
> This leaf describes a Posix 1003.2 regular expression ...
>
> twice, which may, or may not, relate to this issue.
>
> Back in July, clyde said
> "I will insert a normative reference to POSIX 1003.2 in the next
> revision of the draft."
>
> In a similar vein, RFC6991 appears in a reference statement but nowhere
> else.
>
> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
> should not be.
>
> And in a slightly different vein,
>
> registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>
> looks odd for plain text and for the repetition of 'the'..
>
> Tom Petch
>
> - Original Message -
> From: "Kent Watsen" 
> To: 
> Cc: 
> Sent: Tuesday, September 12, 2017 10:50 PM
> Subject: [netmod] syslog-model-17 shepherd writeup issues
>
>
>> Clyde, all,
>>
>> In reviewing the draft for Shepherd writeup, I found the following
> issues that I think need to be addressed before the document can be sent
> to Benoit for AD review:
>>
>> 1. Idnits found the following:
>>
>>Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
> (--).
>>  ** There are 2 instances of too long lines in the document, the
> longest one
>>   being 3 characters in excess of 72.
>>
>>  ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991)
>>
>>  ** Downref: Normative reference to an Historic RFC: RFC 6587
>>
>>  == Missing Reference: 'RFC5425' is mentioned on line 359, but not
> defined
>>   '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'
>>
>>   == Unused Reference: 'RFC7895' is defined on line 1406, but no
> explicit
>>reference was found in the text
>>'[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG
> Module L...'
>>   == Unused Reference: 'RFC6242' is defined on line 1435, but no
> explicit
>>reference was found in the text
>>'[RFC6242]  Wasserman, M., "Using the NETCONF Protocol over
> Secure Sh...'
>>
>> 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
> "@-mm-dd" in its name
>> 3.  neither `pyang` nor `yanglint` found any errors with
> ietf-syslog.yang.pyang says
>>for vendor-syslog-types-example: statement "identity" must have
> a "description"
>>substatement.
>>
>> 4. testing the examples in the draft against yanglint:
>>- for both examples: Missing element's "namespace". (/config)
>>- just removing the "" element envelop resolves this
> error.
>> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
> SHOULD be a
>>   domain name (e.g., foo.example.com)
>>
>> 6. in the YANG module, anywhere you have an RFC listed in a
> 'description' statement,
>>   there should be a 'reference' statement for that RFC.
>>
>> 7. in the tree diagram, the leafrefs no longer indicate what they
> point at, they now all
>>   just say "leafref".  Did you do this on purpose, or are you using
> a different tree
>>   output generator from -15?
>>
>> 8. RFC6536 is listed as a normative reference, but it probably should
> be informative.
>> 9. Std-1003.1-2008 is listed as a normative reference, but it is not
> used anywhere in the document.
>> 10. RFC6242 is listed as an informative reference, but it is not used
> anywhere in the document.
>> 11. the document fails to declare its normative references to
> ietf-keystore and ietf-tls-client-server.
>>  

[netmod] Comments on NMDA-04

[Balazs Lengyel]

Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the  or  
datastore already not just to : e.g.


UC1: I have a server configured in running. I need to bind it to an 
ip-address. The ip-address might be the local loopback address, however 
if that is only added to the , validation will fail 
indicating that the server is bound to a non-existent address. How to 
handle this?


UC2: I have a set of capabilities set by the system e.g. 
supported-reporting-intervals. I need to configure a job that MUST use 
one of these intervals. If the supported-reporting-intervals are only 
added to  I can not validate the selected-interval in my 
configured job.


My proposal is to allow the system to add data to running as well. 
Actually I think that is a more relevant case then adding configuration 
just to .


CH 4.4.)  "Validation is performed on  the contents of ." This 
to me means that default data is not considered at validation which 
would be a backwards incompatible change. Also if validation does not 
consider system configured data that would allow cases like multiple 
interfaces named lo0. One from  one from system configuration. 
IMHO while it is OK to violate uniqueness because of remnant data, the 
above violation of uniqueness seems a bad idea.


Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it 
should not be.


Ch 5.1) IMHO actions and rpcs should be allowed to include other 
datastores in their XPath evaluation. My suggestion is that they need to 
specify it somehow. (Yang extension?)


UC1) I want to define a convinience action that allows me to do a big 
modification in  in one step. I wan't to validate what it is 
doing based on the current contents of running. E.g. configure the OAM 
settings for the system including SNMP/Netconf/FTP in one step, but for 
each step I need to check that I am putting the relevant server on an 
existing interface.
If specifying the datastore is an overkill, I would still rather chose 
runing as the accessible datastore. XPath is mostly use for checks. 
Checks are done against configuration.


Appendix B)

"4. How applied : automatic"This is definitely not enough to 
understand what happens even as an example. I propose:

Changes are automatically propagated to 

C.1)  During the example the
2001:db8::10
 32
is changed to 64 its. Is that intentional? It is not mentioned in the text.

regards Balazs


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] upcoming adoptions

[Robert Wilton]

Hi Kent & Lou,

When do you think that it will be possible to start the adoption process 
on these drafts?


I think that the first two at least would seem to be ready for 
adoption.  For the 3rd draft, there still seems to be an open question 
of what to do with the old state tree, but presumably that could be 
solved after the draft has been adopted?


Thanks,
Rob


On 30/08/2017 00:46, Kent Watsen wrote:

Hey folks,

As discussed at the last meeting, we are heading to revising existing RFCs to 
align them with NMDA.  The first batch have been published as individual drafts:

1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

Please take a look (comments welcome!) and stay tuned for the related adoption 
calls.

Thanks,
Kent (and Lou)


___
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] syslog-model-17 shepherd writeup issues -references

[Robert Wilton]

Hi Kent, Clyde,

Does the "pattern-match" leaf need to be explicitly pulled out in 
security considerations?  Allowing a client to provide an arbitrary 
regex could potentially cause a regex engine to overflow its stack and 
crash.


An example of an regex overflow is described here: 
http://www.regular-expressions.info/catastrophic.html


Thanks,
Rob


On 13/09/2017 18:08, Kent Watsen wrote:

Hi Tom,

Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
to have a 'reference' statement to Std-1003.1-2008, and for S4.1
to also list Std-1003.1-2008 as a draft-level reference.

I was going to point out the typo "the the" as well, but figured
that the RFC Editor would get it.

K. // shepherd


--

Kent

You flag Std-1003.1-2008 as listed as a normative reference but not used
anywhere in the document.  In the Descriptions, but not in the s.4.1
references, I see

This leaf describes a Posix 1003.2 regular expression ...

twice, which may, or may not, relate to this issue.

Back in July, clyde said
"I will insert a normative reference to POSIX 1003.2 in the next
revision of the draft."

In a similar vein, RFC6991 appears in a reference statement but nowhere
else.

As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
should not be.

And in a slightly different vein,

registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the

looks odd for plain text and for the repetition of 'the'..

Tom Petch

- Original Message -
From: "Kent Watsen" 
To: 
Cc: 
Sent: Tuesday, September 12, 2017 10:50 PM
Subject: [netmod] syslog-model-17 shepherd writeup issues



Clyde, all,

In reviewing the draft for Shepherd writeup, I found the following

issues that I think need to be addressed before the document can be sent
to Benoit for AD review:


1. Idnits found the following:

   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment

(--).

 ** There are 2 instances of too long lines in the document, the

longest one

  being 3 characters in excess of 72.

 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991)

 ** Downref: Normative reference to an Historic RFC: RFC 6587

 == Missing Reference: 'RFC5425' is mentioned on line 359, but not

defined

  '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'

  == Unused Reference: 'RFC7895' is defined on line 1406, but no

explicit

   reference was found in the text
   '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG

Module L...'

  == Unused Reference: 'RFC6242' is defined on line 1435, but no

explicit

   reference was found in the text
   '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol over

Secure Sh...'


2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing

"@-mm-dd" in its name

3.  neither `pyang` nor `yanglint` found any errors with

ietf-syslog.yang.pyang says

   for vendor-syslog-types-example: statement "identity" must have

a "description"

   substatement.

4. testing the examples in the draft against yanglint:
   - for both examples: Missing element's "namespace". (/config)
   - just removing the "" element envelop resolves this

error.

5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this

SHOULD be a

  domain name (e.g., foo.example.com)

6. in the YANG module, anywhere you have an RFC listed in a

'description' statement,

  there should be a 'reference' statement for that RFC.

7. in the tree diagram, the leafrefs no longer indicate what they

point at, they now all

  just say "leafref".  Did you do this on purpose, or are you using

a different tree

  output generator from -15?

8. RFC6536 is listed as a normative reference, but it probably should

be informative.

9. Std-1003.1-2008 is listed as a normative reference, but it is not

used anywhere in the document.

10. RFC6242 is listed as an informative reference, but it is not used

anywhere in the document.

11. the document fails to declare its normative references to

ietf-keystore and ietf-tls-client-server.

 Note: you manually entered the "[RFC ], and [RFC ]"

references…

12.  The IANA considerations section seems asymmetric.  Either put

both registry insertions into

 subsections, or keep them both at the top-level…

13. reviewing the final document against my original YD review, I have

the following responses.  Let's be sure to close out these items as
well.  Ref: https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11
s-0gOfCe8NSE

1. ok
2. better
3. should be: s/the message/these messages/  [RFC Editor might've

caught this]

4. better
5. still feel the same way, but no biggee
6. better, but from 8174, you should add the part "when, and only

when, they appear in all capitals, as shown here."

7. fixed
8. fixed
9. you did what I asked, but the result still isn't