Subject: Re: RFC 2925 (disman remote operations) Implementation Experience

From: Randy Presuhn <[email-masked]>
Date: Tue, 6 Nov 2001 18:08:52 -0800 (PST)

Hi -

> Date: Fri, 2 Nov 2001 11:34:18 +0100
> Message-Id: <[email-masked]>
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> In-reply-to: <[email-masked]> (message from Randy
> 	Presuhn on Thu, 1 Nov 2001 14:51:31 -0800 (PST))
> Subject: Re: RFC 2925 (disman remote operations) Implementation Experience
> References:  <[email-masked]>
...
> Randy> What do we need to do to satisfy the IPv6 folk?
> 
> The text in question gives a reasoning for the upper size limit.  An
> IPv6 header is at least 40 bytes (if I understand RFC 2460 correctly).
> So far we are fine. But wait:
> 
> The IPv4 header contains a "total length" field which is 16 bit while
> the IPv6 header contains a "payload length" field which is 16 bit. RFC
> 2460 says:
> 
>    Payload Length       16-bit unsigned integer.  Length of the IPv6
>                         payload, i.e., the rest of the packet following
>                         this IPv6 header, in octets.  (Note that any
>                         extension headers [section 4] present are
>                         considered part of the payload, i.e., included
>                         in the length count.)
> 
> So the IPv6 header is not really included and it might be possible to
> IPv6 packets which have 65535 octets in the payload. If this is
> indeedt true, then the upper size should actually be 65535 minus the
> UDP header size for the two objects.
> 
> The other option would be to just use 65535 as the upper bound and to
> say in the DESCRIPTION how implementations should react if they do not
> support a given size. This gets us out of the byte counting trouble
> and I guess that some implementations will have their own constraints
> and not support the full theoretical range anyway.
...

As a technical contributor, I prefer the second option.
As WG chair, I'd like to ask whether there are any other
opinions on this topic.

Ken White, could you submit an updated draft as
<draft-ietf-disman-remops-mib-v2-00.txt>?

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Wed, 7 Nov 2001 08:13:35 -0600

>> and not support the full theoretical range anyway.

This approach seems to be more practical and easier to deal with at the
implementation stage.

Thanks,
--Gene

Eugene Golovinsky
BMC Software, Inc.
Networking Group.

[email-masked]
Voice +(713)-9181816
Mobile +(713)-8598281