[netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18

[Juergen Schoenwaelder]

Hi,

I think it was common practice to write

  reference "RFC 6991: Common YANG Data Types";

instead of just

  reference "RFC 6991";

that is to include the RFC title (this can be especially useful with
longer lists of references and less commonly known RFC numbers). It
seems that draft-ietf-netmod-rfc6087bis-18 kind of suggests to only
use the RFC number (section 3.2 and section 4.7).

/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] AD review of draft-ietf-netmod-syslog-model-20

[Benoit Claise]

On 2/22/2018 11:49 AM, t.petch wrote:

- Original Message -
From: "Kent Watsen" 
To: "t.petch" ; "NETMOD Working Group"

Sent: Tuesday, February 20, 2018 5:06 PM

Kent

You illustrate beautifully the problem I would like a solution to.

The current thinking AFAICT is that tree-diagrams
should be an Informative Reference.

Therefore, the RFC Editor will not hold publication until an RFC

number

is assigned.

Therefore, a note asking the I-D reference to be updated to reflect

the

assigned RFC number is null - the RFC can be published with the
reference as an i-d and not as an RFC which is what I expect the RFC
Editor to do.

QED


Except I know that this draft will be stuck in MISREF state and

tree-diagrams

will in fact be assigned an RFC number by the time this draft is

published.

Kent

Corner case:-)
Note that, for this corner case, the IESG agreed for the tree-diagrams 
to go through expedited processing.
Even if this is an informative reference, it's nicer to get an RFC as a 
reference.


Regards, Benoit



You cannot know in general that drafts that appear as Informational
References and which are referenced from within a YANG module will be
published before the referencing I-D will be and so will have a RFC
number which can be inserted by the RFC Editor.




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

[netmod] Secdir telechat review of draft-ietf-netmod-rfc6087bis-18

[Stephen Farrell]

Reviewer: Stephen Farrell
Review result: Ready


I reviewed the diff between -18 and RFC6087. [1]

   [1] 
https://www.ietf.org/rfcdiff?url1=rfc6087=draft-ietf-netmod-rfc6087bis-18

I assume the security ADs were involved already in discussion about
the new security considerations template in 3.7.1 and the text there
does seem fine to me, so I won't even nit-pick about it:-)

I do have some other nits to note though.

- There are a number of URLs given for access to updated materials
that use http schemed URLs and that do not use https schemed URLs.
There was a recent IESG statement to the effect that those'd be better
as https URLs. The first such example is in 3.1. In fact that URL is
re-directed (for me) to https. I think a general pass to fix such URLs
to use https wherever possible would be easy and better practice.

- Some of the namespaces use http schemed URLs, for example in
section 4.2. I don't know if people are expected to de-reference such
URLs, but if they are then it'd be good to say if https is better to use
or not. (I'd argue it is.) If those URLs are not expected to be 
de-referenced, then saying that would be good. (Not that it'd stop 
people de-referencing 'em so the change is better in any case;-)

Cheers,
S.

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

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Robert Wilton]

Hi Lou,

I think that this solution is inferior to the model presented in pre-09.

I would prefer that we publish pre09 instead, potentially including the 
-08 model in the appendix if that helps progress the document in a more 
expedient fashion.


Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:

Hi,

(I have a bunch of different roles WRT this work.  This mail is being 
sent as an individual - as chair, I fully support the previous chair 
statements on this draft.)


Chris and I have come up with a proposal on how to provide full NMDA 
as part the existing schema-mount module.  Our motivation was to 
enable full NMDA support with *minimal* change to the model and 
disruption to the LC'ed work.  The key NMDA limitation, with -08, that 
we are aiming to address is the ability to support different mounted 
schema in different datastores for non-inline mount points. (See more 
detailed description below if interested full nuances of limitations 
of -08)


What we came up with was  to simply add a (leaf)list to identify in 
which datastores a
schema-mount schema is valid/present. This is somewhat similar to 
YL-bis schema/module-set. Specifically we're proposing (see below for 
full tree below):


   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted 
