[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
Thanks Bert!
An updated document has been submitted to the I-D repository.
It can also be found immediately at
http://www.icir.org/dthaler/draft-ietf-ipv6-inet-tunnel-mib-02.txt
See below for detailed responses, especially the zero-length octet
string discussion.
-Dave
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Tuesday, August 10, 2004 6:13 AM
> To: Dave Thaler; Mreview (E-mail)
> Cc: Margaret Wasserman (E-mail)
> Subject: 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".
Updated.
Would be good to mention this in the Guidelines. Looking at
recent RFCs, even with documents that do use "MIB module" in the text,
they still have a title which implies it's a MIB in itself.
(RFC 3747, RFC 3729, RFC 3621, etc.) One could even argue that
the XXX-MIB naming convention is troublesome, although it's
probably not worth changing that.
> - Sect 3.1.1.
> Is it always "IPv4 addresses" ? Or can it also be IPv6 addresses?
Fixed.
> - Is it wise to put IANAtunnelType TC in IANAifType-MIB?
> Or would a different module be better.
This was discussed (including on the mreview list), and
the rationale for the same module was specifically to avoid the
problem of people not seeing it and asking for an ifType when a
tunnel type is more appropriate.
> In any event, the DESCRIPTION clause of that TC should explain
> the rules for IANA on when/how to assign new values.
This was also discussed. The IANA-ifType does not do this now,
and the recommendation was to mimic ifType and then fix them
both via some action like another document.
See bottom of
http://ops.ietf.org/lists/mreview/mreview.2003/msg00632.html
> 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?
Yes, although the reviews were really more from the IF-MIB people, but
since that WG has closed the IPv6 WG hosted it in name. I've changed it
now anyway.
> - 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.
Done.
> - 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.
Done (most objects already pointed to the new objects in the
description clause... explicitly stated this is for IPv6 and
also did the same for conformance statements).
> - 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
Done.
> - 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?
In fact this object does really reflect the DSCP bits (that's why it's a
6-bit number and not an 8-bit number). Added note to the DESCRIPTION to
clarify.
> - 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.
Done.
> 2. Is it ever possible that one of the addresses would be
> unknown while the other is known?
Yes. For some tunnel types (e.g. 6to4), this is the normal case.
> 3. According to RFC3291, if the address is unknown, then the
> value should be the zero-length octet string
My reading of 3291 is that the zero-length octet string is only used if
the InetAddressType is unknown. If the type is known to be IPv4 or
IPv6, then the zero-length octet string is not used. This is
the case here.
Now it's possible my interpretation is incorrect. The new UDP MIB says,
for a similar case (and the TCP MIB has similar text):
an application which is willing to accept only IPv4
or only IPv6 datagrams is represented by a
udpEndpointLocalAddressType of the appropriate
address type, and udpEndpointLocalAddress of ''h (a
zero-length octet-string).
However, from RFC 3291 (unchanged in draft-ietf-ops-rfc3291bis-05.txt),
the definition of the InetAddressType says
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) A global IPv6 address as defined by the
InetAddressIPv6 textual convention.
And the SYNTAX clauses of those are:
InetAddressIPv4 ::= TEXTUAL-CONVENTION
SYNTAX OCTET STRING (SIZE (4))
InetAddressIPv6 ::= TEXTUAL-CONVENTION
SYNTAX OCTET STRING (SIZE (16))
Since the 0-length string is not legal in those SYNTAX clauses,
my reading is that the UDP-MIB (which is in IETF last call)
and TCP-MIB (which is in the RFC editors queue)
interpretation is not legal, and the existing TUNNEL-MIB
interpretation is correct.
Or am I missing something?
> - 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?
notInService (notReady means the agent does not have all the required
configuration information, which as noted in the DESCRIPTION above,
is never the case)
> - 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.
Done.
> - References. You import from RFC3291, you must add it as a
> normative reference.
Done.
> - 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?
It has been discussed on the IPv6 WG list, the IF-MIB WG list, and the
Mreview list. So while only a small number of people have actually
participated in the discussions, the requests for review have been
exposed widely.
Thanks,
-Dave
> 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
> >