IP Tunnel MIB
draft-ietf-ipv6-inet-tunnel-mib-03

Correspondence with author regarding IANA issues (now resolved?):

Subject: RE: Question:
From: "Dave Thaler"
To: "Michelle S. Cotton"
Cc: "Thomas Narten" ,
...snip...Haberman"

> -----Original Message-----
> From: Margaret Wasserman [mailto:margaret@thingmagic.com]
> Sent: Thursday, October 28, 2004 2:05 PM
...snip...
>... ietf-ipv6-inet-tunnel-mib-03.txt>
>
>
> Hi Dave,
>
> Could you respond to the attached IANA questions from Michelle Cotton?

Sure, see below.

> Thanks,
> Margaret
>
> >From: "Michelle S. Cotton"
> >To: "Margaret Wasserman"
...snip...
> >I understand the IANA Considerations correctly?
> >
> >We will be adding a new MIB to the IANA regsitries
> >for IANAtunnel Type TC.

No, a new TC would be added into the existing MIB module,
it's not a new MIB module.

> >I don't quite understand the first sentence of the IANA
> >Considerations section makes it seem that I need to
> >CHANGE the IANAifType-MIB in some way???

Yes.  The IANAtunnelType TC would be added into the
http://www.iana.org/assignments/ianaiftype-mib
page.  This would be done by taking the TC text defined
in the doc, and inserting it into the page just before
the END line that's already there  (and then near the top
adding a new REVISION, DESCRIPTION pair as has been done
many times in the past).

> >Currently the IANAifTypes are reviewed by experts.  Just
> >making sure that was still OK as it says to use the same
> >for IANAtunnelType values.
> >
> >Deprecate IANAifType value 215.
> >
> >Bert helps me with the IANAifTypes so has he also reviewed
> >this one?

Bert has been involved in the review of this document yes.

-Dave
From: "Wijnen, Bert (Bert)"
To: "'Dave Thaler'"
Cc: Thomas Narten ,
...snip...
Subject: RE: Question:

So...

1. Yes I have seen the IANA considerations and the impact on
  the IANAifType-MIB.
  In fact I also discussed these with the MIB doctors, and
  I believe we have indeed consensus to do it the way as
  described in teh draft, otherwise I would not have
  posted a YES position in the ID tracker.

2. I propose that we add Dave Thaler to the team of experts
  (currently Keith McCloghire and myself) to review requests
  for new assignments. Specifically, because some requests may
  actually need to be changed to requests for assignments in this
  new TC. Dave... OK ?

3. Michell, if you want, I can pick up the current IANAifType-MIB
  and make the change for you. Or I an do so at the time when you
  are ready to actually make the assignment (for example, right after
  the IESG sends the approval announcement or so). Just if that
  helps. I can also check it for you when you are done.
  We better make sure that the updated MIB module does compile
  without SYNTAX errors.

Hope this helps,
Bert

Passed IANA question on to author:

To: dthaler@microsoft.com
From: Margaret Wasserman
Subject: Fwd: Question:
Cc: Thomas Narten

Hi Dave,

Could you respond to the attached IANA questions from Michelle Cotton?

Thanks,
Margaret

