Bert,
Forgive me but I'm frustrated. I won't just complain, however. I have
a proposal (I've been chewing on it for a bit). See below.
How could call home functionality possibly have ended up in the charter?
Nobody knew we would come close to using a TCP-based approach until
March when an WG-shaking event occurred. Every approach submitted and
envisioned prior to that was a new security model using the existing UDP
transport.
But we are here now, and we are positioned to either take advantage of
or miss a huge opportunity or create a mess. Anyone who thinks that
firewalls or NATs routinely implement the proxy function of RFC 3413
hasn't taken a good look at the market lately. Let's at least make the
best of the position we find ourselves and take corrective action. I
hate to say it, but take a look at Windows. Most of the time management
connections are issued by clients. Really this is no different.
Let me refresh your and Dave's memory on the matter of NETCONF. The
initial authors of the base spec ALWAYS envisioned a call home function.
We got it for free with BEEP, which was part of the core specification
until the working group forced us to separate out protocol mappings. We
even had it in an early draft of the SSH specification, but cut it out
[too much channel cruft as you may recall]. What's more, I claim it's
easier than ever to do now.
In the netconf ssh draft, what I propose is that we add some text around
the following idea:
- when the manager contacts the agent, it will request the "netconf"
SSH service.
- when the agent contacts the manager, it will request the
"netconf-turn" service (or "netconf-callhome" if you prefer - I
would like to reuse the SMTP term since they invented the concept,
so far as I can recall).
- Add text in security considerations about how to handle identity
for the call home approach. I claim it's No Big Deal. It just
says that the client process for callhome should probably tie to
an appropriately authorized user for the function being managed.
This mechanism has the added benefit of not requiring pre-existing
implementations to change their code. The reason I want it in round one
of netconf is that I would if I could nuke all other transport options
including BEEP. Options are a necessary evil. Transport options are an
UNnecessary evil.
Rinse and repeat. The same process can be applied to SNMP. There is no
difference. Presto. Yes, it took me a few days to come up with this in
a simple way. And yes, there are a few issues surrounding the mapping
for traps, but I claim we can solve those as well to peoples'
satisfaction. What do people think?
The result is a single mandatory transport for both NETCONF AND BEEP.
Similar call home functionality for both.
This is NOT Eliot's "would be nice" for a protocol. It's really
important for our customers. We've always envisioned having call home
functionality in our products. In fact we've had proprietary solutions
for years (which is how we know it's important to our customers). The
other option - and they're already talking about it - is SNMP over SIP.
I kid you not. Sort of makes me think of running IP over a DHCP
option, but heck anything's possible.
In summary, please let's be elegant. Let's kill two birds with one
stone. Let's make it easier on all of our customers in the future. And
let's codify something that everyone else has been doing for years.
My connectivity will be sketchy for the next few days, but will continue
as best I can (although I don't want to beat a dead horse).
Eliot
ps: yes, I've offered to put this into real draft words for Dave.