Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 07 Oct 2014 09:23:19 +0200

Dear NETCONF WG participants,

Appologies for being a bit late with trying to draw a conclusion on this
one.

As WG chairs, we believe that option a) had reasonable support with
good technical arguments why the choice was for that option.

On pure numerical count, we believe that option c won, but it was/is also
clear that it just complicates things and has more risk of
interoperability problems.

So we as chairs propose to go with option a).

If anyone still has REAL STRONG objections, pls speak up before
the end of this week. If we hear none by Friday Okt 10th,
we conclude that we have (rough) consensus to go with option a)

Bert and Mehmet.

On 02/09/14 12:23, Bert Wijnen (IETF) wrote:
> On 26/08/14 22:49, Andy Bierman wrote:
>>
>> Perhaps the co-chairs should decide how to proceed somehow.
>
> Dear NETCONF WG participants, do you have an opinion?
>
> So far I have seen only a few people express their opinion.
>
> Please speak up so that we (WG chairs) have better data to judge if we
> do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014.
>
> Please speak your mind about these options:
>
> a) XML is mandatory
> b) JSON is mandatory
> c) XML and JSON are both mandatory
> d) Both XML and JSON mandatory on client,
>     server can implement whatever it chooses.
>     Not clear yet how the client would find out, but that would of course
>     be something to be worked out if we choose this option
>
> Bert
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Oct 2014 09:26:56 -0700

Hi,

> interoperability problems.

I think you meant that (d) got the most. And it wasn't "whatever it
chooses",
it was "XML or JSON or both".

Bert and Mehmet.
Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 9 Oct 2014 17:43:36 +0000

Hi Andy, All,

in reality it was 8 for a) and 8 for d) until Mahesh changed his mind in favor of d).
However with the conclusion mail below you may count both co-chair's votes in favor of a).

We indeed think that a) had reasonable support with good technical arguments, which are mainly "less options, less complexity, better understood".
You may count the co-chairs now to "old-school" but we believe that a) improves interoperability.

Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of ext Andy Bierman
Sent: Tuesday, October 07, 2014 6:27 PM
To: Bert Wijnen (IETF)
Cc: Netconf
Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity

Hi,

On Tue, Oct 7, 2014 at 12:23 AM, Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
Dear NETCONF WG participants,

I think you meant that (d) got the most. And it wasn't "whatever it chooses",
it was "XML or JSON or both".

Bert and Mehmet.

Andy

a) XML is mandatory
b) JSON is mandatory

Bert

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Oct 2014 16:37:00 +0200

Hi Mehmet,

On 09 Oct 2014, at 19:43, Ersue, Mehmet (NSN - DE/Munich) <[email-masked]> wrote:

> However with the conclusion mail below you may count both co-chair’s votes in favor of a).

Either way, it is IMO nowhere near to rough consensus.

>  
> We indeed think that a) had reasonable support with good technical arguments, which are mainly “less options, less complexity, better understood”.

If JSON becomes the preferred choice - and I think we cannot exclude this alternative - than a) will actually mean more complexity for server implementors.

Some 20+ years ago I heard many good technical arguments why ISO OSI was better than TCP/IP.

> You may count the co-chairs now to “old-school” but we believe that a) improves interoperability.

The interoperability argument neglects the fact that RESTCONF clients won’t pick their servers out of the blue (or vice versa for call home). NMSes are usually selected for a concrete network, and the capabilities of network devices (including support for RESTCONF encodings) can be taken into account.

Lada

> On Tue, Oct 7, 2014 at 12:23 AM, Bert Wijnen (IETF) <[email-masked]> wrote:

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 13 Oct 2014 13:50:15 +0200

So with Mehemt and myself choosing/vouching for a), we have 10 for a)
and 8 for d) (sorry that I said c) in an earlier email).

 > Either way, it is IMO nowhere near to rough consensus.

Can anyone tell us what then constitutues "rough consensus"?
I am OK if yount to call it "very rough consensus". But I do not
see we cann claim that option d) has "rough consensus".

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Oct 2014 14:04:32 +0200

On 13 Oct 2014, at 13:50, Bert Wijnen (IETF) <[email-masked]> wrote:

> Can anyone tell us what then constitutues "rough consensus”?

From “The Tao of IETF”:

The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree.

> see we cann claim that option d) has "rough consensus”.

I didn’t say that. Without rough consensus, I think the RESTCONF spec should not require any encoding to be mandatory and leave it to implementors to choose one that’s appropriate for a particular use case.

Lada

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 13 Oct 2014 14:53:17 +0200

inline

On 13/10/14 14:04, Ladislav Lhotka wrote:
> On 13 Oct 2014, at 13:50, Bert Wijnen (IETF)<[email-masked]>  wrote:
>
> The general rule on disputed topics is that the Working Group has to come to "rough consensus",
> meaning that a very large majority of those who care must agree.
>
>> >I am OK if you want to call it "very rough consensus". But I do not
>> >see we can claim that option d) has "rough consensus”.
> I didn’t say that. Without rough consensus, I think the RESTCONF spec should not require any
> encoding to be mandatory and leave it to implementors to choose one that’s appropriate for a
> particular use case.
>
Lada, apologies if you understood me to say that "you said that option d) did have rough concensus".
You did not. But as chairs we cannot claim that d) has rough consensus. This what I meant to say.