>From: "Michelle S. Cotton"
>To: "Margaret Wasserman"
>Date: Thu, 28 Oct 2004 08:23:55 -0700
>X-Priority: 3 (Normal)
>Importance: Normal
>X-Spam-Score: 0.0 (/)
>X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
>Cc: iana@iana.org, iesg@ietf.org
>Subject: Question:
>X-BeenThere: iesg@ietf.org
>X-Mailman-Version: 2.1.5
>List-Id: iesg.ietf.org
>List-Unsubscribe: ,
>
>List-Post:
>List-Help:
>List-Subscribe: ,
>
>Sender: iesg-bounces@ietf.org
>X-Spam: [F=0.0004079551; rbl=0.500(0); rep=0.010(s294/n35688); heur=0.500(-5800); stat=0.010; spamtraq-heur=0.800(2004102806)]
>X-MAIL-FROM:
>X-SOURCE-IP: [132.151.6.71]
>
>Margaret,
>
>For , do
>I understand the IANA Considerations correctly?
>
>We will be adding a new MIB to the IANA regsitries
>for IANAtunnel Type TC.
>
>I don't quite understand the first sentence of the IANA
>Considerations section makes it seem that I need to
>CHANGE the IANAifType-MIB in some way???
>
>Currently the IANAifTypes are reviewed by experts.  Just
>making sure that was still OK as it says to use the same
>for IANAtunnelType values.
>
>Deprecate IANAifType value 215.
>
>Bert helps me with the IANAifTypes so has he also reviewed
>this one?
>
>Thanks,
>
>Michelle
>
>
>5.  IANA Considerations
>
>This document introduces a new IANA-maintained textual convention
>(TC) which is to be added to the IANAifType-MIB [IFTYPE].  The
>initial version of this IANAtunnelType TC can be found in Appendix
>A.  The current version of the textual convention can be accessed
>at http://www.iana.org/assignments/ianaiftype-mib
>
>The assignment policy for IANAtunnelType values should always be
>identical to the policy for assigning IANAifType values.
>
>New types of tunnels over IPv4 or IPv6 should not be assigned
>IANAifType values.  Instead, they should be assigned
>IANAtunnelType values and hence reuse the interface type
>tunnel(131).  (Note this restriction does not apply to "tunnels"
>which are not over IPv4 or IPv6.)
>
>Previously tunnel types which were not point-to-point tunnels were
>problematic in that they could not be properly expressed in the
>tunnel MIB, and hence were assigned IANAifType values.  This
>document now corrects this problem, and as a result, IANA should
>deprecate the sixToFour(215) IANAifType value in favor of the
>sixToFour(11) IANAtunnelType value.
>

IANA Comments:
For , do
I understand the IANA Considerations correctly?

We will be adding a new MIB to the IANA regsitries
for IANAtunnel Type TC.

I don't quite understand the first sentence of the IANA
Considerations section makes it seem that I need to
CHANGE the IANAifType-MIB in some way???

Currently the IANAifTypes are reviewed by experts.  Just
making sure that was still OK as it says to use the same
for IANAtunnelType values.

Deprecate IANAifType value 215.

[Ballot comment]
Being sensitive to discussions of the TOS/DSCP material as TSV folks tend to,
I noticed a nit:

            Note: instead of the name tunnelIfTOS, a better name
            would have been tunnelIfDSCPMethod, but the existing
            name appeared in RFC 2776 and existing objects cannot
            be renamed.

RFC 2776 is not where this is (nor is it in the references).  ??

[Ballot comment]
As usual, being sensitive to discussions of the TOS/DSCP material, I noticed a nit:

            Note: instead of the name tunnelIfTOS, a better name
            would have been tunnelIfDSCPMethod, but the existing
            name appeared in RFC 2776 and existing objects cannot
            be renamed.

RFC 2776 is not where this is (nor is it in the references).  ??

[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

His review:



This draft is ready for publication as a Proposed Standard.

nit: There is no table of contents.

Sent request for status clarification to Dave Thaler and Bert Wijnen:

To: "Wijnen, Bert (Bert)" , Dave Thaler , "Mreview (E-mail)"
From: Margaret Wasserman
Subject: RE: MIB DOctor review of: draft-ietf-ipv6-inet-tunnel-mib-01.txt
Cc:
Bcc:
X-Attachments:


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

Bert's initial review comments (from 10-Aug-2004):

From: "Wijnen, Bert (Bert)"
To: "'Dave Thaler'"
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".

- 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

Bert's initial review comments (from 10-Aug-2004):

From: "Wijnen, Bert (Bert)"
To: "'Dave Thaler'"
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".

- 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

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?

This document received reviews from several members of the IPv6
WG as well as a review on the ipv6mib mailing list.

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.)?

No concerns.

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.

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 support within the IPv6 WG is limited to those people who are
experts or have a vested interest in MIBs.  The remainder of the
group is silent on the document.  It should be noted that there is
apparent broad support on the ipv6mib mailing list.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

The chairs are unaware of any appeals in the works or of any
serious discontent.

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

Yes.

- Technical Summary

This memo defines a Management Information Base (MIB) for use with
network management protocols in the Internet community.  In
particular, it describes managed objects used for managing tunnels
of any type over IPv4 and IPv6 networks.  Extension MIBs may be
designed for managing protocol-specific objects. Likewise,
extension MIBs may be designed for managing security-specific
objects.  This MIB does not support tunnels over non-IP networks.
Management of such tunnels may be supported by other MIBs.

- Working Group Summary

The IPv6 working group has reviewed this document and
this document reflects the consensus of the group.

- Protocol Quality

This document has been reviewed by members of the ipv6@ietf.org
mailing list, the IPv6 working group chairs, and members of the
ipv6mib mailing list.