Management Information Base for the User Datagram Protocol (UDP)
draft-ietf-ipv6-rfc2013-update-04

Author response to IANA questions:

To: margaret@thingmagic.com
Subject: Re: Fwd: RE: Evaluation: draft-ietf-ipv6-rfc2013-update-04.txt to  ProposedStandard
Cc: john.flick@hp.com, narten@us...snip...cotton@icann.org,
iana@iana.org
From: Bill Fenner


>Do we need to change the references for those mib-2 values
>or do they remain the same?

The references for {mib-2 7} and {mib-2 50} should be updated to this spec,
yup.  I don't think there are any other IANA actions.

  Bill

Author response to IANA questions:

To: margaret@thingmagic.com
Subject: Re: Fwd: RE: Evaluation: draft-ietf-ipv6-rfc2013-update-04.txt to  ProposedStandard
Cc: john.flick@hp.com, narten@us...snip...cotton@icann.org,
iana@iana.org
From: Bill Fenner


>Do we need to change the references for those mib-2 values
>or do they remain the same?

The references for {mib-2 7} and {mib-2 50} should be updated to this spec,
yup.  I don't think there are any other IANA actions.

  Bill

Author response to IANA questions:

To: margaret@thingmagic.com
Subject: Re: Fwd: RE: Evaluation: draft-ietf-ipv6-rfc2013-update-04.txt to  ProposedStandard
Cc: john.flick@hp.com, narten@us...snip...cotton@icann.org,
iana@iana.org
From: Bill Fenner


>Do we need to change the references for those mib-2 values
>or do they remain the same?

The references for {mib-2 7} and {mib-2 50} should be updated to this spec,
yup.  I don't think there are any other IANA actions.

  Bill

Sent IANA questions to authors:

To: john.flick@hp.com, fenner@research.att.com
From: Margaret Wasserman
Subject: Fwd: RE: Evaluation: draft-ietf-ipv6-rfc2013-update-04.txt to ProposedStandard
Cc: Thomas Narten From: "Michelle S. Cotton"
>To:
>Date: Thu, 28 Oct 2004 08:31:34 -0700
>X-Priority: 3 (Normal)
>Importance: Normal
>X-Spam-Score: 0.0 (/)
>X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
>Cc: iana@iana.org
>Subject: RE: Evaluation: draft-ietf-ipv6-rfc2013-update-04.txt to
> ProposedStandard
>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.0004985666; rbl=0.500(0); rep=0.010(s294/n35688); heur=0.500(-12200); stat=0.010; spamtraq-heur=0.830(2004102806)]
>X-MAIL-FROM:
>X-SOURCE-IP: [132.151.6.71]
>
>IANA has a question.
>Do we need to change the references for those mib-2 values
>or do they remain the same?
>
>Other than that I understand there to be no other IANA Actions.
>Correct?
>
>Michelle
>IANA

IANA Comments:
Do we need to change the references for those mib-2 values
or do they remain the same?

Other than that I understand there to be no other IANA Actions.
Correct?

Follow-up message sent to  authors:

Hi Bill and John,

According to my records, draft-ietf-ipv6-rfc2013-update-03.txt has been waiting for about a month for an update to address Mike Heard's IETF Last Call issues that were discovered when he reviewed the Tunnel MIB (see messages below).

Do you understand his comments, and is an update underway?  If not, what questions do you have and how can we resolve this issue and get this document into the IESG?

Thanks,
Margaret

From: "C. M. Heard"
To: "Mreview (E-mail)"
cc: "Wijnen, Bert (Bert)"
Subject: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of:
draft-ietf-ipv6-inet-tunnel-mib-01.txt)

On Thu, 12 Aug 2004, Dave Thaler wrote:
> >  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.

http://www1.ietf.org/internet-drafts/draft-ietf-ops-rfc3291bis-05.txt
says something a little bit different -- an InetAddressType object
must assume the value unknown(0) if the corresponding InetAddress
object has zero length, but the reverse is not necessarily true,
per the following excerpt from the InetAddressType DESCRIPTION clause:

  unknown(0)  An unknown address type. This value MUST
              be used if the value of the corresponding
              InetAddress object is a zero-length string.
              It may also be used to indicate an IP address
              which is not in one of the formats defined
              below.

> If the type is known to be IPv4 or IPv6, then the zero-length
> octet string is not used.

That, however, is certainly true.

> [... ] The new UDP MIB says [ ... ] (and the TCP MIB has
> similar text):
>      an application which is willing to accept only IPv4
...snip...
> interpretation is not legal, and the existing TUNNEL-MIB
> interpretation is correct.
>
> Or am I missing something?

IMHO, you are not.  I think that both of those documents need to be
corrected.  Fortunately, they are both blocked waiting for 3291bis,
since it is a normative reference in both.

I guess we would be covered by a Last Call comment on the UDP-MIB,
but we will have to ask for help from Bert and Margaret for the
TCP-MIB.

Mike

---

From: "C. M. Heard"
To: "Wijnen, Bert (Bert)"
cc: "Mreview (E-mail)" ,
...snip...Raghunarayan
Subject: RE: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of:
draft-ietf-ipv6-inet-tunnel-mib-01.txt)

