Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-05.txt

Tarek

A different and orthogonal question.  What is MPLS?

This I-D augments but has no associated conditional statement, 'when' or
if, which is unusual so
   augment "/rt:routing/mpls:mpls" {  container static-lsps {
will always add static-lsps if the YANG module is present and
  augment "/rt:routing/mpls:mpls/mpls-static:static-lsps" {
will always add extended which makes me wonder why there are separate
modules.

A similar question applies to base-yang which defines mpls as an address
family but does not use the previously defined mpls and mplstunnel
interface types.  It augments regardless, when other such modules have a
feature defined and then use if-feature to make the augments
conditional.

The mpls base augments to the routes uses the address family but not the
interface types.

So in generic IETF terms, what is mpls?  Address family, interface type,
feature, tunnel type?  And should e.g. static be separate, derived from
one of the base definitions?  Ditto extended.

Expert as the participants of the NETMOD WG are, I would not assume that
that expertise extends to MPLS, for many if not most of them (yes, I
know, there are exceptions) so IMHO you need to decide what you want and
then, if necessary, seek guidance in how to turn that into the DDL.

Tom Petch

----- Original Message -----
From: "tom petch" <ietfc@btconnect.com>
To: "Tarek Saad (tsaad)" <tsaad@cisco.com>; "mpls" <mpls@ietf.org>
Cc: <draft-ietf-mpls-static-yang@ietf.org>;
<draft-ietf-mpls-base-yang@ietf.org>
Sent: Wednesday, November 07, 2018 9:38 AM

> Getting there
>
> The convention is to limit editors to five, lest there is no room for
> anything else on page one.  Some ADs are more aggressive on this than
> others but seven is likely to draw comment; the usual technique is to
> have
> one name as (Editor) and list the others at the end.  If you want more
> than five, then you will likely be asked to justify that they all made
> significant contributions
>
> Abstract
>
> You will likely be asked to expand LER and LSR on first use.  I do not
> think that they are well enough known IETF-wide to not need expanding.
> An Abstract needs to be understandable on its own without recourse to
> the Definitions section
>
> Introduction
>
> The MPLS Static LSP YANG model is broken !
> The MPLS Static LSP YANG model is divided
> would be better IMHO
>
>
>  module ietf-mpls-static
>
>    import ietf-mpls { ..  reference "draft-ietf-mpls-base-yang: MPLS
> Base YANG Data Model";
> You are asking the RFC-Editor to notice and replace this I-D name;
> better to have
>      reference "RFC YYYY: MPLS Base YANG Data Model";
> with a note up front
>
> // RFC Ed.: replace YYYY with RFC number assigned to
> draft-ietf-mpls-base-yang
> and remove this note
>
> -  prefix "rt-types";  reference "RFC6991:
> Right prefix, wrong RFC. Hint look at s.2.3:-)
>
>    import ietf-te { ... reference "draft-ietf-teas-yang-te: A YANG
Data
> Model for Traffic Engineering Tunnels and Interfaces";
> same idea but make it ZZZZ
>
>    reference "RFC ZZZZ: A YANG Data Model for Traffic
>                 Engineering Tunnels and Interfaces";
>
> and up front
>
> // RFC Ed.: replace ZZZZ with RFC number assigned to
> draft-ietf-teas-yang-te:
> and remove this note
>
> (Some editors use XXXX for all such I-Ds which I do not think very
> helpful:-(
>
> Figure 3: MPLS Static LSP YANG module
> It is unusual to label YANG modules as Figures.
>
>
> module ietf-mpls-static-extended
>
>   import ietf-mpls { ...    reference "draft-ietf-mpls-base-yang: MPLS
> Base YANG Data Model";
>
> See above
>
>
>   import ietf-routing {prefix "rt";
>     reference "RFC6991: Common YANG Data Types";
> See above
>
> reference "draft-ietf-mpls-static-yang
> reference "RFC XXXX
> (you already have notes to replace XXXX)
>
>
> Figure 4: Extended MPLS Static LSP YANG module
> Again not wrong but unusual
>
>
> Security Considerations
> is not the current template since it lacks reference to RESTCONF which
> then needs to be a Normative Reference
>
> Also, it is weak in that it does not identify the nodes that need
> protecting.  Here it is probably enough to say
> 'All nodes defined in this YANG module that are
>    writable/creatable/deletable (i.e., config true, which is the
>    default) may be considered sensitive or vulnerable
>    in some network environments
>
> draft-ietf-ccamp-mw-yang is an example of a more comprehensive
analysis.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
> Sent: Monday, November 05, 2018 5:04 PM
>
>
> > Hi Tom,
> >
> > Thank you much for your review comments. We have addressed your
> comments in latest revision of the drafts
> (draft-ietf-mpls-static-yang-07 and draft-ietf-mpls-base-yang-09).
> Please let us know if you have any further comments or whether you're
> satisfied with the resolution.
> >
> > Regards,
> > Tarek
> >
> > -----Original Message-----
> > From: mpls <mpls-bounces@ietf.org> on behalf of "t.petch"
> <ietfc@btconnect.com>
> > Date: Friday, February 16, 2018 at 5:55 PM
> > To: "mpls@ietf.org" <mpls@ietf.org>
> > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-05.txt
> >
> >     As a YANG module, I think that this needs some - well, quite a
lot
> of -
> >     work
> >
> >     - Terminology section needs to reference RFC8174
> >
> >     - ietf-netmod-revised-datastores is the correct reference for
most
> of
> >     the terms in the Terminology section
> >
> >     - ietf-rib needs a reference (ietf-routing is the usual base
> routing
> >     module)
> >
> >     - it references YANG 1.0 and not 1.1 - if this is justified, it
> needs an
> >     explanation
> >
> >     - it is not NMDA compliant - this needs changing or justifying
> >
> >     - " and augments the MPLS Base YANG model defined in module
> >        "ietf-mpls" in [I-D.saad-mpls-static-yang].
> >
> >     ietf-mpls does not appear an the referenced I-D
> >
> >     - the I-D has five authors, the YANG module has ten
> >
> >     - the module lacks a copyright clause
> >
> >     - the imports need references, best provided with a reference
> clause for
> >     each,  and again in the text of the I-D and in the I-D
References
> >     section
> >     see
> >     draft-ietf-ccamp-alarm-module
> >     for an example of this
> >
> >     - good practice is to list the prefix used and the RFC in which
> they can
> >     be found somewhere in the text of the I-D
> >     draft-ietf-netmod-rfc8022bis
> >     has an example of this
> >
> >     - the YANG module needs a reference back to the RFC in which it
> appears
> >     along with a note to the RC editor to replace XXXX with the
> relevant
> >     number - you have a reference to RFC3031 which is sadly mistaken
> >
> >     - If a reference to RFC3031 is warranted, then it needs to
appear
> in the
> >     text of the I-D and in the References section
> >
> >     - static-extended - same comments
> >
> >     - Security Considerations needs updating - it needs to call out
> the
> >     vulnerable objects
> >
> >     Tom Petch
> >
> >     ----- Original Message -----
> >     From: <internet-drafts@ietf.org>
> >     To: <i-d-announce@ietf.org>
> >     Cc: <mpls@ietf.org>
> >     Sent: Thursday, February 15, 2018 5:42 PM
> >     Subject: I-D Action: draft-ietf-mpls-static-yang-05.txt
> >
> >
> >     >
> >     > A New Internet-Draft is available from the on-line
> Internet-Drafts
> >     directories.
> >     > This draft is a work item of the Multiprotocol Label Switching
> WG of
> >     the IETF.
> >     >
> >     >         Title           : A YANG Data Model for MPLS Static
LSPs
> >     >         Authors         : Tarek Saad
> >     >                           Kamran Raza
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>