Subject: [Netconf] xml declaration required or optional

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 May 2008 10:48:30 +0200

Hi,

are XML declarations required for NETCONF messages or optional? I
could not find an answer in the RFCs and it seems that some
implementations require XML declarations in NETCONF messages while
others don't.

XML 1.0 seems to require XML declarations for valid XML documents
but then RFC 4741 or RFC 4742 are silent about the question whether
NETCONF messages must be valid XML or just well-formed.

If XML declarations are required, what is the error code to return?

/js

PS The last question touches a general issue; the RFC does not provide
   much detail which error codes apply where and so implementations
   seem to return pretty different results when you feed them with
   carefully crafted input. There are several other places where RFC
   4741 is inconsistent; shall we start an effort to work on a -bis
   version so that we can fix the specs as we test implementations?

-- 
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 [email-masked]  Tue May  6 01:48:39 2008
Date: Tue, 6 May 2008 10:48:30 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [Netconf] xml declaration required or optional
Reply-To: [email-masked]
Sender: [email-masked]

Hi,

are XML declarations required for NETCONF messages or optional? I
could not find an answer in the RFCs and it seems that some
implementations require XML declarations in NETCONF messages while
others don't.

XML 1.0 seems to require XML declarations for valid XML documents
but then RFC 4741 or RFC 4742 are silent about the question whether
NETCONF messages must be valid XML or just well-formed.

If XML declarations are required, what is the error code to return?

/js

PS The last question touches a general issue; the RFC does not provide
   much detail which error codes apply where and so implementations
   seem to return pretty different results when you feed them with
   carefully crafted input. There are several other places where RFC
   4741 is inconsistent; shall we start an effort to work on a -bis
   version so that we can fix the specs as we test implementations?

-- 
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____________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 May 2008 10:25:56 -0400

Hi

It's not a bad idea. Another ambiguity seems to be whether the reply to
<get> and <get-config> contains the <ok> element or not.

We are also suppose to be doing -bis to the transport mappings to add
text around <notification> although if we touch it we might want to see
if we need to make the text more general if we think we might ever add
something else that doesn't use the <rpc> layer.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 06, 2008 4:48 AM
To: [email-masked]
Subject: [Netconf] xml declaration required or optional

Hi,

are XML declarations required for NETCONF messages or optional? I could
not find an answer in the RFCs and it seems that some implementations
require XML declarations in NETCONF messages while others don't.

XML 1.0 seems to require XML declarations for valid XML documents but
then RFC 4741 or RFC 4742 are silent about the question whether NETCONF
messages must be valid XML or just well-formed.

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 May 2008 10:25:56 -0400

Hi

Sharon 

-----Original Message-----

Hi,

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 May 2008 16:46:45 +0200 (CEST)

> <get> and <get-config> contains the <ok> element or not.

Do you mean for the case where no data is returned, e.g. if a filter
is used which selects nothing?  For the case where data _is_ returned
I think the text + XSD is clear.

I think we should use the ticket tracker
(http://www3.tools.ietf.org/wg/netconf/trac/) for these issues.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 May 2008 16:46:45 +0200 (CEST)

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 06 May 2008 16:47:43 +0200

Hello,
I would like a bis.

Would a bis only cover corrections or can it include new stuff like:
- with-defaults
- test-only option for edit-config

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 06 May 2008 16:47:43 +0200

Hello,
I would like a bis.

Balazs

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 May 2008 10:55:14 -0400

Hi

Section 4.4 says:

The <ok> element is sent in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request.

This has caused some confusion.

Sharon 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 10:47 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] xml declaration required or optional

"Sharon Chisholm" <[email-masked]> wrote:
> Hi
> 
> It's not a bad idea. Another ambiguity seems to be whether the reply 
> to <get> and <get-config> contains the <ok> element or not.

