Re: [OPSAWG] [Netconf] guidance on draft-kwatsen-reverse-ssh

["Randy Presuhn" <[e-mail]>]

Hi -

> From: "Andy Bierman" <[e-mail]>
> To: "t.petch" <[e-mail]>; "Kent Watsen" <[e-mail]>; <[e-mail]>; <[e-mail]>
> Sent: Tuesday, July 19, 2011 10:46 AM
> Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh
...
> Here is the original charter text from Eliot Lear:
> 
>     http://www.ietf.org/mail-archive/web/ietf/current/msg38521.html
> 
> Here are David Harrington's slides on why not ISMS:
> 
>     http://www.ietf.org/proceedings/64/slides/callhome-5.pdf
> 
> Here are the Callhome BoF minutes:
> 
>     http://www.ietf.org/proceedings/64/callhome.html
> 
> My recollection of the conclusion was that the problem space was not big enough,
> and an SSH-specific solution was inappropriate.  A more general approach should
> be investigated.
> 
> So almost 6 years have passed, and NETCONF vendors still want a call-home solution for SSH.
> IMO, Ken's proposal should be published (assuming the security experts approve).
> NETCONF notifications are rarely used.  The main reason given is that the client
> connection maintenance is not worth the resources and coding effort.  I think
> call-home for SSH could make NETCONF more deployable.
...

It seems like there were two distinct problem spaces that folks had in mind
during the initial discussions.

One (I'll call it the "narrow" one) is the question of how a device new to the
network lets management know that it exists so that it can be (more fully)
configured. The other (I'll call it the "broad" one) includes the issues of
overcoming NAT.  The original proposed charter text seems consistent
with the narrow space.  Addressing it shouldn't be much work, but would
nonetheless be worthwhile.   The broad problem is a different matter.  David
Harrington's most persuasive arguments were addressed to it, rather than
the narrow problem.

The NETCONF connection maintenance issue Andy raises is really a third
issue, which wasn't germane to the isms discussions.  When talking about
user / vendor needs, it would probably be helpful to indicate which of these
three is "the problem" that needs to be addressed, and the extent to which
solving the others is necessary (or not).

Randy