Subject: [netconf] Added restconf-next for restructuring error messages

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Jul 2020 14:26:26 +0000

Folks,

I just added this “restconf-next” issue for restructuring error messages:

	https://github.com/netconf-wg/restconf-next/issues/3 <https://github.com/netconf-wg/restconf-next/issues/3>

K.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Jul 2020 09:41:16 -0700

Hi,

I don't agree that any NBC changes are needed to RESTCONF, including this
one.
I agree servers usually send 1 error, but not always. E.g., the <validate>
operation
returns as many errors as it can find and does not stop on the first error.
It is not a burden to have an "errors" container so the protocol allows for
multiple errors
and is the same data model for XML and JSON.

Andy

On Wed, Jul 1, 2020 at 7:26 AM Kent Watsen <[email-masked]> wrote:

> https://github.com/netconf-wg/restconf-next/issues/3
>
> K.
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Jul 2020 18:12:44 +0000

I was expecting this response  ;)

We could grandfather the current “errors” structure by, e.g., using a “choice”...

We don’t even have to wait for RC-next, as someone could submit a short I-D for just this issue.  We just need to define a way for the client to signal to the server its preferences…likely the existing "Accept-Type” header could be used.

K.

> On Jul 1, 2020, at 12:41 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> I don't agree that any NBC changes are needed to RESTCONF, including this one.
> I agree servers usually send 1 error, but not always. E.g., the <validate> operation
> It is not a burden to have an "errors" container so the protocol allows for multiple errors
> On Wed, Jul 1, 2020 at 7:26 AM Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
> Folks,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Jul 2020 16:04:59 -0700

On Wed, Jul 1, 2020 at 11:12 AM Kent Watsen <[email-masked]> wrote:

> We don’t even have to wait for RC-next, as someone could submit a short
> I-D for just this issue.  We just need to define a way for the client to
> signal to the server its preferences…likely the existing "Accept-Type”
> header could be used.
>
>
Seems like a lot of trouble to save about 8 bytes in the JSON response.
Adding a request header (larger than 8 byes) actually increases the overall
size
of the operation.  I prefer stability and consistency across XML and JSON
encoding
of the same protocol messages.

K.
Andy