Subject: Re: [Isms] RE: Call for consensus and a proposal

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2005 09:19:15 -0700

Hi Eliot,

I cc:ed the NETCONF WG because you are proposing changes to NETCONF over SSH
to the ISMS WG.

In theory, I agree with your goal of a single transport for both NETCONF 
and ISMS,
and I like your proposal.  If it had been on the table at the interim 
meeting where this
was all worked out,  I think it would have been selected the one and 
only NETCONF transport.

However, the NETCONF WG took a long time to decide on 3 different 
transports.
I don't really know how useful NETCONF over SOAP is going to be, but I 
bet a few
people would complain if we told them (at the last minute) that NETCONF 
over BEEP
is being removed. (It's not!)

Any new NETCONF features need to be done as proprietary extensions first,
shown to be useful in real operator environments, and then gain wide 
acceptance
from the WG.  I would support new NETCONF work today that met this criteria.

Andy

>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.
>
>
>  
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>