Skip to main content

Multicast Group Membership Discovery MIB
RFC 5519

Revision differences

Document history

Date Rev. By Action
2017-05-16
15 (System) Changed document authors from "Brian Haberman" to "Brian Haberman, Julian Chesterfield"
2015-10-14
15 (System) Notify list changed from magma-chairs@ietf.org,julian.chesterfield@cl.cam.ac.uk,julian@xensource.com to julian@xensource.com, julian.chesterfield@cl.cam.ac.uk
2012-08-22
15 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
15 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2009-04-06
15 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2009-04-06
15 Amy Vezza [Note]: 'RFC 5519' added by Amy Vezza
2009-04-03
15 (System) RFC published
2009-02-10
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-02-10
15 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-02-10
15 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-02-10
15 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2009-02-09
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-02-09
15 (System) IANA Action state changed to In Progress
2009-02-09
15 Amy Vezza IESG state changed to Approved-announcement sent
2009-02-09
15 Amy Vezza IESG has approved the document
2009-02-09
15 Amy Vezza Closed "Approve" ballot
2009-02-09
15 Jari Arkko State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Jari Arkko
2009-02-09
15 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2009-02-09
15 (System) New version available: draft-ietf-magma-mgmd-mib-15.txt
2009-02-09
15 Dan Romascanu
[Ballot discuss]
mgmdRouterInterfaceQueryInterval OBJECT-TYPE
    SYNTAX    Unsigned32 (0..31744)
    UNITS      "seconds"
    MAX-ACCESS read-create
    STATUS    current …
[Ballot discuss]
mgmdRouterInterfaceQueryInterval OBJECT-TYPE
    SYNTAX    Unsigned32 (0..31744)
    UNITS      "seconds"
    MAX-ACCESS read-create
    STATUS    current
    DESCRIPTION
            "The frequency at which IGMP or MLD Host-Query packets are
            transmitted on this interface. This variable must be a
            non-zero value."
    DEFVAL    { 125 }

If it must be non-zero, why is 0 in the legal syntax range? It seems that the range should be (1..31744) and the last sentence in the DESCRIPTION can then be deleted.


------------
2009-02-08
14 (System) New version available: draft-ietf-magma-mgmd-mib-14.txt
2009-02-08
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-02-08
13 (System) New version available: draft-ietf-magma-mgmd-mib-13.txt
2008-10-21
15 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko
2008-09-17
15 Jari Arkko State Changes to IESG Evaluation::External Party from AD Evaluation::AD Followup by Jari Arkko
2008-09-16
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-09-16
12 (System) New version available: draft-ietf-magma-mgmd-mib-12.txt
2008-03-20
15 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk
2008-01-23
15 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko
2008-01-15
15 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2008-01-15
15 Jari Arkko Waiting for MIB doctor re-review comments.
2007-12-04
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-12-04
11 (System) New version available: draft-ietf-magma-mgmd-mib-11.txt
2007-11-01
15 Jari Arkko Asking author to resubmit. Version number was wrong, probably causing the draft to not be posted.
2007-10-28
15 Jari Arkko New version has been submitted (not appeared yet). According to Dan it should clear the Discuss.
2007-10-19
15 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko
2007-10-18
15 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2007-10-18
15 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2007-10-18
15 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-10-18
15 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-10-18
15 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2007-10-18
15 Amy Vezza State Changes to IESG Evaluation from Waiting for AD Go-Ahead::Revised ID Needed by Amy Vezza
2007-10-17
15 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-10-17
15 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-10-03
15 Jari Arkko Telechat date was changed to 2007-10-18 from 2007-10-04 by Jari Arkko
2007-10-03
15 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-10-03
15 David Ward [Ballot comment]
I am assuming that the issues are corrected that others have pointed out.
2007-10-03
15 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2007-09-20
15 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Rob Austein.
2007-09-19
15 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman
2007-09-18
15 Tim Polk
[Ballot discuss]
[Thanks to Pasi Eronen for his Gen-ART review and Rob Austein
for his secdir review; both are quoted below.]

