Subject: [Netconf] rpc-reply

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Aug 2008 12:56:39 +0200 (CEST)

Hi,

Section 4.2 of rfc4741 says:

   The response name and response data are encoded as the contents of
   the <rpc-reply> element.  The name of the reply is an element
   directly inside the <rpc-reply> element, and any data is encoded
   inside this element.

Note "the name of the reply is an element...".   Is the intention that
each rpc operation can define its own reply element?  Always exactly
one element?  This is not reflected in the XSD.  The XSD allows one
<ok/> or <data>...</data> element only.

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

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 09:27:33 -0400

><ok/> or <data>...</data> element only.

IMHO this is a bug in the XSD and we are allowed to return content
directly inside the <rpc-reply>, but Andy's take is that it's a bug
in the text and all returned data should always be in the <data>
element.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 09:27:33 -0400

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 07:30:12 -0700

>> <ok/> or <data>...</data> element only.

No -- there is only one standard <rpc-reply> element and it
also allows <rpc-error>* instead of <ok/>?.

> in the text and all returned data should always be in the <data>

Yes -- the WG wanted to include the <data> element in
the replies that returned more than status. It provides
a consistent way to determine that 'the empty set' was
returned (e.g., filter did not match anything.)

> ________

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 07:30:12 -0700

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 10:55:44 -0400

Andy Bierman writes:
>the replies that returned more than status.

Last time this issue came up, I looked for this discussion to see
how the concensus was found and couldn't find it.  Could you point
me to it?

>It provides

This is for <get-config>, which is the one place the
<data> element is referenced in the text.

    7.1.  <get-config>
    ...
    Positive Response:

      If the device can satisfy the request, the server sends an
      <rpc-reply> element containing a <data> element with the results
      of the query.

This is not true for other RPCs.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 10:55:44 -0400

7.1.  <get-config>
    ...
    Positive Response:

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 08:11:47 -0700

> This is not true for other RPCs.

It is for the ones that return data: get and get-config.
No other operations actually return data in the response.

All other standard operations return <ok> or <rpc-error>.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 08:11:47 -0700

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 11:37:28 -0400

>No other operations actually return data in the response.

We're discussing the generic RPC definitions in 4.2, not the specific
RPCs like get and get-config which specifically define their own
content.

4.2 says:

which means one can define an RPC called <ping> that returns
<ping-results> as an element directly inside the <rpc-reply>.

<rpc>
   <ping>
      <host>10.1.2.3</host>
   </ping>
</rpc>
<rpc-reply>
   <ping-results>
      <target-host>10.1.2.3</target-host>
      <target-ip>10.1.2.3</target-ip>
      <packet-size>56</packet-size>
      <probe-results-summary>
      <probes-sent>5</probes-sent>
      <responses-received>0</responses-received>
      <packet-loss>100</packet-loss>
      </probe-results-summary>
      <ping-failure>no response</ping-failure>
   </ping-results>
</rpc-reply>

The question is whether this requires an argument to "output":

    rpc ping {
        input {
            leaf host { ... }
        }
        output ping-results {
            leaf target-host { ... }
            leaf target-op { ... }
            leaf packet-size { ... }
            ...
        }
    }

or:

    rpc ping {
        input {
            leaf host { ... }
        }
        output {
            container ping-results {
                leaf target-host { ... }
                leaf target-op { ... }
                leaf packet-size { ... }
                ...
            }
        }
    }

I'm using the latter now, but moving to the former is fine with me.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 Aug 2008 11:37:28 -0400

4.2 says:

<rpc>
   <ping>
      <host>10.1.2.3</host>
   </ping>
</rpc>
<rpc-reply>
   <ping-results>

    rpc ping {
        input {
            leaf host { ... }
        }
        output ping-results {
            leaf target-host { ... }
            leaf target-op { ... }
            leaf packet-size { ... }
            ...
        }
    }

or:

    rpc ping {
        input {
            leaf host { ... }
        }
        output {
            container ping-results {
                leaf target-host { ... }
                leaf target-op { ... }
                leaf packet-size { ... }
                ...
            }
        }
    }

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Aug 2008 08:54:20 -0700

Phil Shafer wrote:
>         outputFrom [email-masked]  Mon Aug 11 08:54:24 2008
Date: Mon, 11 Aug 2008 08:54:20 -0700
From: Andy Bierman <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] rpc-reply
Sender: [email-masked]

