[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 5.1) SSH End of message directive
Title: Message
I was
not talking about BEEP, I was talking about plain ASCII based "transports" like
SSH.
Using
NetConf as formal CLI/macro-language over such transports.
The
cut&paste requirement, I assume, is just a way of expressing an easy way to
create
macros
the way people are used to do it now (CLI/Expect but with a more formalized
language that
NetConf provides) so a GUI would not help much here. A BEEP based
SSH/shell (!) that Expect
could
interact with would. Possibly some scripting-language binding for
BEEP would help too
but I
suspect there is a fear out there to be bound to such an
implementation.
By the
way, I'm not advocating this, I'm just trying to interpret from afar what I'm
seeing in the
NetConf discussions. The use I'm looking for in NetConf
myself is more that of a full management protocol
(as I
indicated in the PS, my preference is towards byte-lenght encoding for that
purpose).
I now
see NetConf as evolving into two heads/forms; 1) as a macro language with an SSH
transport (an XML based
CLI?), and, 2) as a full
featured Network Management protocol (24/7 use) where a true framed/protocol
transport like BEEP is much better suited.
My
first reading of the protocol was the latter.
In
trying to figure out a half way in between the two, I did explore plain
text framing schemes.
The
one that seemed interesting to me was to use MIME headers like some of the
SIP
protocols do. Combine that with a byte-length field (not unlike
latest HTTP supports) and
you
have a possible/optional framing scheme transported as plain text over
SSH/Telnet.
(which
could then allow for notifications and concurrent commands).
That
could be a third option though it is still more complex than those looking for a
macro language
would
be ready to live with I guess. It's an alternative to using a more
advanced protocol like
BEEP
(where the multi-threading and issues being discussed in the beepcore-C lists
worry me somewhat).
Again,
I'm sorry if I'm rehashing stuff that's already been
discussed...:-(
Thanks
HI,
Ed, you are not correct on your PS
with BEEP. Since with BEEP,
it chunks (segments) the message, you do not
need to build a complete
message before starting to send. The BEEP layer
does the chunking
both on input and output for you. You just write or read
a stream
of octets. Of course, having a person doing the chunking is
not
fun. However, marshall rose wrote a gui app in which you type or
paste
text and it does the BEEP work for you. (I don't know the
status
of the gui app.)
At 09:15 AM 2/20/2004 -0500, Gilbert
Gagnon wrote:
Hello,
It may be just a bit overkill but it might be a good
idea to suggest a
common escaping for cases within
the CDATA block (e.g. user the </%gt;
entities even though they are within an escaped block). The
rationale is that
since mixed contents (tags and
plain text values) is discourage (I like that)
it
would be difficult to put some CDATA stuff, then close this to put the
EOM with entities outside of the block, then open up
another CDATA block
to complete the text value that
was originally intended.
Again, it might be a
bit beyond the essential but it does not sound
costly to suggest and it sticks to the principle that only
specialized
used of the system would need to do
specialized processing.
Thanks
P.S. As I P.S.ed I do prefer length encoding for
framing but if used blindly
(as in plain HTTP), it forces one to construct the entire output (in
memory)
before sending it
at great latency and memory costs (on element and manager)
in order to know the length to put it in the
frame header. To work, that
requires true framing/fragmentation and
incremental parsers. THat's
something that's been on my mind with
NetConf (e.g. a large show config)
since the first time I saw it. In the
end, the scripting requirements
are not completely similar to the 24/7
management protocol requirements...
[ignore me if you've discussed this before,
I'm new on the list though not
to the protocol...]
-----Original
Message-----
From: Ed Roskos [mailto:ed.roskos@utstar.com]
Sent: Thursday, February 19, 2004 8:37 PM
To: Wes Hardaker
Cc: Gagnon,
Gilbert [CAR:NM10:EXCH]; tstoddar@utstar.com; 'Juergen Schoenwaelder';
netconf@ops.ietf.org
Subject: Re: Issue 5.1) SSH End
of message directive
Wes Hardaker wrote:
>>>>>>On Thu, 19 Feb 2004 20:02:52 -0500,
Ed Roskos
>>>>>><ed.roskos@utstar.com> said:
>
>
> Ed> But SSH, as I see it, must fill a particular need, and
that is
> Ed> scripting. How do you
explain to someone that they cannot just
> Ed>
cut-and-paste, they must calculate bytes for the message, while
> Ed> they are playing around getting their
scripts right in the first
> Ed> pass?
>
> Oh, sorry if you thought
I was advocating byte counters. I wasn't. I
> was just pointing out there are two ways to get around problems
like
> this: forced escaping and byte
lengths.
>
> Note that
BEEP has byte length counters in it as well, which I've
> pointed out before because I wasn't sure script-writers would
want it.
I would advocate something
byte-counters for non-scripting interfaces. Haven't played with BEEP yet,
but I can't wait. Cool stuff =)
> Ed>
What we need for SSH is a simple way to stream in your messages
> Ed> which does not introduce possible
security breaches. I think we
> Ed>
pretty much have such a method.
>
> Which is? disallowing CDATA? That'd
be unpopular I bet.
Nah, disallowing CDATA was
killing a fly with a nuke. Gilbert had a far better idea. If you
use CDATA with the SSH protocol, just make sure you don't do so with the EOM
marker on output, which implementers should be able to do pretty
easily.
To see if we have the bases covered with
this approach, here are the ideas again (correct me if I'm wrong!):
On input if the user chooses to use CDATA on input with
the EOM marker, an implementation would wind up doing one of two things.
Either it recognizes it is inside of a CDATA section and handles it
correctly, or it does not recognize this, falsely identifies the
end-of-message, and a syntax error occurs resulting in no
update.
On output, we just have to be sure that
we do not render the end-of-message text verbatim. This can only
happen in a CDATA section, AFAIK. You can always render with <
and > outside of a CDATA block. Since an XML parser will pull
in text after stripping out the CDATA syntax and converting escaped
characters in non-CDATA text, you would never know the difference, and the
framing by a script writer will
work.