schema in different DSes, working with both NMDA and non-NMDA 
implementations, supporting all of the extensively discussed features 
of schema mount (including recursive mounts), and having minor/scoped 
impact on all dependent work.  The main downside is that it isn't the 
most optimal/compact solution possible if we were to base this work on 
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
perspectives, but it is what was agreed to as sufficient by those who 
contribute to the WG discussion.


In short, we see this as a solution to  addresses the raised last call 
issue with the minimal impact on -08 and dependent work -- which is 
what is appropriate given where we are in the process.


So our/my question really is:

    Is this a solution that you/all can live with?

Note: optimization, design preference and perfect alignment with use 
or YL-bis are not part of our question as we both don't think that is 
the right question given where we are in the WG process.


Lou (with ideas developed with Chris, and chair hat off)

==
Details -- for those who want
==
As background, my understanding/view is that the -08 version of the 
both NMDA and non-NMDA supporting implementations, but there are 
limitations in its NMDA applicability. Used with Yang Library, 
[rfc7895], only non-NMDA implementations can be supported.  When used 
with the revised Yang Library defined in 
[I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be 
supported with certain limitations. Specifically, this document 
requires use of the now deprecated module-list grouping, and the same 
schema represented in schema list of the Schema Mount module MUST be 
used in all datastores.  Inline type mount points, which don't use the 
schema list,  can support different schema in different data stores 
not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of 
YANG library under the inline mount point.


    module: ietf-yang-schema-mount
    +--ro schema-mounts
   +--ro namespace* [prefix]
   |  +--ro prefix    yang:yang-identifier
   |  +--ro uri?  inet:uri
   +--ro mount-point* [module name]
   |  +--ro module    yang:yang-identifier
   |  +--ro name  yang:yang-identifier
   |  +--ro config?   boolean
   |  +--ro (schema-ref)?
   | +--:(inline)
   | |  +--ro inline?   empty
   | +--:(use-schema)
   |    +--ro use-schema* [name]
   |   +--ro name
   |   |   -> /schema-mounts/schema/name
   |   +--ro parent-reference*   yang:xpath1.0
   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}
      +--ro module* [name revision]
  |  +--ro name    yang:yang-identifier
  |  +--ro revision    union
  |  +--ro schema? inet:uri
  |  +--ro namespace   inet:uri
  |  +--ro feature*    yang:yang-identifier
  |  +--ro deviation* [name revision]
  |  |  +--ro name    yang:yang-identifier
  |  |  +--ro revision    union
  |  +--ro conformance-type    enumeration
  |  +--ro submodule* [name revision]
  | +--ro name    yang:yang-identifier
  | +--ro revision    union
  | +--ro schema? inet:uri
 

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[t.petch]

- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, February 21, 2018 9:21 PM

> Kent, Tom, Yaron, and Ron,
>
> A new version of the draft-ietf-netmod-syslog-model has been published
that addresses your concerns.

Optimist:-)