Do you mean for the case where no data is returned, e.g. if a filter is
used which selects nothing?  For the case where data _is_ returned I
think the text + XSD is clear.

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 May 2008 10:55:14 -0400

Hi

Section 4.4 says:

Sharon 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 10:47 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] xml declaration required or optional

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 11:16:40 -0400

>This has caused some confusion.

Well, that's completely clear, but not what we implemented in
JUNOS.  I'm happy to fix our implementation though.  Being able
to do simple tests like:

    if ($results/ok) { ... }

is a win.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 11:16:40 -0400

if ($results/ok) { ... }

is a win.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 11:32:43 -0400

>If XML declarations are required, what is the error code to return?

XMLDecls are always optional, per REC-xml:

    [22]  prolog ::= XMLDecl? Misc* (doctypedecl  Misc*)?

So it definitely shouldn't be an error if they are missing.

We talked early on about avoiding the entire prolog, during the
XMLCONF design team's effort:

7.1 Canonical XML

   XMLCONF's use of XML follows the rules specified by Canonical XML
   (RFC 3076 [6]).  These rules were meant to make XML appear in a
   consistent form, suitable for string comparison.  Many of XML's more
   marginal constructs are excluded, allowing simple parsers to avoid
   implementation issues for rarely-used features.
   ...
   RFC 3076 summarizes the changes required by Canonical XML as follows:
   ...
      *  The XML declaration and document type declaration (DTD) are
         removed

But this didn't make it into the final rfc; IIRC we were concerned
about defining our own XML variant.  In the end we just dropped the
DTD.

I'd be happy to return to Canonical XML, but I don't see that as
likely.  Lacking specific words in rfc4741, the xml declaration
should be optional on both sides.  We should add some words saying
that it MUST NOT change over the lifetime of NETCONF session, since
popping from version="1.0" to version="2.0" isn't fun for anyone.

Thanks,
 Phil

P.S.: I did find this ancient text in the prot-00 draft:

  2.4 Channels

   NETCONF requires two distinct communication channels and an optional
   third channel.

   One channel, called the "management channel", carries information for
   managing the NETCONF session.

   A second channel, called the "operation channel", carries a series of
   RPCs that constitute the real content of the NETCONF session.

   A third optional channel, called the "notification channel", carries
   asynchronous notifications.  This channel is established only if both
   parties request it during the initial capabilities exchange.  (See
   Section 6 for more information.)
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 11:32:43 -0400

7.1 Canonical XML

Thanks,
 Phil

  2.4 Channels

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 May 2008 12:03:33 -0400

Hi

Except that it is contradicted in other parts of the document, like the
XSD and the examples. What people do seems to depend on which parts of
the document they pay the most attention to. I sort of like the easier
test too. We just need to be clear which is intended and ensure that all
the text is consistent.

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 11:17 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] xml declaration required or optional

>This has caused some confusion.

Well, that's completely clear, but not what we implemented in JUNOS.
I'm happy to fix our implementation though.  Being able to do simple
tests like:

    if ($results/ok) { ... }

is a win.

Thanks,
 Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 May 2008 12:03:33 -0400

Hi

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 11:17 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] xml declaration required or optional

    if ($results/ok) { ... }

is a win.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 May 2008 18:18:01 +0200 (CEST)

> JUNOS.  I'm happy to fix our implementation though.  Being able

I probably don't understand what you mean.

In a reply to <get-config>, you'll get:

  <rpc-reply ...>
    <data>
      <!-- content here -->
    <data>
  </rpc-reply>

What changes are you suggesting?

  <rpc-reply ...>
    <ok>
      <!-- content here -->
    <ok>
  </rpc-reply>
  
or

  <rpc-reply ...>
    <data>
      <!-- content here -->
    <data>
    <ok/>
  </rpc-reply>

or what?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 May 2008 18:18:01 +0200 (CEST)

<rpc-reply ...>
    <data>
      <!-- content here -->
    <data>
  </rpc-reply>

  <rpc-reply ...>
    <ok>
      <!-- content here -->
    <ok>
  </rpc-reply>
  