> [from Pasi's gen-ART …
[Ballot discuss]
[Thanks to Pasi Eronen for his Gen-ART review and Rob Austein
for his secdir review; both are quoted below.]

> [from Pasi's gen-ART review]
> The following objects seem to have read-create MAX-ACCESS,
> but are not mentioned in the security considerations section:
> mgmdHostInterfaceStatus, mgmdHostInterfaceVersion,
> mgmdRouterInterfaceProxyIfIndex.

> [from Rob Austein's Secdir review]
> 1) The list of read-create variables discussed in the Security
>  Considerations section is not exhaustive.  Leaving aside the
>  RowStatus variables, I see mgmdHostInterfaceVersion and
>  mgmdRouterInterfaceProxyIfIndex.  I don't understand the proxy
>  mechanism well enough to know how the latter could be abused, but
>  mgmdHostInterfaceVersion looks like it could be abused to force an
>  incorrect version of IGMP.

Upon review, each of these objects would seem to present some
threat of denial of service.

Given that "destruction of a row disables the host side of IGMP
or MLD  on the interface", the mgmdHostInterfaceStatus OBJECT-TYPE
would seem to support a denial of service attack by bringing down a connection or preventing future connections.

The mgmdHostInterfaceVersion OBJECT-TYPE specifies the "version of
MGMD which is running on this interface."  The document notes "For
IGMP and MLD to function correctly, all routers on a LAN must be
configured to run the same version on that LAN."  Couldn't this
be used to implement a LAN-wide denial of service attack?

For mgmdRouterInterfaceProxyIfIndex, the specification notes that
"Some devices implement a form of IGMP or MLD proxying whereby
memberships learned on the interface represented by this row,
cause Host Membership Reports to be sent on the interface whose
ifIndex value is given by this object."  By setting this value to zero,
an attacker could disble transmission of Host Membership Reports,
creating a denial of service attack.

As Rob and Pasi also noted, the document omits any discussion of sensitivity
of read-only information.  I lack the expertise to identify all the sensitive
objects myself, but note that RFC 2933 and RFC 3019 (which this document
obsoletes) do identify such  objects in the security considerations section. 

From RFC 2933:

  This MIB contains readable objects whose values provide information
  related to multicast sessions.  Some of these objects could contain
  sensitive information.  In particular, the igmpCacheSelf and
  igmpCacheLastReporter can be used to identify machines which are
  listening to a given group address.

From RFC 3019:

  This MIB contains readable objects whose values provide information
  related to multicast sessions.  Some of these objects could contain
  sensitive information.  In particular, the mldCacheSelf and
  mldCacheLastReporter could be used to identify machines which are
  listening to a given group address.

While I couldn't find a "...CacheSelf" object, this specification does include the
mgmdHostCacheLastReporter object, which I presume has the same security
issues.  Anyway, I think a review for sensitive readable objects is in order...
2007-09-18
15 Tim Polk
[Ballot discuss]
[Thanks to Pasi Eronen for his Gen-ART review and Rob Austein
for his secdir review; both are quoted liberally below.]

> [from Pasi's …
[Ballot discuss]
[Thanks to Pasi Eronen for his Gen-ART review and Rob Austein
for his secdir review; both are quoted liberally below.]

> [from Pasi's gen-ART review]
> The following objects seem to have read-create MAX-ACCESS,
> but are not mentioned in the security considerations section:
> mgmdHostInterfaceStatus, mgmdHostInterfaceVersion,
> mgmdRouterInterfaceProxyIfIndex.

> [from Rob Austein's Secdir review]
> 1) The list of read-create variables discussed in the Security
>  Considerations section is not exhaustive.  Leaving aside the
>  RowStatus variables, I see mgmdHostInterfaceVersion and
>  mgmdRouterInterfaceProxyIfIndex.  I don't understand the proxy
>  mechanism well enough to know how the latter could be abused, but
>  mgmdHostInterfaceVersion looks like it could be abused to force an
>  incorrect version of IGMP.

Upon review, each of these objects would seem to present some
threat of denial of service.

Given that "destruction of a row disables the host side of IGMP
or MLD  on the interface", the mgmdHostInterfaceStatus OBJECT-TYPE
would seem to support a denial of service attack by bringing down a connection or preventing future connections.

The mgmdHostInterfaceVersion OBJECT-TYPE specifies the "version of
MGMD which is running on this interface."  The document notes "For
IGMP and MLD to function correctly, all routers on a LAN must be
configured to run the same version on that LAN."  Couldn't this
be used to implement a LAN-wide denial of service attack?

For mgmdRouterInterfaceProxyIfIndex, the specification notes that
"Some devices implement a form of IGMP or MLD proxying whereby
memberships learned on the interface represented by this row,
cause Host Membership Reports to be sent on the interface whose
ifIndex value is given by this object."  By setting this value to zero,
an attacker could disble transmission of Host Membership Reports,
creating a denial of service attack.
2007-09-18
15 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2007-09-18
15 Jari Arkko Telechat date was changed to 2007-10-04 from 2007-09-20 by Jari Arkko
2007-09-18
15 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-09-17
15 Russ Housley
[Ballot comment]
From Gen-ART review by Pasi Eronen.

  1) Section 3: " All tables are intended for EITHER router OR host
  functionality as …
[Ballot comment]
From Gen-ART review by Pasi Eronen.

  1) Section 3: " All tables are intended for EITHER router OR host
  functionality as indicated by the name and corresponding description,
  although it is anticipated that there would be scenarios where both
  terms might apply to a device, e.g. a router which joins a multicast
  group also as a host for measurement purposes."

  At least in the case of IPv6, a router is required to join certain
  multicast groups, right? And even in IPv4, wouldn't a router
  normally join 224.0.0.2?

  2) Terminology: The term "MGMDv1" (and "MGMDv2", "MGMDv3") is
  used in several places: does this mean IGMPv1, MLDv1, both of
  them, is this some weirdness caused by a search-replace accident?

  3) Description of "mgmdRouterInterfaceProxyIfIndex" object:
  "Such a device would implement the mgmdV2RouterBaseMIBGroup"
  I can't find the definition of "mgmdV2RouterBaseMIBGroup" anywhere?

  4) The security considerations section is a bit confused about what
  object belongs to what table. For example, to me it looks like
  mgmdRouterInterfaceVersion would be in mgmdRouterInterfaceTable, not
  mgmdRouterCacheTable?

  5) The following objects seem to have read-create MAX-ACCESS,
  but are not mentioned in the security considerations section:
  mgmdHostInterfaceStatus, mgmdHostInterfaceVersion,
  mgmdRouterInterfaceProxyIfIndex.

  6) There is no discussion about what MIB objects (if any) might
  contain sensitive information.
2007-09-17
15 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2007-09-17
15 Dan Romascanu
[Ballot discuss]
A number of issues have been raised in MIB doctor reviews performed by Dave Thaler and Bert Wijnen. The editors agreed to fix …
[Ballot discuss]
A number of issues have been raised in MIB doctor reviews performed by Dave Thaler and Bert Wijnen. The editors agreed to fix those in a revised I-D. Below is Dave's review which also includes Bert's comments.

--------------

Section 1:
>  [RFC2236] or version 3 [3376] and the Multicast Listener Discovery

s/[3376]/[RFC3376]/

>  This version of the MIB obsoletes both rfc2933 [RFC2933] and rfc3019

s/MIB/MIB module/
s/rfc2933/RFC 2933/
s/rfc3019/RFC 3019/

Section 2:
> document are to be interpreted as described in RFC-2119 [KEYWORDS].

[KEYWORDS] should be [RFC2119], which is how it appears in the references section.

