Phil Mayers writes:
>OTOH I've seem XML come back from some devices like this:
>
>
> ...
>i.e. no xmlns for the namespace on a tag. This is just broken, and
>really hard to deal with using normal XML libraries.
Yes, that would definitely be a bug.
>I don't think netconf wants to end up l
Phil Mayers writes:
>I guess. What about rpc payloads, thinking in particular config XML blocks?
We'll ignore incoming namespaces there as well, but should be
generating proper standard XML.
Thanks,
Phil
___
juniper-nsp mailing list juniper-nsp@puck.ne
On 18/06/14 07:52, Balasankar Rajaguru wrote:
[balasank] This is a bug in JUNOS. This has been reported already
and the fix is available from 13.1.
Awesome good to know.
[balasank] JUNOS doesn't validate the namespaces in 'rpc' as it goes
by the postal principle which says be conservative i
On 25/06/14 02:32, Phil Shafer wrote:
Phil Mayers writes:
The fundamental question is: are namespaces used incorrectly all over
the place in Netconf?
JUNOS has some namespace issues, suffering from both pre-rfc
implementation problems and attempts to re-use the underlaying
Junoscript XML API c
Phil Mayers writes:
>The fundamental question is: are namespaces used incorrectly all over
>the place in Netconf?
JUNOS has some namespace issues, suffering from both pre-rfc
implementation problems and attempts to re-use the underlaying
Junoscript XML API code. PR 826463 is addressing these.
>
On Jun 17, 2014, at 10:01 AM, Phil Mayers wrote:
> On 17/06/14 14:49, Keegan Holley wrote:
>>>
>>> I've looked at the PyEZ and ncclient code, and basically they seem
>>> to take the approach of just throwing away all namespace
>>> information. This seems icky to me, and make me wonder if Netcon
On 17/06/14 14:49, Keegan Holley wrote:
I've looked at the PyEZ and ncclient code, and basically they seem
to take the approach of just throwing away all namespace
information. This seems icky to me, and make me wonder if Netconf
is going to be another SOAP - so many implementation errors that
"
>
> I've looked at the PyEZ and ncclient code, and basically they seem to take
> the approach of just throwing away all namespace information. This seems icky
> to me, and make me wonder if Netconf is going to be another SOAP - so many
> implementation errors that "interop" ends up being a mess
On 12/06/14 17:48, Tyler Christiansen wrote:
I honestly couldn't tell you--but it wouldn't surprise me. Data formats
like XML aren't very good data formats.
Maybe, maybe not. But they're what we've got, so...
I'd rather stab myself with a rusty fork than use Python. :) To each
his own, I
On Thu, Jun 12, 2014 at 9:16 AM, Phil Mayers
wrote:
> On 12/06/14 16:38, Tyler Christiansen wrote:
>
>> What are you trying to accomplish? It may be easier to use the Juniper
>>
>
> I am trying to integrate our new EX switches into our existing, extensive,
> automation and provisioning systems.
On 12/06/14 16:38, Tyler Christiansen wrote:
What are you trying to accomplish? It may be easier to use the Juniper
I am trying to integrate our new EX switches into our existing,
extensive, automation and provisioning systems.
I've already got it working with Junoscript, but as noted had a
What are you trying to accomplish? It may be easier to use the Juniper
Netconf Ruby gem or the Python junos-eznc module depending on your
background and goals.
--tc
On Thu, Jun 12, 2014 at 6:15 AM, Phil Mayers
wrote:
> All,
>
> We've got some code to talk junoscript, but it's run into problem
All,
We've got some code to talk junoscript, but it's run into problems
because the XML parser turns out to not reliably deliver start/end tag
events to upper layers - it is dependent on the "chunking" of input data :o(
To sidestep this difficulty, I started to look at Netconf, which of
cour
13 matches
Mail list logo
