[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
Hi Bert and Dave,
I am trying to determine the status of
draft-ietf-ipv6-inet-tunnel-mib-01.txt. Specifically, I am trying to
determine whether it has passed MIB doctor review and is ready for
IESG review or whether it requires further changes to resolve MIB
Doctor review issues.
I have included the last message I have in this thread below, and it
appears that the MIB Doctor (Bert in this case) still has some issues
with the document. Bert and Dave , is that your understanding? Are
you planning another update to address these issues? Do you
understand what needs to change?
Dave, if my understanding of the status is correct, do you have ETA
on when a new version might be available?
Margaret
At 2:09 PM +0200 9/2/04, Wijnen, Bert (Bert) wrote:
>Dave, sorry that I had missed this one.
>I had mis-files it in another folder... oh well.
>
>Comments inline below. I cut out the things that were "done"
>and/or "fixed"
>
>Thanks, Bert
>
>
>> -----Original Message-----
>> From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
>> Sent: Friday, August 13, 2004 04:05
>> To: Wijnen, Bert (Bert); Mreview (E-mail)
>> Cc: Margaret Wasserman (E-mail)
>> Subject: 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.
>>
>It really is a CLR is it not.
>So I hope you did not take it as a MUST CHANGE request.
>But trying to be consistent is certainly good when MIB doctors
>edit/submit MIB documents.
>
>> > - 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.
>>
>I now found some of the discussions. Thanks.
>Let us take a few more days on mreview list to see if we have
>at least (rough) consensus.,
>
>> > 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
>>
>
>Mmm... I would love BOTH DESCRIPTION clauses to be updated so that the
>rules are clear. In any event, PLS DO put appropriate text in the
>new TC. Since you want it to be flexible, that should be easy and
>should not raise any controversy. In fact even if we make it
>expert review (as Juergen suggests, and I like that, and in fact for
>ifTypes we basically do some form of expert review as I once posted
>to the mreview mailing list; kzm and I do that), even then it should
>not be controversial. I even wonder if we cannot just add that to
>the ifType TC as well, because that is just documenting current pratice.
>
>> > - 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.
>>
>So we keep the TOS in the descriptor because otherwise we need to
>deprecate and define a new object. Can I suggest to add something to
>description clause aka:
>OLD:
> DESCRIPTION
> "The method used to set the high 6 bits (the
> differentiated services codepoint) of the IPv4 TOS or
> IPv6 Traffic Class in the outer IP header. A value of
> -1 indicates that the bits are copied from the
> payload's header. A value of -2 indicates that a
> traffic conditioner is invoked and more information
> may be available in a traffic conditioner MIB module.
> A value between 0 and 63 inclusive indicates that the
> bit field is set to the indicated value."
>NEW:
> DESCRIPTION
> "The method used to set the high 6 bits (the
> differentiated services codepoint (DSCP)) of the IPv4
> TOS or IPv6 Traffic Class in the outer IP header. A
> value of -1 indicates that the bits are copied from
> the payload's header. A value of -2 indicates that a
> traffic conditioner is invoked and more information
> may be available in a traffic conditioner MIB module.
> A value between 0 and 63 inclusive indicates that the
> bit field is set to the indicated value.
>
> Note: instead of the name tunnelIfTOS, a better name
> would have been tunnelIfDSCPMethod, but the current name
> was created long before the TOS byte was deprecated."
>
>> > - 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.
>>
>Aha... OK. I wondered because I was thinking of the fact that for
>ubnknown the AddressType would be different, but we have had that
>discussion and you are using 0.0.0.0 or :: for that.
>So I take it that it cannot be that one would be IPv4 and the other
>would be of unknown type or possibly IPv6?
>
>> > 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.
>>
>Right, we had that discussion earlier. And I think we have
>consensus that your interpretation was correct.
>
>> 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?
>
>Thanks for uncovering an issue that most of us missed.
>
>>
>> > - 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)
>>
>So that is in conflict with your text and COMPLIANCE which does not list
>the notInService value as a value to be supported.
>But I also believe that the result of a createAndGo cannot be a row
>that ends up being notInService. I need to check. Can you check too, pls
>
>> >
>> > 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.
>>
>
>Yeah... we have many that get exposed widely and then completely ignored.
>I do not mean this negative. I am just trying to get decent and wide
>enuf review for this MIB document.
>
>Bert