Also s/RFC-2119/RFC 2119/

Section 3:

>    5. the reverse MGMD Host Table which contains one row for each
>      interface for which there are active multicast groups on a host,

This is not correct.  The mgmdInverseHostCacheTable has INDEX:
>  INDEX      { mgmdInverseHostCacheIfIndex,
>                mgmdInverseHostCacheAddressType,
>                mgmdInverseHostCacheAddress}

Hence it contains one row for each IP multicast group for which there are members on a particular interface on a host (same as the MGMD Host Cache Table), but they're in a different order.

>    6. the reverse MGMD Router Table which contains one row for each
>      interface for which there are active multicast groups on a
>      router,

Same error in the text above.

> as defined in RFC 2863, the MIB which decribes generic objects for

Grammar.  s/which/that/

Also s/MIB/MIB module/

Section 4:

MODULE-IDENTITY:
>From RFC 4181 section 4.5:
>  - If the module was developed by an IETF working group, then the
>    ORGANIZATION clause MUST provide the full name of the working
>    group, and the CONTACT-INFO clause MUST include working group
>    mailing list information.  The CONTACT-INFO clause SHOULD also
>    provide a pointer to the working group's web page.

Currently the MGMD doc contains the info in WG mailing list and web page in the ORGANIZATION clause, and these need to be moved to the CONTACT-INFO clause as noted above.

Also missing an initial REVISION clause as noted in RFC 4181 section 4.5.

>        "The MIB module for MGMD management.
                              ^^^^
Suggest expanding the MGMD acronym on first usage inside the MIB module.

mgmdHostInterfaceQuerier:

> The address of the IGMP or MLD Querier on the IP subnet to which this
> interface is attached. The InetAddressType, e.g.

Per section 5 of RFC 3810, all MLD messages MUST be sent from a link-local source address.  Hence the IPv6 subnet prefix is irrelevant and the text above incorrectly implies there can only be one subnet prefix on the link.
Instead, it should say it's the address seen as the source address of IGMP or MLD Queries on the interface.

Same comment on the DESCRIPTION of the mgmdRouterInterfaceQuerier object.

mgmdHostInterfaceStatus:

RFC 4181 states regarding RowStatus objects...
>    - There either MUST be one columnar object with a SYNTAX value of
>      StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
>      else the row object (table entry) DESCRIPTION clause MUST specify
>      what happens to dynamically-created rows after an agent restart.
>
>    - The DESCRIPTION clause of the status column MUST specify which
>      columnar objects (if any) have to be set to valid values before
>      the row can be activated.  If any objects in cascading tables
>      have to be populated with related data before the row can be
>      activated, then this MUST also be specified.
>
>    - The DESCRIPTION clause of the status column MUST specify whether
>      or not it is possible to modify other columns in the same
>      conceptual row when the status value is active(1).  Note that in
>      many cases it will be possible to modify some writable columns
>      when the row is active but not others.  In such cases, the
>      DESCRIPTION clause for each writable column SHOULD state whether
>      or not that column can be modified when the row is active, and
>      the DESCRIPTION clause for the status column SHOULD state that
>      modifiability of other columns when the status value is active(1)
>      is specified in the DESCRIPTION clauses for those columns (rather
>      than listing the modifiable columns individually).

None of the above MUSTs are currently met in the draft.
Same for the RowStatus objects of the other tables in the draft.

mgmdRouterInterfaceTable:
Currently the DESCRIPTION is identical to the description of the mgmdHostInterfaceTable.  It SHOULD be different.

mgmdRouterInterfaceQueryInterval:
>  SYNTAX    Unsigned32 (0..31744)
>  DESCRIPTION
>          "The frequency at which IGMP or MLD Host-Query packets are
>          transmitted on this interface. This variable must be a
>          non-zero value."

If it must be non-zero, why is 0 in the legal syntax range?  Seems like the range should be (1..31744) and the last sentence deleted.

mgmdRouterInterfaceVersion:
Fix incorrect capitalization of "To" in the DESCRIPTION.

mgmdRouterInterfaceQueryMaxResponseTime:
The reference clause points to RFC 3810 section 9.3, but not to the equivalent for IPv4 (RFC 3376 section 8.3).

Many objects:
>  SYNTAX    InetAddressType (SIZE(4|16))

This is incorrect.  This is an integer, not an octet string, so the SIZE restriction is wrong.  It should instead be:
>  SYNTAX    InetAddressType { ipv4(1), ipv6(2) }
if you want to restrict what is legal to IPv4 and IPv6.

mgmdRouterInterfaceRobustness has a syntax restriction of (1..255) which is fine, but mgmdHostInterfaceVersion3Robustness has none and just has the statement "The variable must be a non-zero value" in the DESCRIPTION.
It should instead have a range restriction.

mgmdHostCacheLastReporter's DESCRIPTION says:
> ... If no membership report has been received, this object has a value of 0.

Since this is an InetAddress object, shouldn't this say 0.0.0.0 for IPv4 or :: for IPv6?  (And same for mgmdRouterCacheLastReporter)

mgmdRouterCacheExpiryTime:
The sentence in the DESCRIPTION "The value must always be greater than or equal to 1" can be deleted since it's redundant with the range restriction in the SYNTAX clause.

There's an odd difference between the mgmdInverseHostCacheTable and the mgmdRouterInverseCacheTable.  The former defines its own columnar objects for the INDEX, whereas the latter uses the objects in the mgmdRouterCacheTable in its INDEX.  Why the inconsistency between these tables?

mgmdRouterSrcListEntry:
Fix indentation in INDEX clause.

Section 5:

>  a) The mgmdRouterInterfaceTable provides read-create acces to 2

s/acces/access/

Section 6:
There are two section 6's.  "IANA Considerations" and "Contributors"
are both numbered 6.

