Subject: [Netconf] Developing Call-Home for the SSH and TLS transport bindings - New Charter text

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 12 Apr 2013 13:29:36 +0000

Dear NETCONF WG,

we discussed in the IETF #86 Netconf session on resurrecting and developing the call home mechanism, i.e. initiation of session establishment by the server. The session attendees supported the development of call home for both, the SSH and TLS transport bindings.

For the SSH binding, Kent Watsen volunteered to update his draft on Reverse SSH. Concerning the TLS binding, the authors of the rfc5539bis draft agreed to add the necessary text for call home. Based on the session agreement, the co-chairs promised to verify the WG support on the mailing list and add call-home for the ssh and tls drafts to the charter.

If there are no substantial arguments against developing call home as planned by April 26, 2013 EOB, the co-chairs will add following addition to the charter and provide our AD to review and initiate the IESG approval.

Whether point 3. on the list below remains in the charter depends on the response we get to the call on RFC advancement until May 1st.

Please send your comments to the Netconf maillist by April 26, 2013.

Draft authors: Please confirm or comment the deadlines listed in the charter text below with a short note to the co-chairs.

Bert & Mehmet

=== modified charter text ===

  In the current phase of NETCONF's incremental development the workgroup
  will focus on following items:

  1. Add call home mechanism for the mandatory SSH binding providing a
  server-initiated session establishment.

  2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update
  RFC 5539) and add the call home mechanism to provide a server-initiated
  session establishment.

  3. Based on the implementation, deployment experience and
  interoperability testing, the WG will produce a NETCONF status report.
  The result may be clarifications for RFC6241 and RFC6242 and addressing
  any reported errata.

Goals and Milestones:
  Done     - WG Last Call on rfc4741bis
  Done     - Send with-defaults to IESG for consideration as Proposed Standard
  Done     - first WG draft (rev 00) on NACM posted
  Done     - rfc4741bis to IESG for consideration as Proposed Standard
  Done     - Send rfc4742bis to IESG for consideration as proposed Standard
  Done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
  Done     - WGLC for NACM document
  Done     - WGLC for NETCONF specific notifications document
  Done     - submit NACM document to IESG for consideration as Proposed Standard
  Done     - submit NETCONF specific notifications document to IESG for consideration as Proposed Standard
  May 2013 - Submit initial WG document on Reverse SSH
  May 2013 - Collect Implementation/Deployment reports for RFC6241 and 6242
  May 2013 - IETF wiki page and/or initial I-D for RFC6241/6242 implementation/deployment experience
  Jun 2013 - WGLC for rfc5539bis
  Jul 2013 - WGLC for Reverse SSH
  Jul 2013 - WGLC on RFC6241/6242 implementation/deployment experience
  Jul 2013 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
  Aug 2013 - submit SSH binding to AD/IESG for consideration as Proposed Standard
  Aug 2013 - Possibly submit RFC6241/6242 implementation/deployment experience doc to IESG for publication as Informational RFC

=== end-of modified charter text ===

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Apr 2013 19:14:34 -0700

> Dear NETCONF WG,

I don't object to this work, but I don't think it very
high priority.  Since no current drafts related to
this topic exist, it is hard to guess how long
it will take the WG to finish.  Getting to WGLC
within a month of starting seems rather unrealistic.

There was also strong support for the <get2> operation
when it was presented, and lots of interest in better
support for operational state.

I find the division between NETMOD and NETCONF labor
to be artificial, since so many NETMOD drafts specify
YANG extensions that change NETCONF protocol behavior.
I don't think a very good solution will be reached
for operational state unless the charters are coordinated better.

I also wonder why the IESG will approve a charter item for
Reverse SSH to be done in the NETCONF WG, or why they will
like it now when they did not at the Call-home BoF several years
ago.

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 13 Apr 2013 12:50:16 +0200

> YANG extensions that change NETCONF protocol behavior.

While I might agree on your general statement, I disagree with the
argument you bring forward. I think none of the current NETMOD I-Ds
has a YANG extension that changes the NETCONF protocol behaviour.

/js

-- 
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: Andy Bierman <[email-masked]>
Date: Sat, 13 Apr 2013 06:40:02 -0700

> has a YANG extension that changes the NETCONF protocol behaviour.

I was referring to the work on operational state.
I assume that the current NETMOD drafts will eventually
be finished this year.

IMO any YANG module that even slightly breaks the contract
established by base:1.1 or standard capabilities is not
acceptable, so changing the protocol via YANG modules
is not going to work (for operational state and in general).

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 13 Apr 2013 17:13:29 +0200