or

  <rpc-reply ...>
    <data>
      <!-- content here -->
    <data>
    <ok/>
  </rpc-reply>

or what?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 09:19:31 -0700

> test too. We just need to be clear which is intended and ensure that all

The XSD reflects the intent of the WG, when RFC 4741 was developed.
RPC methods that returned data used the <data> node in the <rpc-reply>.
Instead of sending an empty <rpc-reply> upon success (for RPC methods
that do not return any data), it was thought that an explicit <ok/>
would be better.

IMO, section 4.4 is incomplete.
It should say that that <ok/> only applies if no <data>
element is sent (and the other conditions are met).

All the examples, and the normative XSD say otherwise.

> Sharon 

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 09:19:31 -0700

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 12:32:08 -0400

>  </rpc-reply>

This one.  If the RPC completes and the server hasn't emitted
any errors or warnings, it emits and <ok/> element.  This
allows, say, a config archiver to know if there were any
errors reading the config from flash without having to
traverse the entire hierarchy looking for <error> elements.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 12:32:08 -0400

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 12:35:30 -0400

>The XSD reflects the intent of the WG, when RFC 4741 was developed.

ROFL!!  No one read the XSD.  This has become obvious.  After seven
years, very few WGers read the final draft.  We'd read it so many
times, we just sang the chorus and mumble the verses.  I've been
shocked several times at the words in the text, let alone the XSD.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 12:35:30 -0400

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 10:05:15 -0700

> shocked several times at the words in the text, let alone the XSD.

Nobody reads the YANG ABNF either.  Proves nothing.

What about the RFC 4741 examples?
Are you saying nobody understood the examples either,
and most of them are wrong?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 10:05:15 -0700

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 May 2008 20:01:03 +0200

> - test-only option for edit-config

I think at this point, what we really need is an update which just
does corrections. There many things that are simply inconsistent in
RFC 4741; some are relatively clear and easy to fix. For others, it is
not clear what the intent really was.

/js

PS: I am talking about the text and the examples, not the XSD which I
    tend to ignore. I would love the text and the examples to say
    everything that needs to be said.

-- 
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 [email-masked]  Tue May  6 11:01:19 2008
Date: Tue, 6 May 2008 20:01:03 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Balazs Lengyel <[email-masked]>
Mail-Followup-To: Balazs Lengyel <[email-masked]>,
	[email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] xml declaration required or optional
Reply-To: [email-masked]
Sender: [email-masked]

> - test-only option for edit-config

I think at this point, what we really need is an update which just
does corrections. There many things that are simply inconsistent in
RFC 4741; some are relatively clear and easy to fix. For others, it is
not clear what the intent really was.

/js

PS: I am talking about the text and the examples, not the XSD which I
    tend to ignore. I would love the text and the examples to say
    everything that needs to be said.

_________________________________________

______
Netconf mailing list
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 May 2008 20:04:40 +0200

> So it definitely shouldn't be an error if they are missing.

But declarations are required for valid XML documents as far as I can
tell...  Anyway, I have no personal opinion in favour or against XML
declarations; I just want to know what I have to send to NETCONF
server.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 May 2008 20:04:40 +0200

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 14:56:12 -0400

>and most of them are wrong?

I'm just saying that the document has some parts that show that we
did a fairly poor job of polishing it.  Claiming that the XSD is
the will of the WG conflicts with saying that we need YANG because
no one reads XSD.  We used the "surprises" in the NETCONF XSD as
an example that no one read it.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 14:56:12 -0400

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 15:00:36 -0400

>declarations; I just want to know what I have to send to NETCONF

The "?" in production [22] means "zero or one times", so they are
optional.  For example, XHTML web pages normally start directly
with the DTD:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 15:00:36 -0400

Thanks,
 Phil

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 6 May 2008 21:04:02 +0200