Section 6: IANA Considerations
>  This MIB introduces a new term to refer to two existing multicast 
> protocols, Multicast Group Membership Discovery. It encompasses both 
> the IPv4 Multicast discovery protocol, IGMP, and the IPv6 Multicast 
> discovery protocol, MLD, as defined in RFCs 2933 and 3019 
> respectively.

I don't see what the above paragraph has to do with IANA considerations or with anything else in that section.  It looks like something that belongs in the introduction section.

Also s/MIB/MIB module/

Section 9:

References should be listed in order.



idnits output:


tmp/draft-ietf-magma-mgmd-mib-10.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

  ** The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
    Acknowledgement -- however, there's a paragraph with a matching
    beginning. Boilerplate error?


  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == Mismatching filename: the document gives the document name as
    'draft-ietf-magma-mgmd-mib-09', but the file name used is
    'draft-ietf-magma-mgmd-mib-10'

  == No 'Intended status' indicated for this document; assuming Proposed
    Standard

  == It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 34 pages


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

  ** There are 6 instances of too long lines in the document, the longest one
    being 3 characters in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFC 3967 for information about using normative references to
    lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '3376' on line 70

  == Missing Reference: 'KEYWORDS' is mentioned on line 83, but not defined

  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'KEYWORDS'

  == Missing Reference: 'RFC 1112' is mentioned on line 1176, but not defined

  == Missing Reference: 'RFC 2236' is mentioned on line 1232, but not defined

  ** Obsolete undefined reference: RFC 2236 (Obsoleted by RFC 3376)

  == Missing Reference: 'RFC 2710' is mentioned on line 1279, but not defined

  == Missing Reference: 'RFC 3376' is mentioned on line 1344, but not defined

  == Unused Reference: 'RFC3376' is defined on line 1730, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2863' is defined on line 1740, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4001' is defined on line 1743, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2119' is defined on line 1749, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3414' is defined on line 1765, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3415' is defined on line 1769, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4605' is defined on line 1773, but no explicit
    reference was found in the text

  ** Obsolete normative reference: RFC 2236 (Obsoleted by RFC 3376)

(Note that the reference to RFC 2236 is actually correct.  It was actually wrong for RFC 3376 to obsolete RFC 2236, it actually updates it since it does not respecify the IGMPv2 behavior (e.g. it normatively references 2236 for the packet format of the v2 report) and actually mandates that it use
IGMPv2 under certain conditions.  Hence I believe it was in fact a process error that 3376 was allowed to claim it obsoleted 2236.  Anyway, the point is that referencing 2236 is correct and the "obsolete normative reference"
complaint should be ignored.)

Also the smi checker output (which Bert already ran, so just copying his output here) is below.
Some of these are the same as items I noted above.

> I get this from SMICng:
>
> C:\bwijnen\smicng\work>smicng mgmd.inc
> E: f(mgmd.mi2), (90,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (246,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (487,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (590,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (644,27) A SIZE or range clause may not be used with
> TimeTicks
> E: f(mgmd.mi2), (751,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (835,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (797,5) Item "mgmdRouterInterfaceIfIndex" in sequence
> "MgmdRouterInverseCacheEntry" is not a column for row
> "mgmdRouterInverseCacheEntry"
> E: f(mgmd.mi2), (798,5) Item "mgmdRouterCacheAddressType" in sequence
> "MgmdRouterInverseCacheEntry" is not a column for row
> "mgmdRouterInverseCacheEntry"
> E: f(mgmd.mi2), (799,5) Item "mgmdRouterCacheAddress" in sequence
> "MgmdRouterInverseCacheEntry" is not a column for row
> "mgmdRouterInverseCacheEntry"
> E: f(mgmd.mi2), (910,5) Item "mgmdRouterCacheAddressType" in sequence
> "MgmdRouterSrcListEntry" is not a column for row "
> mgmdRouterSrcListEntry"
> E: f(mgmd.mi2), (911,5) Item "mgmdRouterCacheAddress" in sequence
> "MgmdRouterSrcListEntry" is not a column for row "mgmd
> RouterSrcListEntry"
> E: f(mgmd.mi2), (912,5) Item "mgmdRouterCacheIfIndex" in sequence
> "MgmdRouterSrcListEntry" is not a column for row "mgmd
> RouterSrcListEntry"
> E: f(mgmd.mi2), (784,1) Row "mgmdRouterInverseCacheEntry" must have
> leaf objects defined under it
> W: f(mgmd.mi2), (791,18) Row "mgmdRouterInverseCacheEntry" does not
> have a consistent indexing scheme - cannot specify a n index item from
> additional "base row" mgmdRouterInterfaceEntry, since can have only
> one "base row" which is mgmdRouter CacheEntry
>
> *** 14 errors and 1 warning in parsing
>
> And I get this from smilint:
>
> C:\bwijnen\smicng\work>smilint -m -l 6 -s ./MGMD-STD-MIB
> ./MGMD-STD-MIB:39: [3] {revision-missing} revision for last update is
> missing
> ./MGMD-STD-MIB:90: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:100: [2] {sequence-type-mismatch} type of
> `mgmdHostInterfaceQuerierType' in sequence and object type defi nition
> do not match
> ./MGMD-STD-MIB:246: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:256: [2] {sequence-type-mismatch} type of
> `mgmdRouterInterfaceQuerierType' in sequence and object type de
> finition do not match
> ./MGMD-STD-MIB:487: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:494: [2] {sequence-type-mismatch} type of
> `mgmdHostCacheAddressType' in sequence and object type definiti on do
> not match
> ./MGMD-STD-MIB:590: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:597: [2] {sequence-type-mismatch} type of
> `mgmdRouterCacheAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:644: [2] {subtype-illegal} subtyping not allowed
> ./MGMD-STD-MIB:751: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:756: [2] {sequence-type-mismatch} type of
> `mgmdInverseHostCacheAddressType' in sequence and object type d
> efinition do not match
> ./MGMD-STD-MIB:798: [2] {sequence-type-mismatch} type of
> `mgmdRouterCacheAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:835: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:842: [2] {sequence-type-mismatch} type of
> `mgmdHostSrcListAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:910: [2] {sequence-type-mismatch} type of
> `mgmdRouterCacheAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:796: [3] {sequence-no-column} SEQUENCE element #1
> `mgmdRouterInterfaceIfIndex' is not a child node under
> `mgmdRouterInverseCacheEntry'
> ./MGMD-STD-MIB:784: [5] {index-element-not-accessible} warning:
> exactly one index element of row `mgmdRouterInverseCache Entry' must
> be accessible
> ./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #1
> `mgmdRouterCacheAddressType' is not a child node under
> `mgmdRouterSrcListEntry'
> ./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #2
> `mgmdRouterCacheAddress' is not a child node under `mgm
> dRouterSrcListEntry'
> ./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #3
> `mgmdRouterCacheIfIndex' is not a child node under `mgm
> dRouterSrcListEntry'
> ./MGMD-STD-MIB:102: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:258: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:496: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:524: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:599: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:620: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:758: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:844: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:862: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:917: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object

Finally, it might be helpful, though not required, to have a section that summarizes the changes from RFC 2933 and RFC 3019.  So feel free to ignore this one.

----------------
2007-09-17
15 Dan Romascanu
[Ballot discuss]
A number of issues have been raised in MIB doctor reviews performed by Dave Thaler and Bert Wijnen. The ditors agreed to fix …
[Ballot discuss]
A number of issues have been raised in MIB doctor reviews performed by Dave Thaler and Bert Wijnen. The ditors agreed to fix those in a revised I-D. Blow is Dave's review which also includes Bert's comments.

--------------

Section 1:
>  [RFC2236] or version 3 [3376] and the Multicast Listener Discovery

s/[3376]/[RFC3376]/

>  This version of the MIB obsoletes both rfc2933 [RFC2933] and rfc3019

s/MIB/MIB module/
s/rfc2933/RFC 2933/
s/rfc3019/RFC 3019/

Section 2:
> document are to be interpreted as described in RFC-2119 [KEYWORDS].

[KEYWORDS] should be [RFC2119], which is how it appears in the references section.

Also s/RFC-2119/RFC 2119/

Section 3:

>    5. the reverse MGMD Host Table which contains one row for each
>      interface for which there are active multicast groups on a host,

This is not correct.  The mgmdInverseHostCacheTable has INDEX:
>  INDEX      { mgmdInverseHostCacheIfIndex,
>                mgmdInverseHostCacheAddressType,
>                mgmdInverseHostCacheAddress}

Hence it contains one row for each IP multicast group for which there are members on a particular interface on a host (same as the MGMD Host Cache Table), but they're in a different order.

>    6. the reverse MGMD Router Table which contains one row for each
>      interface for which there are active multicast groups on a
>      router,

Same error in the text above.

> as defined in RFC 2863, the MIB which decribes generic objects for

Grammar.  s/which/that/

Also s/MIB/MIB module/

Section 4:

MODULE-IDENTITY:
>From RFC 4181 section 4.5:
>  - If the module was developed by an IETF working group, then the
>    ORGANIZATION clause MUST provide the full name of the working
>    group, and the CONTACT-INFO clause MUST include working group
>    mailing list information.  The CONTACT-INFO clause SHOULD also
>    provide a pointer to the working group's web page.

Currently the MGMD doc contains the info in WG mailing list and web page in the ORGANIZATION clause, and these need to be moved to the CONTACT-INFO clause as noted above.

Also missing an initial REVISION clause as noted in RFC 4181 section 4.5.

>        "The MIB module for MGMD management.
                              ^^^^
Suggest expanding the MGMD acronym on first usage inside the MIB module.

mgmdHostInterfaceQuerier:

> The address of the IGMP or MLD Querier on the IP subnet to which this
> interface is attached. The InetAddressType, e.g.

Per section 5 of RFC 3810, all MLD messages MUST be sent from a link-local source address.  Hence the IPv6 subnet prefix is irrelevant and the text above incorrectly implies there can only be one subnet prefix on the link.
Instead, it should say it's the address seen as the source address of IGMP or MLD Queries on the interface.

Same comment on the DESCRIPTION of the mgmdRouterInterfaceQuerier object.

mgmdHostInterfaceStatus:

RFC 4181 states regarding RowStatus objects...
>    - There either MUST be one columnar object with a SYNTAX value of
>      StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
>      else the row object (table entry) DESCRIPTION clause MUST specify
>      what happens to dynamically-created rows after an agent restart.
>
>    - The DESCRIPTION clause of the status column MUST specify which
>      columnar objects (if any) have to be set to valid values before
>      the row can be activated.  If any objects in cascading tables
>      have to be populated with related data before the row can be
>      activated, then this MUST also be specified.
>
>    - The DESCRIPTION clause of the status column MUST specify whether
>      or not it is possible to modify other columns in the same
>      conceptual row when the status value is active(1).  Note that in
>      many cases it will be possible to modify some writable columns
>      when the row is active but not others.  In such cases, the
>      DESCRIPTION clause for each writable column SHOULD state whether
>      or not that column can be modified when the row is active, and
>      the DESCRIPTION clause for the status column SHOULD state that
>      modifiability of other columns when the status value is active(1)
>      is specified in the DESCRIPTION clauses for those columns (rather
>      than listing the modifiable columns individually).

None of the above MUSTs are currently met in the draft.
Same for the RowStatus objects of the other tables in the draft.

mgmdRouterInterfaceTable:
Currently the DESCRIPTION is identical to the description of the mgmdHostInterfaceTable.  It SHOULD be different.

mgmdRouterInterfaceQueryInterval:
>  SYNTAX    Unsigned32 (0..31744)
>  DESCRIPTION
>          "The frequency at which IGMP or MLD Host-Query packets are
>          transmitted on this interface. This variable must be a
>          non-zero value."

If it must be non-zero, why is 0 in the legal syntax range?  Seems like the range should be (1..31744) and the last sentence deleted.

mgmdRouterInterfaceVersion:
Fix incorrect capitalization of "To" in the DESCRIPTION.

mgmdRouterInterfaceQueryMaxResponseTime:
The reference clause points to RFC 3810 section 9.3, but not to the equivalent for IPv4 (RFC 3376 section 8.3).

Many objects:
>  SYNTAX    InetAddressType (SIZE(4|16))

This is incorrect.  This is an integer, not an octet string, so the SIZE restriction is wrong.  It should instead be:
>  SYNTAX    InetAddressType { ipv4(1), ipv6(2) }
if you want to restrict what is legal to IPv4 and IPv6.

mgmdRouterInterfaceRobustness has a syntax restriction of (1..255) which is fine, but mgmdHostInterfaceVersion3Robustness has none and just has the statement "The variable must be a non-zero value" in the DESCRIPTION.
It should instead have a range restriction.

mgmdHostCacheLastReporter's DESCRIPTION says:
> ... If no membership report has been received, this object has a value of 0.

Since this is an InetAddress object, shouldn't this say 0.0.0.0 for IPv4 or :: for IPv6?  (And same for mgmdRouterCacheLastReporter)

mgmdRouterCacheExpiryTime:
The sentence in the DESCRIPTION "The value must always be greater than or equal to 1" can be deleted since it's redundant with the range restriction in the SYNTAX clause.

There's an odd difference between the mgmdInverseHostCacheTable and the mgmdRouterInverseCacheTable.  The former defines its own columnar objects for the INDEX, whereas the latter uses the objects in the mgmdRouterCacheTable in its INDEX.  Why the inconsistency between these tables?

mgmdRouterSrcListEntry:
Fix indentation in INDEX clause.

Section 5:

>  a) The mgmdRouterInterfaceTable provides read-create acces to 2

s/acces/access/

Section 6:
There are two section 6's.  "IANA Considerations" and "Contributors"
are both numbered 6.

Section 6: IANA Considerations
>  This MIB introduces a new term to refer to two existing multicast 
> protocols, Multicast Group Membership Discovery. It encompasses both 
> the IPv4 Multicast discovery protocol, IGMP, and the IPv6 Multicast 
> discovery protocol, MLD, as defined in RFCs 2933 and 3019 
> respectively.

I don't see what the above paragraph has to do with IANA considerations or with anything else in that section.  It looks like something that belongs in the introduction section.

Also s/MIB/MIB module/

Section 9:

References should be listed in order.



idnits output:


tmp/draft-ietf-magma-mgmd-mib-10.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

  ** The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
    Acknowledgement -- however, there's a paragraph with a matching
    beginning. Boilerplate error?


  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == Mismatching filename: the document gives the document name as
    'draft-ietf-magma-mgmd-mib-09', but the file name used is
    'draft-ietf-magma-mgmd-mib-10'

  == No 'Intended status' indicated for this document; assuming Proposed
    Standard

  == It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 34 pages


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

  ** There are 6 instances of too long lines in the document, the longest one
    being 3 characters in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFC 3967 for information about using normative references to
    lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '3376' on line 70

  == Missing Reference: 'KEYWORDS' is mentioned on line 83, but not defined

  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'KEYWORDS'

  == Missing Reference: 'RFC 1112' is mentioned on line 1176, but not defined

  == Missing Reference: 'RFC 2236' is mentioned on line 1232, but not defined

  ** Obsolete undefined reference: RFC 2236 (Obsoleted by RFC 3376)

  == Missing Reference: 'RFC 2710' is mentioned on line 1279, but not defined

  == Missing Reference: 'RFC 3376' is mentioned on line 1344, but not defined

  == Unused Reference: 'RFC3376' is defined on line 1730, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2863' is defined on line 1740, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4001' is defined on line 1743, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2119' is defined on line 1749, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3414' is defined on line 1765, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3415' is defined on line 1769, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4605' is defined on line 1773, but no explicit
    reference was found in the text

  ** Obsolete normative reference: RFC 2236 (Obsoleted by RFC 3376)

(Note that the reference to RFC 2236 is actually correct.  It was actually wrong for RFC 3376 to obsolete RFC 2236, it actually updates it since it does not respecify the IGMPv2 behavior (e.g. it normatively references 2236 for the packet format of the v2 report) and actually mandates that it use
IGMPv2 under certain conditions.  Hence I believe it was in fact a process error that 3376 was allowed to claim it obsoleted 2236.  Anyway, the point is that referencing 2236 is correct and the "obsolete normative reference"
complaint should be ignored.)

Also the smi checker output (which Bert already ran, so just copying his output here) is below.
Some of these are the same as items I noted above.

> I get this from SMICng:
>
> C:\bwijnen\smicng\work>smicng mgmd.inc
> E: f(mgmd.mi2), (90,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (246,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (487,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (590,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (644,27) A SIZE or range clause may not be used with
> TimeTicks
> E: f(mgmd.mi2), (751,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (835,38) A SIZE or range clause may not be used with
> ENUM
> E: f(mgmd.mi2), (797,5) Item "mgmdRouterInterfaceIfIndex" in sequence
> "MgmdRouterInverseCacheEntry" is not a column for row
> "mgmdRouterInverseCacheEntry"
> E: f(mgmd.mi2), (798,5) Item "mgmdRouterCacheAddressType" in sequence
> "MgmdRouterInverseCacheEntry" is not a column for row
> "mgmdRouterInverseCacheEntry"
> E: f(mgmd.mi2), (799,5) Item "mgmdRouterCacheAddress" in sequence
> "MgmdRouterInverseCacheEntry" is not a column for row
> "mgmdRouterInverseCacheEntry"
> E: f(mgmd.mi2), (910,5) Item "mgmdRouterCacheAddressType" in sequence
> "MgmdRouterSrcListEntry" is not a column for row "
> mgmdRouterSrcListEntry"
> E: f(mgmd.mi2), (911,5) Item "mgmdRouterCacheAddress" in sequence
> "MgmdRouterSrcListEntry" is not a column for row "mgmd
> RouterSrcListEntry"
> E: f(mgmd.mi2), (912,5) Item "mgmdRouterCacheIfIndex" in sequence
> "MgmdRouterSrcListEntry" is not a column for row "mgmd
> RouterSrcListEntry"
> E: f(mgmd.mi2), (784,1) Row "mgmdRouterInverseCacheEntry" must have
> leaf objects defined under it
> W: f(mgmd.mi2), (791,18) Row "mgmdRouterInverseCacheEntry" does not
> have a consistent indexing scheme - cannot specify a n index item from
> additional "base row" mgmdRouterInterfaceEntry, since can have only
> one "base row" which is mgmdRouter CacheEntry
>
> *** 14 errors and 1 warning in parsing
>
> And I get this from smilint:
>
> C:\bwijnen\smicng\work>smilint -m -l 6 -s ./MGMD-STD-MIB
> ./MGMD-STD-MIB:39: [3] {revision-missing} revision for last update is
> missing
> ./MGMD-STD-MIB:90: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:100: [2] {sequence-type-mismatch} type of
> `mgmdHostInterfaceQuerierType' in sequence and object type defi nition
> do not match
> ./MGMD-STD-MIB:246: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:256: [2] {sequence-type-mismatch} type of
> `mgmdRouterInterfaceQuerierType' in sequence and object type de
> finition do not match
> ./MGMD-STD-MIB:487: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:494: [2] {sequence-type-mismatch} type of
> `mgmdHostCacheAddressType' in sequence and object type definiti on do
> not match
> ./MGMD-STD-MIB:590: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:597: [2] {sequence-type-mismatch} type of
> `mgmdRouterCacheAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:644: [2] {subtype-illegal} subtyping not allowed
> ./MGMD-STD-MIB:751: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:756: [2] {sequence-type-mismatch} type of
> `mgmdInverseHostCacheAddressType' in sequence and object type d
> efinition do not match
> ./MGMD-STD-MIB:798: [2] {sequence-type-mismatch} type of
> `mgmdRouterCacheAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:835: [2] {size-illegal} illegal size restriction for
> non-octet-string parent type `InetAddressType'
> ./MGMD-STD-MIB:842: [2] {sequence-type-mismatch} type of
> `mgmdHostSrcListAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:910: [2] {sequence-type-mismatch} type of
> `mgmdRouterCacheAddressType' in sequence and object type defini tion
> do not match
> ./MGMD-STD-MIB:796: [3] {sequence-no-column} SEQUENCE element #1
> `mgmdRouterInterfaceIfIndex' is not a child node under
> `mgmdRouterInverseCacheEntry'
> ./MGMD-STD-MIB:784: [5] {index-element-not-accessible} warning:
> exactly one index element of row `mgmdRouterInverseCache Entry' must
> be accessible
> ./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #1
> `mgmdRouterCacheAddressType' is not a child node under
> `mgmdRouterSrcListEntry'
> ./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #2
> `mgmdRouterCacheAddress' is not a child node under `mgm
> dRouterSrcListEntry'
> ./MGMD-STD-MIB:909: [3] {sequence-no-column} SEQUENCE element #3
> `mgmdRouterCacheIfIndex' is not a child node under `mgm
> dRouterSrcListEntry'
> ./MGMD-STD-MIB:102: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:258: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:496: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:524: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:599: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:620: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:758: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:844: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:862: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object
> ./MGMD-STD-MIB:917: [5] {inetaddress-inetaddresstype} warning:
> `InetAddress' object should have an accompanied preceding 
> `InetAdressType' object

Finally, it might be helpful, though not required, to have a section that summarizes the changes from RFC 2933 and RFC 3019.  So feel free to ignore this one.

----------------
2007-09-17
15 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2007-09-17
15 Jari Arkko State Changes to Waiting for AD Go-Ahead::Revised ID Needed from IESG Evaluation::Revised ID Needed by Jari Arkko
2007-09-14
15 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Jari Arkko
2007-09-14
15 Jari Arkko Based on last call, this document really needs a revision.
2007-09-13
15 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-09-11
15 Amanda Baber
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "NETWORK MANAGEMENT PARAMETERS" registry
located at

http://www.iana.org/assignments/smi-numbers …
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "NETWORK MANAGEMENT PARAMETERS" registry
located at

http://www.iana.org/assignments/smi-numbers
Sub-registry: "Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"
Decimal Name Description References
------- ---- ----------- ----------

TDB mgmdStdtMIB Multicast Group Membership Discovery [RFC-magma-mgmd-mib-10]

We understand the above to be the only IANA Action for this
document.
2007-08-30
15 Samuel Weiler Request for Last Call review by SECDIR is assigned to Rob Austein
2007-08-30
15 Samuel Weiler Request for Last Call review by SECDIR is assigned to Rob Austein
2007-08-30
15 Amy Vezza Last call sent
2007-08-30
15 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-08-30
15 Jari Arkko Placed on agenda for telechat - 2007-09-20 by Jari Arkko
2007-08-30
15 Jari Arkko [Note]: 'Document Shepherd is Brian Haberman' added by Jari Arkko
2007-08-30
15 Jari Arkko State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko
2007-08-30
15 Jari Arkko Last Call was requested by Jari Arkko
2007-08-30
15 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2007-08-30
15 Jari Arkko Ballot has been issued by Jari Arkko
2007-08-30
15 Jari Arkko Created "Approve" ballot
2007-08-30
15 (System) Ballot writeup text was added
2007-08-30
15 (System) Last call text was added
2007-08-30
15 (System) Ballot approval text was added
2007-08-30
15 Jari Arkko
Questionnaire from 2006:

1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to …
Questionnaire from 2006:

1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward to the IESG

  for publication?



Yes



2) Has the document had adequate review from both key WG members and

  key non-WG members? Do you have any concerns about the depth or

  breadth of the reviews that have been performed?

The document has been reviewed by key WG members and the chairs
have no concerns with those reviews.



3) Do you have concerns that the document needs more review from a

  particular (broader) perspective (e.g., security, operational

  complexity, someone familiar with AAA, etc.)?


As usual for a MIB, the chairs would like MIB Doctor review to ensure
compliance with SNMP-related rules.


4) Do you have any specific concerns/issues with this document that

  you believe the ADs and/or IESG should be aware of? For example,

  perhaps you are uncomfortable with certain parts of the document,

  or whether there really is a need for it, etc., but at the same

  time these issues have been discussed in the WG and the WG has

  indicated it wishes to advance the document anyway.


No concerns.


5) How solid is the WG consensus behind this document?  Does it

  represent the strong concurrence of a few individuals, with others

  being silent, or does the WG as a whole understand and agree with

  it?


The WG as a whole supports this effort.


6) Has anyone threatened an appeal or otherwise indicated extreme

  discontent?  If so, please summarize what are they upset about.


No.


7) Have the chairs verified that the document adheres to _all_ of the

  ID nits?



Yes



- Technical Summary


  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes objects used for managing the Internet
  Group Management Protocol (IGMP) and the Multicast Listener
  Discovery (MLD) protocol.


- Working Group Summary



The MAGMA working group has done extensive review of this document and

this document reflects the consensus of the group.



- Protocol Quality



This document has been reviewed by members of the magma@ietf.org

mailing list and by the working group chairs.





Regards,

Brian & Isidor

MAGMA WG co-chairs
2007-08-30
15 Jari Arkko
Brian Haberman:

This revision addresses all the comments made by David McWalter and Dave Thaler.  Even though the I-D editor posted the draft, the id-nits …
Brian Haberman:

This revision addresses all the comments made by David McWalter and Dave Thaler.  Even though the I-D editor posted the draft, the id-nits tool run automatically on tools.ietf.org says there are 4 errors with a boilerplate mismatch and long lines being the biggest issues. The reference to RFC 2119 in the Introduction still uses [KEYWORDS] which doesn't exist in the Reference section.
2007-08-28
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-08-28
10 (System) New version available: draft-ietf-magma-mgmd-mib-10.txt
2007-08-17
15 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko
2007-08-17
15 Jari Arkko Still need to resolve the issues from my mail; not everything in MIB doctor review was addressed.
2007-07-12
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-07-12
09 (System) New version available: draft-ietf-magma-mgmd-mib-09.txt
2007-07-11
15 Jari Arkko State Change Notice email list have been change to magma-chairs@tools.ietf.org,julian.chesterfield@cl.cam.ac.uk,julian@xensource.com from magma-chairs@tools.ietf.org,julian.chesterfield@cl.cam.ac.uk
2007-07-11
15 Jari Arkko Look at the submitted -09 reveals that it is not ready, needs a few more changes. May not even get posted due to boilerplate error.
2007-04-23
15 Jari Arkko
I reviewed the proposed -09 version, and found some issues that had not been addressed from the MIB doctor review. In addition, there are some …
I reviewed the proposed -09 version, and found some issues that had not been addressed from the MIB doctor review. In addition, there are some comments on the list and some feedback from the chairs. Finally, I asked Dave Thaler to verify that his MIB doctor review comments have been addressed.
2007-04-23
15 Jari Arkko Julien has a new revision, asks for feedback.
2006-10-27
15 Jari Arkko Julian responds and promises to edit the draft next week.
2006-10-27
15 Jari Arkko
Sent a query to Julian's university address, called his phone number, and talked to the chairs. We will wait for a week, then switch to …
Sent a query to Julian's university address, called his phone number, and talked to the chairs. We will wait for a week, then switch to another editor.
2006-10-27
15 Jari Arkko State Change Notice email list have been change to magma-chairs@tools.ietf.org,julian.chesterfield@cl.cam.ac.uk from magma-chairs@tools.ietf.org
2006-04-06
15 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko
2006-04-06
15 Jari Arkko
MIB Doctor review from Dave Thaler sent to the chairs and authors on April 1, 2006. Jari's AD review on April 6 agrees with issues …
MIB Doctor review from Dave Thaler sent to the chairs and authors on April 1, 2006. Jari's AD review on April 6 agrees with issues raised in that review, and notes that there are some document nits that the IETF online idnits checker tool provides. Awaiting for a new document revision.
2006-04-04
15 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2006-03-25
15 Margaret Cullen Shepherding AD has been changed to Jari Arkko from Margaret Wasserman
2006-03-13
15 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-03-08
08 (System) New version available: draft-ietf-magma-mgmd-mib-08.txt
2005-09-13
07 (System) New version available: draft-ietf-magma-mgmd-mib-07.txt
2005-08-22
06 (System) New version available: draft-ietf-magma-mgmd-mib-06.txt
2005-07-18
05 (System) New version available: draft-ietf-magma-mgmd-mib-05.txt
2005-02-25
04 (System) New version available: draft-ietf-magma-mgmd-mib-04.txt
2004-06-23
03 (System) New version available: draft-ietf-magma-mgmd-mib-03.txt
2004-02-17
02 (System) New version available: draft-ietf-magma-mgmd-mib-02.txt
2003-10-28
01 (System) New version available: draft-ietf-magma-mgmd-mib-01.txt
2003-06-25
00 (System) New version available: draft-ietf-magma-mgmd-mib-00.txt