Re: [pim] Last Call: <draft-ietf-pim-igmp-mld-yang-10.txt> (A YANG data model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)) to Proposed Standard

[tom petch <[e-mail]>]

Looking into the technical aspects of this, I am inclined to think that
it is not ready to become an RFC, needing widespread revision; the
problem is the language.  In places, I can guess what is meant, in
others, I cannot.  An example of the latter is
"Interface-global: Only including configuration data nodes that
   IGMP configuration attributes are applicable to all the interfaces
   whose interface-level corresponding attributes are not existing,
   with same attributes' value for these interfaces."
which is differentiated from "Global level" and "Interface-level".  That
combination of 'not existing' and 'same value' leaves me uncertain as to
the meaning.

(When these terms are used in the YANG descriptions, the hyphens are
missing).

'Global level' (no hyphen) is defined as "configuration and operational
state attributes for the entire routing system."  Is that the entire
routing system of all routers and hosts? or just everything regardless
of protocol in this router? or just IGMP in this router?  ...

SSM/ssm appears in dozens of places and is never expanded nor is there a
single reference.  I imagine that this is RFC3569 in which case, that
must be a Normative Reference.

'IGMP or MLD' appears in a dozen places and gives me the most heartache;
I do not know what it means.  Thus
"The maximum number of entries in IGMP or MLD.";
could be a maximum for IGMP which is also a maximum for MLD, same value;
or it could mean the maximum for IGMP or MLD combined, regardless of
which.  I cannot tell which is meant

Likewise, with
grouping global-config-attributes/ leaf enable /type boolean;
you have enable or disable coupled with IGMP and MLD; that is four
choices, while a boolean only has two values - does not compute.

Ditto
grouping interface-specific-config-attributes / leaf enable / type
boolean

Is interface specific the same as interface level?

Interestingly, where I was expecting ambiguity,
leaf discontinuity-time
...
description "The time on the most recent occasion at which any one
              or more of the statistic counters suffered a
              discontinuity. "
is perfectly clear; that ' any one or more' leaves me in no doubt.

IGMP and MLD do get expanded on first use but it would be helpful to
have the RFC reference there - you give it for YANG (surely everyone
knows those RFC numbers off by heart by now:-) but not for the less
widely used MLD.

And then there are many places where the English is understandable but
quirky and might be left to the RFC Editor but here, probably worth
changing sooner rather than later; e.g.

- not all included in this document of the data model
- including some with basic subsets of the IGMP and MLD protocols.
- any major now-existing implementation may be said to support the basic
model
- operational state parameters are not so widely designated as features
- Where fields are not genuinely essential to protocol operation
- The MLD YANG model uses the same structure as IGMP YANG model
- MLD module also defines in a three-level hierarchy structure
- IGMP and MLD RPC clears
- group-addrss?
- definitions common for IGMP and MLD
- whose are not existing in interface global level
- it prunes off the group
- that IGMP ro MLD can join
- If present, IGMP/MLD-based explicit membership tracking function for
multicast routers and IGMP/MLD proxy devices supporting IGMPv3/MLDv2.
- lightweight IGMPv3 and MLDv2 protocols will run on the which simplify
the
- List of multicast membership hosts
- The last host address which has sent the report to
- the MLD attributes at all of the interfaces level on a device

HTH:-(

Tom Petch


----- Original Message -----
From: "tom petch" <[e-mail]>

Sent: Saturday, January 26, 2019 4:57 PM


> Some initial  thoughts on this I-D
>
> Prefer 'Abstract' before 'Copyright' and 'Status'
>
>    | acl       | ietf-access-control-list | [I-D.ietf-acl-yang] |
> better to have
>    | acl       | ietf-access-control-list | [RFC YYYY] |
> Note to RFC Editor please replace YYYY with number assigned to draft-
> ietf-netmod-acl-model
>
> YANG module needs the Copyright statement
>
> 4. IGMP and MLD YANG Modules
> suggests that there are two modules but I only see one
>
>       import ietf-inet-types {
> and other imports need a reference clause to identify the RFC; for acl
> you need such as
> RFC YYYY "Network Access Control List (ACL) YANG Data Model",
> Note to RFC Editor please replace YYYY with number assigned to draft-
> ietf-netmod-acl-model
> ( you can put all RFC Editor Notes in one place at the front - they
> prefer it this way)
>
>       revision 2019-01-03 {
> there must only be one revision clause stating 'Initial revision' with
> date of publication supplied by RFC Editor to match that on the file
> statement
>
> several lines are too long e.g.
>              If QQIC >= 128, QQIC represents a floating-point value as
> follows:
>
> 5. Security Considerations
>    transport is TLS [RFC5246].
> this is now superseded
>
> 6. IANA Considerations
>    Names registry [RFC7950]:
> this is a poor reference since all it does is tell you to go to
RFC6020;
> better to tell the reader to go straight there.
>
>    [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors
> this is now out of date - RFC8407
> (and it tells you to do most of what I have listed above:-)
>
> Tom Petch
>
> ----- Original Message -----
> From: "The IESG" <[e-mail]>
> To: "IETF-Announce" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>
> Sent: Friday, January 25, 2019 8:28 PM
>
> >
> > The IESG has received a request from the Protocols for IP Multicast
WG
> (pim)
> > to consider the following document: - 'A YANG data model for
Internet
> Group
> > Management Protocol (IGMP) and
> >    Multicast Listener Discovery (MLD)'
> >   <draft-ietf-pim-igmp-mld-yang-10.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> final
> > comments on this action. Please send substantive comments to the
> > [e-mail] mailing lists by 2019-02-08. Exceptionally, comments
may
> be
> > sent to [e-mail] instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    This document defines a YANG data model that can be used to
> >    configure and manage Internet Group Management Protocol (IGMP)
and
> >    Multicast Listener Discovery (MLD) devices.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/
> >
> > IESG discussion can be tracked via
> >
https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-yang/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
>
>