Hi Juergen, All,

a -bis document in general may have also extensions but you are 
right, corrections should be done first.

There are some other 4741 issues in the issue tracker already.
Which issues do you guys think should be covered in the -bis 
document? 
It would be helpful to have a discussion on the list of corrections 
and kind of agreement before we chat with Dan to enable the work 
on -bis.

Cheers, 
Mehmet

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Juergen 
> Schoenwaelder
> Sent: Tuesday, May 06, 2008 8:01 PM
> To: Balazs Lengyel
> Cc: [email-masked]

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 6 May 2008 21:04:02 +0200

Hi Juergen, All,

Cheers, 
Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 May 2008 22:25:57 +0200 (CEST)

Hi,

    if ($results/ok) { ... }

vs.

    if (not($results/rpc-error)) { ... }

I agree with Andy.  All the examples, the text about get-config and
get, and the XSD, indicate that there is no <ok/> element in the reply
for get and get-config.

I would not consider changing this "a clarification" or bugfix.

And I don't see the value in making this change at all.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 06 May 2008 22:25:57 +0200 (CEST)

Hi,

    if ($results/ok) { ... }

vs.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 16:33:56 -0400

>    if (not($results/rpc-error)) { ... }

What about error or warning elements that appear deep inside the
xml hierarchy?  You'd need:

    if (not($results//rpc-error)) { ... }

so your XPath searches the entire hierarchy.

>And I don't see the value in making this change at all.

The current text says:

4.4.  <ok> Element

   The <ok> element is sent in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request.  For
   example:

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

So if you like the examples, this needs fixed to say "if no other
elements are emitted" or something like that.  Either way, it's a
bugfix.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 16:33:56 -0400

The current text says:

4.4.  <ok> Element

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 13:39:15 -0700

> an example that no one read it.

The XSD was reviewed by several people, over several years.
It does reflect the consensus of the WG.

BTW, for future development of protocol features (by NETCONF
or any other WG):

1) Why does the IETF continue to use XSD if there is such great
    evidence that nobody understands it enough to review it?

2) There are less people qualified to review DSDL+Schematron
    than XSD (probably by an order of magnitude).  Is the intent
    to include these in RFCs, but nobody will ever review them?

3) What are protocol WGs supposed to use to document XML-based protocols,
    if not XSD?  When is this 'policy' going to show up in RFCs?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 13:39:15 -0700

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 13:41:10 -0700

> so your XPath searches the entire hierarchy.

This is not allowed (by the XSD you never read).
There are zero-or-more <rpc-error> elements, as direct
siblings of <rpc-reply>.  There are no 'deep errors'
to hunt down in a compliant implementation.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 13:41:10 -0700

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 17:08:19 -0400

>to hunt down in a compliant implementation.

If you read the text part, it says <rpc-error> messages are emitted
during the processing of the operation, which implies they appear
inside the returned content.  If I'm reading statistics from an
embedded hardware component and I get an ENOMEM error, am I not
able to emit that error immediately?  Is it your position that I
need to buffer all errors and emit them at the end of the rpc?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 06 May 2008 17:08:19 -0400

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 14:28:41 -0700

> need to buffer all errors and emit them at the end of the rpc?

I don't see that text.
Even if it did say "emitted" during processing,
that does not mean they are embedded in the <data> element.
That is not how the protocol is defined.
The XSD is normative for XML syntax, and it is very clear:

      <xs:complexType name="rpcReplyType">
        <xs:choice>
          <xs:element name="ok"/>
          <xs:group ref="rpcResponse"/>
        </xs:choice>
        <xs:attribute name="message-id" type="messageIdType"
          use="optional"/>
        <!--
          Any attributes supplied with <rpc> element must be returned
          on <rpc-reply>.
        -->
        <xs:anyAttribute processContents="lax"/>
      </xs:complexType>

      <xs:group name="rpcResponse">
        <xs:sequence>
          <xs:element name="rpc-error" type="rpcErrorType"
            minOccuFrom [email-masked]  Tue May  6 14:31:06 2008
Date: Tue, 06 May 2008 14:28:41 -0700
From: Andy Bierman <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] xml declaration required or optional
Sender: [email-masked]

> need to buffer all errors and emit them at the end of the rpc?

I don't see that text.
Even if it did say "emitted" during processing,
that does not mean they are embedded in the <data> element.
That is not how the protocol is defined.
The XSD is normative for XML syntax, and it is very clear:

      <xs:complexType name="rpcReplyType">
        <xs:choice>
          <xs:element name="ok"/>
          <xs:group ref="rpcResponse"/>
        </xs:choice>
        <xs:attribute name="message-id" type="messageIdType"
          use="optional"/>
        <!--
          Any attributes supplied with <rpc> element must be returned
          on <rpc-reply>.
        -->
        <xs:anyAttribute processContents="lax"/>
      </xs:complexType>

      <xs:group name="rpcResponse">
        <xs:sequence>
          <xs:element name="rpc-error" type="rpcErrorType"
            mrs="0" maxOccurs="unbounded"/>
          <xs:element name="data" type="dataInlineType" minOccurs="0"/>
        </xs:sequence>
      </xs:group>

I cannot find any text that says <rpc-error> elements are ever
embedded within the <data> element.  IMO, this is not compliant.

The XSD exactly reflects the intent of the WG, as I remember it.
The <rpc-reply> contains a single <ok/> element, or it contains
zero-or-more <rpc-error> and zero-or-one <data> elements.

Andy

inOccurs="0" maxOccurs="unbounded"/>
          <xs:element name="data" type="dataInlineType" minOccurs="0"/>
        </xs:sequence>
      </xs:group>

I cannot find any text that says <rpc-error> elements are ever
embedded within the <data> element.  IMO, this is not compliant.

The XSD exactly reflects the intent of the WG, as I remember it.
The <rpc-reply> contains a single <ok/> element, or it contains
zero-or-more <rpc-error> and zero-or-one <data> elements.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 14:53:41 -0700

>... Is it your position that I

No -- it's even worse than that.
The XSD says all the <rpc-error> elements are first in the reply,
optionally followed by the <data> element.

I don't agree that any RFC text indicates the <rpc-error>
messages should be generated in any other way.

I have heard of performance-based arguments for protocols that
are in the forwarding path, but never for NM, especially a
relatively low frequency task like editing the configuration.
It seems clear to me what XML is valid according to the XSD.
I don't think that the internal buffering required for NETCONF
is an implementation burden.  Changing the XSD now will
break existing implementations, so the protocol version will
need to be incremented.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 14:53:41 -0700

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 May 2008 15:09:39 -0700

>> need to buffer all errors and emit them at the end of the rpc?

Wait -- there are no inline errors to generate for
<get> or <get-config>, and there is no <data> returned
in <commit>, <edit-config>, or <validate>, which are the
only RPCs that can generate inline errors.

So why is this even a problem?

Andy

> break existing implementations, so the protocol version will

_______________________________From [email-masked]  Tue May  6 15:11:40 2008
Date: Tue, 06 May 2008 15:09:39 -0700
From: Andy Bierman <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] xml declaration required or optional
Sender: [email-masked]

>> need to buffer all errors and emit them at the end of the rpc?

Wait -- there are no inline errors to generate for
<get> or <get-config>, and there is no <data> returned
in <commit>, <edit-config>, or <validate>, which are the
only RPCs that can generate inline errors.

So why is this even a problem?

Andy

________________
Netconf mailing list
[email-masked]

---

From: "tom.petch" <[email-masked]>
Date: Wed, 7 May 2008 10:35:18 +0200

I agree that the intent was for <ok/> to be an alternative to <data>.

Iff we get consensus on this, then we could file an erratum pending the
production of the -bis.