And we can always have fresh concerns:-(

I note that this I-D imports interface-ref  from RFC7223 while
draft-ietf-netmod-rfc7223bis
is in the RFC Edittor's queue.  I do not think that there is any reason
not to use the latter.

Tom Petch


>
> Thanks,
>
> Clyde
>
> On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"
 wrote:
>
>
>
>
> > Kent
> >
> > You illustrate beautifully the problem I would like a solution
to.
> >
> > The current thinking AFAICT is that tree-diagrams
> > should be an Informative Reference.
> >
> > Therefore, the RFC Editor will not hold publication until an RFC
number
> > is assigned.
> >
> > Therefore, a note asking the I-D reference to be updated to
reflect the
> > assigned RFC number is null - the RFC can be published with the
> > reference as an i-d and not as an RFC which is what I expect the
RFC
> > Editor to do.
> >
> > QED
>
>
> Except I know that this draft will be stuck in MISREF state and
tree-diagrams
> will in fact be assigned an RFC number by the time this draft is
published.
>
> K.
>
>
> > Note that this is not the case of a Normative i-d reference
being buried
> > in the YANG module and not being.noticed by the RFC Editor; that
problem
> > I am content with.
> >
> >
> >Tom Petch
>
>
>
>
>
>
>
>
> >
> > Please also address these issues when posting -21 to address
Benoit's
> issues.  Please post -21 ASAP as Benoit has already placed this
draft on
> the IESG telechat in a couple weeks.
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>  on behalf
of
> bcla...@cisco.com> wrote:
> >
> > Dear all,
> >
> > - the draft is NMDA compliant, right? It should be mentioned.
> > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> >
> >The YANG model in this document conforms to the Network
Management
> >
> >Datastore Architecture defined in
> I-D.ietf-netmod-revised-datastores.
> >
> >
> > - As mentioned in the writeup,
[I-D.ietf-netmod-yang-tree-diagrams]
> should be an informative reference, not normative.
> >
> > - Editorial:
> > OLD:
> > This draft addresses the common leafs
> > NEW:
> > This document addresses the common leafs
> >
> > Please publish a new version asap.
> > In the mean time, I'm sending this draft to IETF LC.
> >
> > Regards, Benoit
> >
> >
> >
>
>
> --
--
> 
>
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> >
>
>
>
> ___
> 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] AD review of draft-ietf-netmod-syslog-model-20

[t.petch]

- Original Message -
From: "Kent Watsen" 
To: "t.petch" ; "NETMOD Working Group"

Sent: Tuesday, February 20, 2018 5:06 PM
>
> > Kent
> >
> > You illustrate beautifully the problem I would like a solution to.
> >
> > The current thinking AFAICT is that tree-diagrams
> > should be an Informative Reference.
> >
> > Therefore, the RFC Editor will not hold publication until an RFC
number
> > is assigned.
> >
> > Therefore, a note asking the I-D reference to be updated to reflect
the
> > assigned RFC number is null - the RFC can be published with the
> > reference as an i-d and not as an RFC which is what I expect the RFC
> > Editor to do.
> >
> > QED
>
>
> Except I know that this draft will be stuck in MISREF state and
tree-diagrams
> will in fact be assigned an RFC number by the time this draft is
published.

Kent

Corner case:-)

You cannot know in general that drafts that appear as Informational
References and which are referenced from within a YANG module will be
published before the referencing I-D will be and so will have a RFC
number which can be inserted by the RFC Editor.

Tom Petch

> K.
>
>
> > Note that this is not the case of a Normative i-d reference being
buried
> > in the YANG module and not being.noticed by the RFC Editor; that
problem
> > I am content with.
> >
> >
> >Tom Petch
>
>
>
>
>
>
>
>
> >
> > Please also address these issues when posting -21 to address
Benoit's
> issues.  Please post -21 ASAP as Benoit has already placed this draft
on
> the IESG telechat in a couple weeks.
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>  on behalf of
> bcla...@cisco.com> wrote:
> >
> > Dear all,
> >
> > - the draft is NMDA compliant, right? It should be mentioned.
> > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> >
> >The YANG model in this document conforms to the Network
Management
> >
> >Datastore Architecture defined in
> I-D.ietf-netmod-revised-datastores.
> >
> >
> > - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
> should be an informative reference, not normative.
> >
> > - Editorial:
> > OLD:
> > This draft addresses the common leafs
> > NEW:
> > This document addresses the common leafs
> >
> > Please publish a new version asap.
> > In the mean time, I'm sending this draft to IETF LC.
> >
> > Regards, Benoit
> >
> >
> >
>
>
> --
--
> 
>
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> >
>
>
>
>

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

[netmod] Proposal for minimalist full NMDA support in schema mount

[Lou Berger]

Hi,