Bert,

In the case of the UDP MIB it should not be necessary to make the
corrections in AUTH48 because draft-ietf-ipv6-rfc2013-update-03.txt
is still in last call.  It is necessary to do any corrections to the
TCP MIB in that way since draft-ietf-ipv6-rfc2012-update-06.txt was
already approved.

I've cc:'d the document authors since they are probably in the best
position to evaluate the impact of the required changes.  For their
benefit, the issue is that RFC3291bis does not permit using a
zero-length octet string for an InetAddress object when the
corresponding InetAddressType object has a value other than
unknown(0), but both of those MIB modules use that combination to
indicate an IPv4 or IPv6 wildcard address.  There are more details
in the discussion below.

For IPv4 the problem could be solved by using the all-zeroes
address;  that indeed is what the older IPv4-specific modules did.
However, I don't know enough about IPv6 to know if that would be a
viable solution for that case.

Mike Heard
On Thu, 19 Aug 2004, Wijnen, Bert (Bert) wrote:
> It would be good to prepare the fix to UDP and TCP MIB documents
> in the form of RFC-Editor instructions aka
>
> - on page x pls change
...snip...
> > but we will have to ask for help from Bert and Margaret for the
> > TCP-MIB.
> >
> > Mike
> >
> >
> >
>

Follow-up message sent to  authors:

Hi Bill and John,

According to my records, draft-ietf-ipv6-rfc2013-update-03.txt has been waiting for about a month for an update to address Mike Heard's IETF Last Call issues that were discovered when he reviewed the Tunnel MIB (see messages below).

Do you understand his comments, and is an update underway?  If not, what questions do you have and how can we resolve this issue and get this document into the IESG?

Thanks,
Margaret

From: "C. M. Heard"
To: "Mreview (E-mail)"
cc: "Wijnen, Bert (Bert)"
Subject: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of:
draft-ietf-ipv6-inet-tunnel-mib-01.txt)

On Thu, 12 Aug 2004, Dave Thaler wrote:
> >  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.

http://www1.ietf.org/internet-drafts/draft-ietf-ops-rfc3291bis-05.txt
says something a little bit different -- an InetAddressType object
must assume the value unknown(0) if the corresponding InetAddress
object has zero length, but the reverse is not necessarily true,
per the following excerpt from the InetAddressType DESCRIPTION clause:

  unknown(0)  An unknown address type. This value MUST
              be used if the value of the corresponding
              InetAddress object is a zero-length string.
              It may also be used to indicate an IP address
              which is not in one of the formats defined
              below.

> If the type is known to be IPv4 or IPv6, then the zero-length
> octet string is not used.

That, however, is certainly true.

> [... ] The new UDP MIB says [ ... ] (and the TCP MIB has
> similar text):
>      an application which is willing to accept only IPv4
...snip...
> interpretation is not legal, and the existing TUNNEL-MIB
> interpretation is correct.
>
> Or am I missing something?

IMHO, you are not.  I think that both of those documents need to be
corrected.  Fortunately, they are both blocked waiting for 3291bis,
since it is a normative reference in both.

I guess we would be covered by a Last Call comment on the UDP-MIB,
but we will have to ask for help from Bert and Margaret for the
TCP-MIB.

Mike

---

From: "C. M. Heard"
To: "Wijnen, Bert (Bert)"
cc: "Mreview (E-mail)" ,
...snip...Raghunarayan
Subject: RE: Bugs in UDP-MIB and TCP-MIB (was: RE: MIB DOctor review of:
draft-ietf-ipv6-inet-tunnel-mib-01.txt)

Bert,

In the case of the UDP MIB it should not be necessary to make the
corrections in AUTH48 because draft-ietf-ipv6-rfc2013-update-03.txt
is still in last call.  It is necessary to do any corrections to the
TCP MIB in that way since draft-ietf-ipv6-rfc2012-update-06.txt was
already approved.

I've cc:'d the document authors since they are probably in the best
position to evaluate the impact of the required changes.  For their
benefit, the issue is that RFC3291bis does not permit using a
zero-length octet string for an InetAddress object when the
corresponding InetAddressType object has a value other than
unknown(0), but both of those MIB modules use that combination to
indicate an IPv4 or IPv6 wildcard address.  There are more details
in the discussion below.

For IPv4 the problem could be solved by using the all-zeroes
address;  that indeed is what the older IPv4-specific modules did.
However, I don't know enough about IPv6 to know if that would be a
viable solution for that case.

Mike Heard
On Thu, 19 Aug 2004, Wijnen, Bert (Bert) wrote:
> It would be good to prepare the fix to UDP and TCP MIB documents
> in the form of RFC-Editor instructions aka
>
> - on page x pls change
...snip...
> > but we will have to ask for help from Bert and Margaret for the
> > TCP-MIB.
> >
> > Mike
> >
> >
> >
>

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 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 portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes managed objects used for implementations
  of the User Datagram Protocol (UDP) in an IP version independent
  manner.  This memo obsoletes RFCs 2013 and 2454.

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

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.