[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 5.1) SSH End of message directive
HI,
In protocol design, it can be difficult to figure out where
to draw the line in reporting problems in the messages. In
general, you need to make sure that reporting doesn't create
a cascading situation, but you also want to provide enough
information to determine the situation. The most important
is to return information that a user can determine that
the two ends are misconfigured, but you don't want to
return information that is only useful for the protocol
coders. For "bugs" in coding, this needs to be noted
in instrumentation for the protocol that can be retrieved
locally and by a management protocol, but not reported
if this will lead to a cascade of reports.
So, I agree with that approach that Phil recommends below.
On Thu, 11 Dec 2003, Phil Shafer wrote:
> Mark Stahl writes:
> >If the whole session is one document, a syntax error in one message would
> >require abandoning the session to reset the parser.
>
> Yup.
>
> >How does the NetConf spec address syntax errors in the message stream?
>
> An error in the content should cause an error message to be generated.
> The client and server should be able to recover. An error in the
> protocol or the framing should cause the connection to be dropped,
> since you can't guarantee recovery.
>
> Thanks,
> Phil
Regards,
/david t. perkins
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>