> is not going to work (for operational state and in general).

Again, the operational state discussion was in NETCONF not NETMOD.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Apr 2013 08:35:14 -0700

> Again, the operational state discussion was in NETCONF not NETMOD.

I must be thinking of draft-bjorklund-netmod-operational-00,
which expired 5 days ago.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 13 Apr 2013 20:20:22 +0200

> which expired 5 days ago.

An individual submission under a name picked by an individual. The
discussion of this I-D took place in the NETCONF WG meeting at the
last IETF:

http://tools.ietf.org/wg/netconf/agenda?item=agenda-86-netconf.html

While it may make sense to merge NETCONF/NETMOD, I disagree with "many
NETMOD drafts specify YANG extensions that change NETCONF protocol
behavior".

Coming back to the topic of this thread, I think the NETCONF community
needs to prioritize the various work items that have been proposed (in
square brackets people who have worked on this):

- call home for tls				[Juergen]
- call home for ssh				[Kent]
- handling operational state			[Martin]
- improved retrieval (get2)			[Andy]
- alternate encodings				[Lada, Andy]
- mechanisms to comment out config		[Kent]
- REST API to access NETCONF datastore(s)	[Martin, Andy]
- advancement of RFCs				[Bert, Mehmet]
- ...

Right now, it seems contributors want to run into different directions
or all directions at the same time. The list may be incomplete or
incorrect but it is necessary that we find a way to prioritize all
these things.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Apr 2013 11:41:11 -0700

> NETMOD drafts specify YANG extensions that change NETCONF protocol

I did not say merge -- I said coordinate the charters better.  Big difference.

> incorrect but it is necessary that we find a way to prioritize all

Agreed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Apr 2013 11:47:04 -0700

...
> I did not say merge -- I said coordinate the charters better.  Big difference.

IMO, we should be feature oriented.  We decide what feature
to work on, and write charter proposals for all the WGs involved
(probably just NETCONF and NETMOD).

We figure out at the start what work is needed in each WG
and all WG charters have to be aligned and all
have to get approved, or none of them get to be done.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 13 Apr 2013 21:09:49 +0200

> I did not say merge -- I said coordinate the charters better.  Big difference.

The existing charters are IMHO well coordinated - I do not know what
should have been done better in terms of separating protocol work from
data modeling work.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 13 Apr 2013 22:39:36 +0200 (CEST)

> NETMOD drafts specify YANG extensions that change NETCONF protocol

And, for the record, this draft does not change the behavior of
existing NETCONF protocol behavior.  It adds new optional operations
to NETCONF.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Apr 2013 14:47:58 -0700

> existing NETCONF protocol behavior.  It adds new optional operations

IMO <edit-operational> breaks the base:1.1 contract because
a base:1.1 client does not know about <edit-operational>.
It will think that only special leafs (like duplex=auto)
are allowed to have a different operational value than
the configured value.

A "new client" using <edit-operational> can break a
compliant base:1.1 client using the same server.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 14 Apr 2013 00:00:11 +0200 (CEST)

> compliant base:1.1 client using the same server.

No.  An old client will never do <get-operational>, so it will do
<get> or <get-config>.   This document does not change the behavior of
these operations.  If an old client performs <get> on a node that is
config true, it will receive the running config's value, as defined in
RFC 6241.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 15 Apr 2013 13:27:14 +0200

I agree with the need for call home. It is the highest priority at the 
moment for Ericsson.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Apr 2013 07:49:21 -0700

> I agree with the need for call home. It is the highest priority at the

Does this mean that somebody from Ericcson (you?) is going to author
drafts and/or review drafts, and continue doing so until the work item
is published as an RFC?

When prioritizing work, I think it is important to identity resources,
since "wanting X" and "willing to work on X" are not the same thing.
Getting drafts started is easy in the IETF.  Getting drafts finished
is the hard part.

Andy

>> we discussed in the IETF #86 Netconf session on resurrecting and
>> developing the call home mechanism, i.e. initiation of session establishment
>> by the server. The session attendees supported the development of call home
>> for both, the SSH and TLS transport bindings.
>>
>> For the SSH binding, Kent Watsen volunteered to update his draft on
>> Reverse SSH. Concerning the TLS binding, the authors of the rfc5539bis draft
>> agreed to add the necessary text for call home. Based on the session
>> agreement, the co-chairs promised to verify the WG support on the mailing
>> list and add call-home for the ssh and tls drafts to the charter.
>>
>> If there are no substantial arguments against developing call home as
>> planned by April 26, 2013 EOB, the co-chairs will add following addition to
>> the charter and provide our AD to review and initiate the IESG approval.
>>
>> Whether point 3. on the list below remains in the charter depends on the
>> response we get to the call on RFC advancement until May 1st.
>>
>> Draft authors: Please confirm or comment the deadlines listed in the
>> charter text below with a short note to the co-chairs.
>>
>> Bert & Mehmet
>>
>>
>>    Aug 2013 - Possibly submit RFC6241/6242 implementation/deployment
>> experience doc to IESG for publication as Informational RFC
>>

