Re: ISMS working group and charter problems

Juergen,

> 1) I see lots of people using tools like MIB browsers, snmp command line
>    tools called from fancy scripts, monitoring packages such as cacti
>    and nagios (these were even used on the IETF network in Paris if I
>    recall correctly) and all these packages share the feature that the
>    "manager" does not have a fixed transport address but takes the
>    initiative to talk to an "agent" when there is need to do so. In
>    other words, all these existing and deployed applications simply
>    won't work with call home easily since they would require to
>    implement some rather magic logic to dispatch SNMP traffic via
>    a locally centralized connection manager.

Indeed I do not advocate deleting the existing model where the manager
contacts the agent.  But the tools you mention will almost assuredly
need to be modified no matter the outcome of this debate, because they
will need to incorporate SSH.

> 
> 2) [Consider SSH, and not just TCP aspects]

I agree, and Keith McCloghrie has answered this question better than I
could.

> 
> 3) For those not following ISMS closely, it might be useful to know
>    that originally was another proposal (EUSM) which tried to build on
>    USM messages and tried to integrate USM with AAA infrastructures.
>    This approach did have some rough support but did melt down because 
>    of some inappropriate use of EAP. (I can't explain the details since
>    I never really understood the _technical_ concern.) Once EUSM was
>    off the table, the WG converged to SSH for a very simple reason:
>    SSH is already on many routers/bridges/hosts and you find it even
>    on power strips these days. Netconf also requires SSH as the
>    mandatory to implement transport. Hence, using SSH as a unifying
>    mechanism to securely access the various management interfaces
>    on a box has some promises wrt. ease of deployment.

This jives with my understanding of the group's logic.

> 
> I agree with those who said that CH is an architectural change and I
> have yet to see a concrete proposal how CH via ssh can be achieved.

Funny you should mention this.  I've mentioned several approaches on
this list and others several times, while the group converged on using
SSH without having a single draft available at the time.  It was indeed
impressive that the group had gone from (at least) four separate viable
drafts down to zero by the end of IETF-63.

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf