[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MIB DOctor review of: draft-ietf-ipv6-inet-tunnel-mib-01.txt

OK, I did review. 
In fact I reviewed a pre-rev02 version that already has updates 
to address review comments from Mike HEard.

Here are my (initial) findings:

- You often speak of MIB or MIBs while what you mean is
  "MIB Module". It would be good to fix that. We (or at least I) 
  as MIB doctors try to make it clear all the time that we have
  one single MIB, composed of many MIB modules.
  For example the first sentence of abstract is misleading and
  not inline with what we normaly say (i.e. "A portion of the 
  MIB". Another example "Extension MIBs". 

- Sect 3.1.1. 
  Is it always "IPv4 addresses" ? Or can it also be IPv6 addresses?

- Is it wise to put IANAtunnelType TC in IANAifType-MIB?
  Or would a different module be better.
  In any event, the DESCRIPTION clause of that TC should explain
  the rules for IANA on when/how to assign new values.
  It also seems to me that we may want to update the DESCRIPTION
  clause of the ianaIfType TC to say something about tunnels and
  that they better have tunnel(131) as ifType and a listing
  in the new TC.

-     ORGANIZATION "IETF Interfaces MIB Working Group"
  Mmm.. the work is now done in IPv6 WG, no?

-   REVISION     "200408031200Z" -- August 3, 2004
    DESCRIPTION
            "Added support for IPv6.  Published as RFC yyyy."

  This DESCRIPTION clause MUST list the changes made in this
  revision. So this is in addition to the text version in the
  document itself.

- Those objects and conformance statements that have been
  deprecated SHOULD have text in their description clauses as
  to why such is done, and which new objects are to be used.

- tunnelIfHopLimit OBJECT-TYPE
    SYNTAX     Integer32 (0..255)
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
            "The IPv4 TTL or IPv6 Hop Limit to use in the outer IP
            header.  A value of 0 indicates that the value is
            copied from the payload's header."
    ::= { tunnelIfEntry 4 }

   Possibly better to do
    SYNTAX     Integer32 (0 | 1..255)
   To show that zero is a special value

- tunnelIfTOS OBJECT-TYPE
    SYNTAX     Integer32 (-2..63)

  I keep telling other people that TOS has been deprecated/obsoleted and
  that they should use DSCP or some such. Would now not be a good time
  to try and fix that here as well?

- tunnelIfLocalInetAddress OBJECT-TYPE
    SYNTAX     InetAddress
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
            "The address of the local endpoint of the tunnel
            (i.e., the source address used in the outer IP
            header).  If the address is unknown, the value is
            0.0.0.0 for IPv4 or :: for IPv6."
    ::= { tunnelIfEntry 9 }
  
  1. According to RFC3291, you MUST state which object controls the
     format of this object. It is of course tunnelIfAddressType,
     but such should be stated.
  2. Is it ever possible that one of the addresses would be
     unknown while the other is known?
  3. According to RFC3291, if the address is unknown, then the
     value should be the zero-length octet string

- tunnelInetConfigStatus
           "The status of this row, by which new entries may be
           created, or old entries deleted from this table. The
           agent need not support setting this object to
           createAndWait or notInService since there are no other
           writable objects in this table, and writable objects
           in rows of corresponding tables such as the
           tunnelIfTable may be modified while this row is
           active.

       .. snip ..

           Creating a row in this table will cause an interface
           index to be assigned by the agent in an
           implementation-dependent manner, and corresponding
           rows will be instantiated in the ifTable and the
           tunnelIfTable.  The status of this row will become
           active as soon as the agent assigns the interface
           index, regardless of whether the interface is
           operationally up.

   So what value would this object have if not (yet) active?

- References. RFC3595 is listed as normative (which is correct),
  but there is no citation to this reference. Needs to be added.
  Pls check other references as well.
- References. You import from RFC3291, you must add it as a 
  normative reference.
- IANAifType-MIB must be in normative references.

I get the impression that this doc has not had much review before,
is that right? If so, what can we do to expose it somewhat better
so that it DOES get proper review, not only from MIB experts, but
also from IPv4/v6 and Tunneling experts?

Thanks,
Bert 

> -----Original Message-----
> From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
> Sent: woensdag 4 augustus 2004 17:47
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: RE: MIB DOctor review of:
> draft-ietf-ipv6-inet-tunnel-mib-01.txt
> 
> 
> An updated pre-02 version of the doc is at
> http://www.icir.org/dthaler/draft-ietf-ipv6-inet-tunnel-mib-02.txt
> 
> This fixes several smilint errors.
> 
> -Dave
> 
> > -----Original Message-----
> > From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]
> On
> > Behalf Of Wijnen, Bert (Bert)
> > Sent: Sunday, August 01, 2004 9:11 PM
> > To: Mreview (E-mail)
> > Subject: MIB DOctor review of: 
> draft-ietf-ipv6-inet-tunnel-mib-01.txt
> > 
> > ANy volunteer?
> > 
> > Thanks,
> > Bert
>