Subject: RE: MADCAP error codes/messages

From: Munil Shah <[email-masked]>
Date: Wed, 21 Apr 1999 14:05:24 -0700

I think the major point for adding the error code would be to shorten the
retransmission path of the client. If a server does not provide an error
code to a client then the client may continue to send bogus requests(e.g
invalid scope which may have been in the client cache but no longer
available on the network) to one server after another. This could add
unnecessary delay on the failure path and does not really help recovery from
it.

 You don't really want to report all the soft errors(e.g server too busy or
may be out of resources temporarily). But for hard errors (e.g invalid
scope) if server can provide more information then just the NAK then the
client can revise its request before  retransmitting to the same server or a
different server.

However, I don't think this is super critical at this time.  Maybe we can
just have a separate draft to define better reporting mechanism.  I think
after a little bit of real world experience with this protocol we may have a
better idea of what sort of errors we might be interested in reporting back
to the client.  The interaction with AAP may also help us identify more
error conditions we would like to report. 

I do not feel so strongly about the error message option though.  We have
had a similar option in DHCP and it has been of little use especially
because there is no support for internationalization.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]]
Sent: Thursday, April 15, 1999 8:23 AM
To: malloc
Subject: MADCAP error codes/messages

During the IETF Last Call on MADCAP, a suggestion has been made that we
add an error code and/or error message option that would allow servers
to respond with an error instead of just ignoring the packet that caused
the error. To avoid implosion, servers would not send error responses to
multicast messages unless the Server ID matched their own.

The arguments in favor of including error codes/messages are:

* makes debugging easier
* allows for better error messages
* avoids pointless retransmissions by client

The arguments against are:

* no address available is handled by NAK. Other errors are rare.
* adds complexity to protocol with little real-world benefit
* textual error messages have internationalization problems

I would like to solicit feedback from the list. What do you think?
Should we add a numeric error code option to MADCAP? What about a
textual error message option?

Thanks,

Steve

---

From: Steve Hanna <[email-masked]>
Date: Fri, 23 Apr 1999 09:10:46 -0400

Munil Shah wrote:
> after a little bit of real world experience with this protocol we may have
> a better idea of what sort of errors we might be interested in reporting
> back to the client.  The interaction with AAP may also help us identify
> more error conditions we would like to report.

There are probably a few error codes that we could agree on now, like
clock skew too great or malformed packets. Error code is a pretty basic
thing, so maybe we should define the option and a few values now, then
add other values later.

Also, this raises a related issue. Currently, the MADCAP spec requires
the server to ignore many kinds of messages: INFORM messages that can't
be handled, RELEASE and RENEW messages with an invalid Client ID,
messages that contain a Feature List option unsupported features,
malformed packets (too short, unsupported version, unrecognized message
type, same option appears more than once, no End option, etc.), messages
with bad option values (like min lease time > lease time), and messages
with excess clock skew. I would suggest changing the spec to say the
server SHOULD NAK these, as long as they were received via unicast or
via multicast with the Server ID matching this server. That will help
the client stop misbehaving.

> because there is no support for internationalization.

That's fine with me. We can add this later if we want to.

-Steve