Subject: RE: Help! Static route option

From: Eric Michelsen <[email-masked]>
Date: Fri, 28 Jan 2000 15:30:45 -0800

Well, I respectfully disagree.  There is a right thing, and it is clearly
for the client to use the class-ful mask, as is done in similar situations
such as RIPv1.  In fact, that seems so clear to me, that it hardly needs
clarification.  

>From the original request, something that is slightly less clear is: what if
the destination includes host-bits in the classfull destination IP address?
I think the obvious thing to do is interpret this as a host route.  

If the class-ful interpretation is inadequate for the job, an installation
will have to use another method than DHCP.  

There is no harm in adding clarity to an option.  If you don't like the
option, you don't have to use or support it.
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks 

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Friday, January 28, 2000 14:05
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Help! Static route option 
> 
> 
> 
> > I guess I'm lost.  If the behavior of the client is already 
> well defined,
> > then what is the issue being debated right now?  Here's the 
> original email
> > that started this thread:
> 
> Right, MacOS is doing something that is clearly the wrong thing.
> But it doesn't matter, because really there _is_ no right thing.
> There is a cost associated with pushing through new drafts.   The
> default routes option is defined to do a particular thing which is not
> useful.   If we define some new behaviour for it, that doesn't solve
> anything, because somebody might continue to use the old behaviour.
> So it's not worth the effort to push through a new draft "clarifying"
> the old option - it would not do any good.
> 
> 			       _MelloN_
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jan 2000 18:44:23 -0500

> There is a right thing, and it is clearly

I agree completely with this, except that the right thing in this case
simply isn't very useful.

> option, you don't have to use or support it.

I think it would be fine, next time we rev rfc2132, to cross-reference
with RFC791 and RFC950 to indicate what network masks to use with this
option.   I just don't think we should go to any extra effort prior to
revising rfc2132, if and when that happens.

I think I've been responding in an unhelpful way on this, because I
thought you were proposing that we specify *new* behaviour, rather
than clarifying the existing, intended behaviour.   Sorry about that.
:'{

			       _MelloN_