Subject: Re: [Netconf] how to handle XML parse errors

From: "Andy Bierman" <[email-masked]>
Date: Thu, 09 Sep 2010 08:48:14 -0700

I don't see any text about framing in the TLS spec. I think each transport mapping will need to be updated.

I noticed sloppy overlapping of normative behavior such as 2.2, para 2...the peer MAY close an idle connection.  This is not part of 4741. This makes netconf work differently over each transport...really bad plan.

I agree with you that 4741bis needs to define this sort of behavior, not the transport rfcs.

Andy

----- Reply message -----
From: "Wes Hardaker" <[email-masked]>
Date: Thu, Sep 9, 2010 07:48
Subject: [Netconf] how to handle XML parse errors
To: "Paul Selkirk" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

>>>>> On Thu, 9 Sep 2010 08:07:07 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> If we keep the framing as is, I prefer to close the connection - but
JS> this drastic measure is really only needed for _some_ of the SSH
JS> transports.

It's also in 5539, which suffers from the same problem.

[which is why I think it should go into 4741bis: lets take care of it
properly for all transports]
-- 
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 10 Sep 2010 09:30:13 -0700

>>>>> On Thu, 09 Sep 2010 08:48:14 -0700, "Andy Bierman" <[email-masked]> said:

AB> I don't see any text about framing in the TLS spec. I think each
AB> transport mapping will need to be updated.

It's not call framing and it's inferred rather than stated:

   This document uses the same delimiter sequence ("]]>]]>") defined in
   [RFC4742], which MUST be sent by both the client and the server after
   each XML document in the NETCONF exchange.  Since this character
   sequence can legally appear in plain XML in attribute values,
   comments, and processing instructions, implementations of this
   document MUST ensure that this character sequence is never part of a
   NETCONF message.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Sep 2010 10:09:00 -0700

Hi,

So this standards stuff is easy.
We just decree with capital letters that a server MUST NOT let anything
bad happen... problem solved.  Never mind that this is a gross layer violation
and no implementation will actually do it, but it seems to solve the IETF's problem.

Andy