(I have a bunch of different roles WRT this work.  This mail is being 
sent as an individual - as chair, I fully support the previous chair 
statements on this draft.)


Chris and I have come up with a proposal on how to provide full NMDA as 
part the existing schema-mount module.  Our motivation was to enable 
full NMDA support with *minimal* change to the model and disruption to 
the LC'ed work.  The key NMDA limitation, with -08, that we are aiming 
to address is the ability to support different mounted schema in 
different datastores for non-inline mount points. (See more detailed 
description below if interested full nuances of limitations of -08)


What we came up with was  to simply add a (leaf)list to identify in 
which datastores a
schema-mount schema is valid/present. This is somewhat similar to YL-bis 
schema/module-set. Specifically we're proposing (see below for full tree 
below):


   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted schema 
in different DSes, working with both NMDA and non-NMDA implementations, 
supporting all of the extensively discussed features of schema mount 
(including recursive mounts), and having minor/scoped impact on all 
dependent work.  The main downside is that it isn't the most 
optimal/compact solution possible if we were to base this work on 
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
perspectives, but it is what was agreed to as sufficient by those who 
contribute to the WG discussion.


In short, we see this as a solution to  addresses the raised last call 
issue with the minimal impact on -08 and dependent work -- which is what 
is appropriate given where we are in the process.


So our/my question really is:

    Is this a solution that you/all can live with?

Note: optimization, design preference and perfect alignment with use or 
YL-bis are not part of our question as we both don't think that is the 
right question given where we are in the WG process.


Lou (with ideas developed with Chris, and chair hat off)

==
Details -- for those who want
==
As background, my understanding/view is that the -08 version of the both 
NMDA and non-NMDA supporting implementations, but there are limitations 
in its NMDA applicability. Used with Yang Library, [rfc7895], only 
non-NMDA implementations can be supported.  When used with the revised 
Yang Library defined in [I.D.ietf-netconf-rfc7895bis-],  NMDA 
implementations  can be supported with certain limitations. 
Specifically, this document requires use of the now deprecated 
module-list grouping, and the same schema represented in schema list of 
the Schema Mount module MUST be used in all datastores.  Inline type 
mount points, which don't use the schema list,  can support different 
schema in different data stores not by instantiating the 
[I.D.ietf-netconf-rfc7895bis-] version of YANG library under the inline 
mount point.


module: ietf-yang-schema-mount
+--ro schema-mounts
   +--ro namespace* [prefix]
   |  +--ro prefixyang:yang-identifier
   |  +--ro uri?  inet:uri
   +--ro mount-point* [module name]
   |  +--ro moduleyang:yang-identifier
   |  +--ro name  yang:yang-identifier
   |  +--ro config?   boolean
   |  +--ro (schema-ref)?
   | +--:(inline)
   | |  +--ro inline?   empty
   | +--:(use-schema)
   |+--ro use-schema* [name]
   |   +--ro name
   |   |   -> /schema-mounts/schema/name
   |   +--ro parent-reference*   yang:xpath1.0
   +--ro schema* [name]
  +--ro name   string
ADD  +--ro datastore*   ds:datastore-ref {revised-datastores}
  +--ro module* [name revision]
  |  +--ro nameyang:yang-identifier
  |  +--ro revisionunion
  |  +--ro schema? inet:uri
  |  +--ro namespace   inet:uri
  |  +--ro feature*yang:yang-identifier
  |  +--ro deviation* [name revision]
  |  |  +--ro nameyang:yang-identifier
  |  |  +--ro revisionunion
  |  +--ro conformance-typeenumeration
  |  +--ro submodule* [name revision]
  | +--ro nameyang:yang-identifier
  | +--ro revisionunion
  | +--ro schema? inet:uri
  +--ro mount-point* [module name]
 +--ro moduleyang:yang-identifier
 +--ro name  yang:yang-identifier
 +--ro config?   boolean
 +--ro (schema-ref)?
+--:(inline)
|  +--ro inline?