---

From: t.petch <[email-masked]>
Date: Thu, 18 Apr 2013 10:34:36 +0100

I find this premature.

The issue, as has come up many times before, on this and on other lists,
is security.

I think that the starting point should be a review of existing call home
mechanisms, how they provide security and how appropriate they are for
Netconf.  Then we can look at whether or not an SSH or TLS based design
is viable.

Tom Petch

p.s. My prejudice is dead against call home.  I see it over and over
again on a Windows (the commonest in the world by a big margin:-)
workstation - i.e. server in the context of call home - which wants to
update its software from websites such as Adobe and Microsoft ('Updates
are available').  NO, I do not want the software trashed by who knows
what!  When I am sitting at the workstation, I expect to be able to stop
it, but yesterday, I got outmanoeuvred by Microsoft:-(

Oddly, I do trust the downloads to my set-top box, don't know why,
perhaps because I have less to lose if that gets trashed.

----- Original Message -----
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 12, 2013 2:29 PM
Subject: [Netconf] Developing Call-Home for the SSH and TLS transport
bindings - New Charter text

> we discussed in the IETF #86 Netconf session on resurrecting and
developing the call home mechanism, i.e. initiation of session
establishment by the server. The session attendees supported the
development of call home for both, the SSH and TLS transport bindings.
> For the SSH binding, Kent Watsen volunteered to update his draft on
Reverse SSH. Concerning the TLS binding, the authors of the rfc5539bis
draft agreed to add the necessary text for call home. Based on the
session agreement, the co-chairs promised to verify the WG support on
the mailing list and add call-home for the ssh and tls drafts to the
charter.
> If there are no substantial arguments against developing call home as
planned by April 26, 2013 EOB, the co-chairs will add following addition
to the charter and provide our AD to review and initiate the IESG
approval.
>
> Whether point 3. on the list below remains in the charter depends on
the response we get to the call on RFC advancement until May 1st.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 18 Apr 2013 17:26:47 +0000

Tom,

We have SPs and Fortune 500 customers that require a call-home mechanism,
in order to manage devices deployed behind NAT gateways.  These customers
are already committed to using an EMS/NMS, call-home is merely a mechanism
to let that happen in certain deployment scenarios.

Thanks,
Kent

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 19 Apr 2013 12:27:14 +0200

Hello ,
In my view call-home will happen, even if it has security problems. The 
real question is just  whether IETF will provide a solution, or whether 
every interested vendor makes his own.
regards Balazs

> Getting drafts started is easy in the IETF.  Getting drafts finished
[BALAZS]: I would love to work on it, but I am not able to. So I am just 
hoping someone will do it. (I agree with your point.)

---

From: Carl Moberg <[email-masked]>
Date: Fri, 19 Apr 2013 09:19:48 -0700

Just to add to this. We need this for scalable discovery of new physical and virtual devices as they arrive on the network. The current state of the art is ping sweeps and highly proprietary probing of neighbour states.

--
Carl Moberg
twitter: @cmoberg
http://www.tail-f.com/

---

From: t.petch <[email-masked]>
Date: Fri, 19 Apr 2013 18:03:06 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Ersue, Mehmet (NSN - DE/Munich)"
<[email-masked]>; <[email-masked]>
Sent: Thursday, April 18, 2013 6:26 PM

Tom,

We have SPs and Fortune 500 customers that require a call-home
mechanism,
in order to manage devices deployed behind NAT gateways.  These
customers
are already committed to using an EMS/NMS, call-home is merely a
mechanism
to let that happen in certain deployment scenarios.

<tp>
Yes, they are probably the same companies who regard NAT as adequate
security:-)

We have a responsibility to provide technology that does not
do harm.  Call home without adequate security may not meet that so I
still say that a review of security, across the many existing instances
of call home, is the starting point, not a design.

Tom Petch
</tp>
Thanks,
Kent

On 4/18/13 5:34 AM, "t.petch" <[email-masked]> wrote:

>>   May 2013 - Collect Implementation/Deployment reports for RFC6241
and
>6242