Phil Shafer wrote:
>          ping-results {

I see your point.
No problem.  I prefer the latter solution because changing the output
statement has an impact on the augment statement.  It is also
more intuitive to think of both 'input' and 'output'
as conceptual containers that do not really exist in the PDU XML.

Also, the current design allows multiple elements (via augments)
to be included in the output.  Changing output-stmt would
prevent the addition of sibling nodes to 'ping-results'.

Andy

output ping-results {
> I'm using the latter now, but moving to the former is fine with me.

I see your point.
No problem.  I prefer the latter solution because changing the output
statement has an impact on the augment statement.  It is also
more intuitive to think of both 'input' and 'output'
as conceptual containers that do not really exist in the PDU XML.

Also, the current design allows multiple elements (via augments)
to be included in the output.  Changing output-stmt would
prevent the addition of sibling nodes to 'ping-results'.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Aug 2008 20:32:57 +0200 (CEST)

Hi,

I asked this question to the netconf WG but it of course impacts what
will be done in netmod.  Going back to my original question:

Does the WG think that this text is correct, and the XSD wrong?

If so, should I interpret "the reply is an element" as saying that
there can be *one* reply and never more?  For example, is this
illegal:

  <rpc>
    <ping>
      <host>10.1.2.3</host>
    </ping>
  </rpc>
  <rpc-reply>

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Aug 2008 20:32:57 +0200 (CEST)

Hi,

  <rpc>
    <ping>
      <host>10.1.2.3</host>
    </ping>
  </rpc>
  <rpc-reply>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 10:37:34 -0700

>     <ping-failure>no response</ping-failure>

Any chance of a resolution on this detail?
If the XSD is normative, then YANG rpc output statements
may only contain 1 element which gets inserted

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Aug 2008 10:37:34 -0700

Any chance of a resolution on this detail?
If the XSD is normative, then YANG rpc output statements
may only contain 1 element which gets insas a child node of the NETCONF 1.0 'data' element.

If the XSD is wrong, then the YANG output statement
may contain more than 1 element, with any name,
and any namespace, which are child nodes of
the <rpc-reply> element.

I agree with Phil's interpretation, i.e., that the
XSD applies to the RPC methods defined in RFC 4741,
and not every possible RPC method, especially those in vendor namespaces.

The results from the example above would actually look more like this:

     <nc:rpc-reply message-id="101"
         xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
         xmlns="http://example.com/ns/ping">
       <target-host>10.1.2.3</target-host>
       <target-ip>10.1.2.3</target-ip>
       <packet-size>56</packet-size>
       <probe-results-summary>
         <probes-sent>5</probes-sent>
         <responses-received>0</responses-received>
       <packet-loss>100</packet-loss>
       </probe-results-summary>
       <ping-failure>no response</ping-failure>
     </nc:rpc-reply>

IMO, this should be allowed.
The only rule would be that all <rpc-error> instances
must be encoded before any data nodes (as it is now).

It really wouldn't affect a vendor's deployed agents,
since all the 'official' RPCs would also be valid
with this clarified interpretation.

Andy

erted
as a child node of the NETCONF 1.0 'data' element.

If the XSD is wrong, then the YANG output statement
may contain more than 1 element, with any name,
and any namespace, which are child nodes of
the <rpc-reply> element.

I agree with Phil's interpretation, i.e., that the
XSD applies to the RPC methods defined in RFC 4741,
and not every possible RPC method, especially those in vendor namespaces.

The results from the example above would actually look more like this:

     <nc:rpc-reply message-id="101"
         xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
         xmlns="http://example.com/ns/ping">
       <target-host>10.1.2.3</target-host>
       <target-ip>10.1.2.3</target-ip>
       <packet-size>56</packet-size>
       <probe-results-summary>
         <probes-sent>5</probes-sent>
         <responses-received>0</responses-received>
       <packet-loss>100</packet-loss>
       </probe-results-summary>
       <ping-failure>no response</ping-failure>
     </nc:rpc-reply>

IMO, this should be allowed.
The only rule would be that all <rpc-error> instances
must be encoded before any data nodes (as it is now).

It really wouldn't affect a vendor's deployed agents,
since all the 'official' RPCs would also be valid
with this clarified interpretation.

Andy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 21 Aug 2008 20:39:30 +0200

May I ask that someone writes up proposed clarification text 
with instructions as to where it would have to go into RFC4741,
so that we can all see exactly what the "fix" would look like 
and the can then all cast our opinion on it?

Thanks,
Bert Wijnen (speaking as WG co-chair)

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 21 Aug 2008 20:39:30 +0200

Thanks,