We as WG chairs still believe that a) had the best support and best supporting arguments.
One can quibble about it not being "very large majority". In my view, a "very large majority
basically means consensus". Consensus does not require 100% agreement from all.
In my view:
  - consensus means: a very large majority agrees, no MAJOR OBJECTIONS
  - rough consensus: majority agrees, no MAJOR OBJECTIONS
  - very rough consensus: small majority (just above 50% of casted opinions) agrees,
                          and no MAJOR OBJECTIONS.

So I'd say we have "very rough consensus".
I can't help that most people on our mailing list seem to not be bothered and do not express
their opinion one way or another. So as a WG co-chair, I do not see how we can move forward
if we as WG chairs do not just take a decision and declare what we think is consensus.

So: do you have a MAJOR OBJECTION, and do you want us to continue the discussion
for another x months? We can issue (re-issue) another WGLC and state that if we do not get
at least say 500 responses that we will drop the document all together. Maybe that wakes up
people???

Or can you accept our interpretation for "rough consensus for a)."?

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Oct 2014 15:43:43 +0200

> You did not. But as chairs we cannot claim that d) has rough consensus. This what I meant to say.

Right, I think it is fair to say there is no rough consensus for any of the options.

> - rough consensus: majority agrees, no MAJOR OBJECTIONS

In my view, marginal majority is not the same as rough consensus.

> Or can you accept our interpretation for "rough consensus for a).”?

The Tao also says it is up to WG chairs to decide when rough consensus was reached, so I will have to accept it. I just think going for a) would be a mistake because it is at odds with 2014 reality. From the feedback I receive it seems clear to me that the momentum is now behind JSON and not XML, whether we like it or not.

The main technical argument in favor of JSON is that it is *dead simple* and yet it will do the job in many/most cases. This is often what counts.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Oct 2014 15:08:13 +0000

I think folks are overlooking that fact that (d) will be implemented
regardless what the RFC says.  This is much like how some devices may only
implement TLS, even though the standard says SSH is required.  Is this not
a MAJOR OBJECTION?

That said, I still don't understand the interoperability or complexity
concerns, and I think it more worthwhile to focus on how (d) could be
implemented.  One way to do this is to put annotations into the
.well-known/host-meta document, specifically using the "Property" element:

      Request
      -------
      GET /.well-known/host-meta users HTTP/1.1
      Host: example.com
      Accept: application/xrd+xml

      Response
      --------
      HTTP/1.1 200 OK
      Content-Type: application/xrd+xml
      Content-Length: nnn
      <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
          <Link rel='restconf' href='/restconf'>
              <Property
type="urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>json</Property>
              <Property
type="urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>xml</Property>
          </Link>
      </XRD>

      // This RESTCONF server supports both JSON and XML (future encodings
TBD)

Per RFC6415, the .well-known/host-meta document is of type
application/xrd+xml (i.e. a fixed-format, easy to parse).  Additionally,
this document is static - no code needs to generate it, which means it
doesn't swing the RESTCONF server towards implementing either XML or JSON
(it's neutral).

Thanks,
Kent

---

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 13 Oct 2014 17:16:47 +0100

I have been advised by my security people that, for the environment where we
are considering NETCONF, SSH is not acceptable. Consequently I would not
want to burden manufacturers with having to implement SSH on their devices
(despite the RFC). On that basis, though my initial unstated preference was
for (a), I can understand the argument for (d) below.

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: 13 October 2014 16:08
To: Ladislav Lhotka; Bert Wijnen
Cc: Netconf
Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your
opinion on RESTCONF modularity

I think folks are overlooking that fact that (d) will be implemented
regardless what the RFC says.  This is much like how some devices may only
implement TLS, even though the standard says SSH is required.  Is this not a
MAJOR OBJECTION?

      Request
      -------

      Response
      --------
      HTTP/1.1 200 OK

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Oct 2014 10:20:44 -0700

Hi,

> for (a), I can understand the argument for (d) below.

I do not object to the XML requirement because it is clearly a more mature
standard
than JSON at this time -- but JSON adoption is growing rapidly, and we know
it.
At the time SSH was made the mandatory transport for NETCONF in 2004, there
was
nothing else replacing CLI over SSH.

Making XML mandatory ensures that servers will have to implement both JSON
and XML
for many years to come, and the clients will be free to choose which
encoding to support.
(The exact opposite of what is really needed.)

Andy

> a

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Oct 2014 18:03:24 +0000

Hi Jonathan,

Can say anything about why SSH is not acceptable?   In particular, if only
using SSH with X.509 certificates (RFC6187), would there still be an
objection?

Thanks,
Kent