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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 18 Aug 2005 14:21:25 +0200

Eliot, whatever proposal you have for NetConf should go to
that WG and not to this list (or so I think). That WG
will/can deal with your comment/proposal.

Bert

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Thursday, August 18, 2005 13:26
> To: Wijnen, Bert (Bert); [email-masked]; Margaret Wasserman; 
> Andy Bierman
> Subject: Re: [Isms] RE: Call for consensus and a proposal
> 
> 
> 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.
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Aug 2005 17:06:39 +0200

> will/can deal with your comment/proposal.

Bert, just to be clear, the proposal is for BOTH groups.

Eliot