And I do read the Appendices (which is where the XSD is); but IMO there is a
general principle in RFC that Appendices are not normative unless they say that
they are and so where there is a conflict between Appendix and the body of the
document, then the body wins. Which is something else a -bis could clarify.

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Sharon Chisholm" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 06, 2008 6:19 PM
Subject: Re: [Netconf] xml declaration required or optional

> > the text is consistent.From [email-masked]  Wed May  7 02:44:20 2008
From: "tom.petch" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Date: Wed, 7 May 2008 10:35:18 +0200
Cc: [email-masked]
Subject: Re: [Netconf] xml declaration required or optional
Reply-To: "tom.petch" <[email-masked]>
Sender: [email-masked]

I agree that the intent was for <ok/> to be an alternative to <data>.

Iff we get consensus on this, then we could file an erratum pending the
production of the -bis.

And I do read the Appendices (which is where the XSD is); but IMO there is a
general principle in RFC that Appendices are not normative unless they say that
they are and so where there is a conflict between Appendix and the body of the
document, then the body wins. Which is something else a -bis could clarify.

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Wed, 07 May 2008 08:56:52 -0400

>only RPCs that can generate inline errors.

I gave a real-world example (ENOMEM while fetching statistics).
I'm no XSD dude, but doesn't the :any inside <data> mean it can
contain anything, including <rpc-error>?

Ah, nevermind.  The RFC says:

   Negative Response:

      An <rpc-error> element is included in the <rpc-reply> if the
      request cannot be completed for any reason.

So if I complete the RPC, I can't send an error.  And since warnings
are encoded in <rpc-error> elements, I can't do that either.  So I
need to discard errors and warnings during the the processing of
the operation, if the operation succeeds, right?

This means that warnings and <ok/> (or <data>) can't live together,
which significantly reduces the value of warnings.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 07 May 2008 08:56:52 -0400

Negative Response:

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 May 2008 08:02:22 -0700

> which significantly reduces the value of warnings.

It was the WG's intent that NETCONF work this way.
If <ok/> is present, then there are no warnings to report.
Warnings and data can be in the same reply, but the implementation
may need to buffer the results.  (I can't find any text that even
suggests the WG was concerned about implementations that
want to save some memory and never buffer results.)  The PDUs
have been in the From [email-masked]  Wed May  7 08:04:34 2008
Date: Wed, 07 May 2008 08:02:22 -0700
From: Andy Bierman <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] xml declaration required or optional
Sender: [email-masked]

> which significantly reduces the value of warnings.

It was the WG's intent that NETCONF work this way.
If <ok/> is present, then there are no warnings to report.
Warnings and data can be in the same reply, but the implementation
may need to buffer the results.  (I can't find any text that even
suggests the WG was concerned about implementations that
want to save some memory and never buffer results.)  The PDUs
have been in the same XSD sequence order since the start.
The <rpc-error> element was placed first so the manager would not
have to receive the entire <data> element before knowing
it there were any errors or warnings.

Andy

same XSD sequence order since the start.
The <rpc-error> element was placed first so the manager would not
have to receive the entire <data> element before knowing
it there were any errors or warnings.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 7 May 2008 12:14:15 -0400

Hi

What is the conclusion here (other then we don't need yang after all
;-))? The <ok> element does not get sent when the <data> elements is
sent and we clarify the text in section 4.4 to say this?

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 2:56 PM
To: Andy Bierman
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [Netconf] xml declaration required or optional

Andy Bierman writes:
>Are you saying nobody understood the examples either, and most of them 
>are wrong?

I'm just saying that the document has some parts that show that we did a
fairly poor job of polishing it.  Claiming that the XSD is the will of
the WG conflicts with saying that we need YANG because no one reads XSD.
We used the "surprises" in the NETCONF XSD as an example that no one
read it.

Thanks,
 Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 7 May 2008 12:14:15 -0400

