Subject: [Netconf] ssh EOM and netconf 1.1

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Nov 2010 04:07:56 +0100

Hi,

I am trying to find a solution that allows to fix the unfortunate EOM
marker without requiring a new SSH subsystem. Would the following
work:

a) We allocate a new EOM marker (e.g. 0x04) we believe is better than
   what we have now.

b) NETCONF client and server exchange hello messages in the
   traditional way, using the ]]>]]> EOM marker.

c) If a peer announces the capability urn:ietf:params:netconf:base:1.1,
   this is taken as the signal to switch from the ]]>]]> EOM marker to
   the new EOM marker (e.g. 0x04).

Since the hello exchange does not carry any user supplied data, the
usage of the traditional EOM marker during the hello exchange should
not be a big deal.

Would something like this work?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Nov 2010 12:03:42 +0800

>    the new EOM marker (e.g. 0x04).

How about using the old EoM for hello but include a processing
instruction *before* the <hello> tag, e.g.
<?EOM:EOT?>

This could be handled entirely within the transport layer.

> usage of the traditional EOM marker during the hello exchange should

Agreed.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Nov 2010 05:12:41 +0100

>From a purist's architectural point of view, both options require
either the transport to peak into the message or the message layer to
tell the transport to upgrade to 1.1 framing. In implementations, this
might be rather simple to do. Since NETCONF 1.1. code already pays
attention to the base:1.1 capability, not introducing another magic
processing instruction might actually be simpler.

At the end, I do not care much - I am just trying to see whether it is
possible to find a solution that allows to transition to a better EOM
marker without requiring a new subsystem.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Nov 2010 13:25:35 +0800

> processing instruction might actually be simpler.

For the message layer this action would be specific only for one type of
transport. I'd prefer not to contaminate the message layer with this
hack and confine the solution to the subsystem which caused the problem.
But yes, both are feasible.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Nov 2010 08:40:01 +0100 (CET)

> This could be handled entirely within the transport layer.

I think this is a better solution.  The idea is that in order to avoid
the inter-layer communication we have "magic" data before the <hello>
element that indicates that the new framing sequence is used.  If this
magic data is done in a way that old implementations just ignore it,
we're safe.  I was thinking about using XML comments, but a PI should
work as well.

Juergen said:

js> From a purist's architectural point of view, both options require
js> either the transport to peak into the message or the message layer
js> tell the transport to upgrade to 1.1 framing.

We already mix transport and message data in the same stream... but we
don't want to put an XML parser in the transport layer, so we have to
fix the format so it is easily found, e.g.:

  [xmldecl CRNL]
  '<?eom eot?>' CRNL
  data
  ']]>]]>'

The peer would switch to the new EOM only if both peers use the same.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Nov 2010 23:57:33 -0800

I don't like this solution at all.
It forces the SSH layer code to start parsing the XML,
in order to determine what EOM sequence to look for.
It has to skip past the <?xml ... ?> directive, skip
past comments and any other PIs, and then parse the magic PI.
What if the old EOM occurs before that is done?
What if the new EOM occurs before that is done?

The solution needs to let the SSH layer treat the NETCONF channel
as a byte stream 100% of the time.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Tuesday, November 09, 2010 11:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] ssh EOM and netconf 1.1

Juergen said:

  [xmldecl CRNL]
  '<?eom eot?>' CRNL
  data
  ']]>]]>'

/martin
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Nov 2010 09:02:24 +0100 (CET)

> What if the new EOM occurs before that is done?

Please read my text again.

/martin