Subject: Re: [Disman] RFC 2595: pingCtlDataSize

From: Juergen Quittek <[email-masked]>
Date: Wed, 18 Jun 2003 10:35:42 +0200

Hi Randy,

-- Randy Presuhn wrote on 26 March 2003 10:45 -0800:

> Hi -
>
> This is action item #10 from the minutes of our session in
> San Francisco.
>
> Currently, RFC 2925 says:
>  pingCtlDataSize OBJECT-TYPE
>     SYNTAX      Unsigned32 (0..65507)
>     UNITS       "octets"
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "Specifies the size of the data portion to be
>         transmitted in a ping operation in octets.  A ping
>         request is usually an ICMP message encoded
>         into an IP packet.  An IP packet has a maximum size
>         of 65535 octets.  Subtracting the size of the ICMP
>         or UDP header (both 8 octets) and the size of the IP
>         header (20 octets) yields a maximum size of 65507
>         octets."
>     DEFVAL { 0 }
>     ::= { pingCtlEntry 5 }
>
> This has caused some concern that the MIB isn't right for
> IPv6.  As a technical contributor, I'd like to propose the
> following as a clarification, and would selcome feedback,
> especially from those who have implemented this in IPv6
> environments:
>
>     DESCRIPTION
>         "Specifies the size of the data portion to be
>         transmitted in a ping operation in octets.  A ping
>         request is usually an ICMP message encoded
>         into an IP packet.  An IPv4 packet has a maximum size
>         of 65535 octets.  Subtracting the size of the ICMP
>         or UDP header (both 8 octets) and the size of the IP
>         header (20 octets) yields a maximum size of 65507
>         octets for IPv4 environments.  If the protocol
>         implied by the value of pingCtlTargetAddressType
>         further limits the size of the data portion, the
>         data is silently truncated to meet those constraints,
>         without affecting the value reported by this object."

Your phrasing is still focussed on IPv4. What about the following?

    DESCRIPTION
        "Specifies the size of the data portion to be
        transmitted in a ping operation in octets.  Whether or
        not this value can be applied depends on the selected
        implementation method for performing a ping operation
        indicated by pingCtlType in the same conceptual row.
        If the used method allows to apply the value contained
        in this object, than it MUST be applied.  Otherwise,
        other data sizes can be chosen for the ping request.

        The maximum value for this object was computed by
        substracting the smallest possible IP header size of
        20 octets (IPv4 header with no options) and the UDP
        header size of 8 octets from the maximum IP packet size.
        An IP packet has a maximum size of 65535 octets
        (excluding IPv6 Jumbograms)."

Cheers,

    Juergen

>
> Again, since I haven't implemented this, I'd really welcome
> feedback on this proposal from those who have.
>
> Randy Presuhn
>
>
>
>
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 18 Jun 2003 10:35:42 +0200

Hi Randy,

    DESCRIPTION

Cheers,

    Juergen

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 19 Jun 2003 10:12:22 -0700

Hi -

> From: "Juergen Quittek" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Disman (E-mail)" <[email-masked]>
> Sent: Wednesday, June 18, 2003 1:35 AM
> Subject: Re: [Disman] RFC 2595: pingCtlDataSize
...
>         other data sizes can be chosen for the ping request.

I think the sentence beginning with "otherwise" is too vague.
It's not clear who would do the chosing of those "other data
sizes."  Perhaps we could say something like

    If the specified size is not appropriate for the chosen ping
    method, the implementation SHOULD use whatever
    size (appropriate to the method) is closest to the specified size.

>         (excluding IPv6 Jumbograms)."
...

I have no problem with this.  Others?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 19 Jun 2003 10:12:22 -0700

Hi -

...

...

Randy

---

From: "Dale Francisco" <[email-masked]>
Date: Thu, 19 Jun 2003 10:41:11 -0700

A stylistic quibble:  How about replacing
this sentence

> If the used method allows to apply the value contained
         ^^^^^^^^^^^        ^^^^^^^^
> in this object, than it MUST be applied.
                  ^^^^

with this one:

  If the method used allows applying the value contained
  in this object, then it MUST be applied.

---

From: "Dale Francisco" <[email-masked]>
Date: Thu, 19 Jun 2003 10:41:11 -0700

^^^^^^^^^^^        ^^^^^^^^
                  ^^^^

with this one:

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 19 Jun 2003 10:37:11 -0700

Hi -

> From: "Dale Francisco" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Thursday, June 19, 2003 10:41 AM
> Subject: RE: [Disman] RFC 2595: pingCtlDataSize
>

> > If the used method allows to apply the value contained

Looks good to me.  My only concern (and this might be
over-engineering) is that it needs to be clear is that the
limitation needs to be inherent to the ping method, and
not not just an implementor's whims.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 19 Jun 2003 10:37:11 -0700

Hi -

Randy

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 19 Jun 2003 20:00:43 +0200

Randy,

>     size (appropriate to the method) is closest to the specified size.

I agree. This wording is stronger, because it recommends to take the
closest sizes.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 19 Jun 2003 20:00:43 +0200

Randy,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 19 Jun 2003 20:05:19 +0200

Randy,

> not not just an implementor's whims.

I like Dale's suggestion. I think the wording you suggested
for the case that the value cannot be applied makes it
(almost completely) clear that a limitation of the method
is addressed:

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 19 Jun 2003 20:05:19 +0200

Randy,

    Juergen