Hi

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 2:56 PM
To: Andy Bierman
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [Netconf] xml declaration required or optional

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 May 2008 09:36:10 -0700

> sent and we clarify the text in section 4.4 to say this?

yes -- the 4.4 text needs to align with the XSD and examples.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 May 2008 09:36:10 -0700

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 07 May 2008 15:10:29 -0400

Andy Bierman writes:
>may need to buffer the results.

No, since an <rpc-error> means the operation did not complete.
Warnings are in <rpc-error>s, so this applies to them as well.

>(I can't find any text that even
>want to save some memory and never buffer results.)

We discussed it on the mailing list enough times.  I see
configs in the >50MB range.  Bufferings not a reasonably
solution.

>it there were any errors or warnings.

Are you saying that buffering's an issue for the manager, but
not for the agent?  That seems exactly backwards.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 07 May 2008 15:10:29 -0400

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 May 2008 13:51:54 -0700

> Warnings are in <rpc-error>s, so this applies to them as well.

Any warnings would be proprietary, since there are only standard
errors defined so far.  What if the <get> operation did complete,
but some strings were truncated, etc.?  This is a gray area
where it is not clear what it means for the operation to complete.

> not for the agent?  That seems exactly backwards.

I'm saying, the XSD has this order (AFAIK) because it was
perceived as better for the manager to know up-front if
the <data> element was 'tainted' in any way.

The XSD is clear on the structure on the <rpc-reply>.
You could embed <rpc-error> or <edit-config> or whatever you want in your
<data> element, but a compliant implementation needs to
follow the XSD structure for standard errors and standard operations.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 May 2008 13:51:54 -0700

Andy

---

From: "David Harrington" <[email-masked]>
Date: Thu, 8 May 2008 08:12:47 -0400

> >     [22]  prolog ::= XMLDecl? Misc* (doctypedecl  Misc*)?

Oh, of course! 
It is right there in plain text; how could we have missed that? ;-)
(just ignore me)

I think it would be helpful to make it clear whether it is REQUIRED or
RECOMMENDED or MAY be present in Netconf, for purposes of
interoperability.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Thu, 8 May 2008 08:12:47 -0400

Oh, of course! 

dbh

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 09 May 2008 17:23:15 +0200

Hello,
Actually we also have problems with buffering big configs.

But you already get buffering problems if you have a big <get> request and you find at the very 
end, that you can't complete your reply. I see the following possibilities:
- you buffer the 50MBs (or more) see if it OK or if you have to start by sending an <rpc-error>
- you start to stream out the big result message and if you run into an error, you abort the 
rpc-reply or maybe even the complete session.
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 09 May 2008 08:51:32 -0700

Balazs Lengyel wrote:
> But you already get buffering problems if you have a big <get> request 
> and you find at the very end, that you can't complete your reply. I see 
> the following possibilities:
> - you start to stream out the big result message and if you run into an 
> error, you abort the rpc-reply or maybe even the complete session.

IMO, this is a totally different problem than <rpc-error> is intended
to solve.

1) If your implementation cannot determine if the RPC method parameters
    are valid, before returning the appropriate reply, it is broken.

2) It is not relevant to the standard what an implementation does
    after it receives an <rpc> request and before it sends an <rpc-reply>.
    This is way out of scope.  If you stream out a reply before
    validating the parameters, then your implementation is broken.

However, if the parameters are valid:

SNMPv3 has an exception mechanism within the varbind list (e.g. noSuchInstance).
NETCONF could have a similar 'runtime exception' mechanism, that allows
<rpc-error> elements to be embedded in <get> and <get-config>
replies, instead of the actual data.  Applications can use these
exception markers to find out why some data that should be present
could not be included in the reply.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 09 May 2008 17:23:15 +0200

Hello,

---

From: Andy Bierman <[email-masked]>
Date: Fri, 09 May 2008 08:51:32 -0700

Andy