Re: [Isms] status and future of the isms working group

"t.petch" <[email protected]>
Newsgroups gmane.ietf.ops
Message-ID <[email protected]>
----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email protected]>
To: "t.petch" <[email protected]>; "David Harrington"
Cc: <[email protected]>
Sent: Monday, September 20, 2010 12:28 PM
> -----Original Message-----
> From: t.petch [mailto:[email protected]]
> Sent: Monday, September 20, 2010 9:29 AM
> To: Romascanu, Dan (Dan); David Harrington; [email protected]; Ron Bonica
> Cc: [email protected]
> Subject: Re: [Isms] status and future of the isms working group
>
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[email protected]>
> To: "David Harrington" <[email protected]>; "Eliot Lear"
> <[email protected]>; <[email protected]>; "Ron Bonica" <[email protected]>
> Sent: Friday, September 17, 2010 4:37 PM
>
> > 1. I agree that it's time to think about a new architecture
> which is
> > multiprotocol and does not impose the restrictions that
> 3411 had put
> > on SNMP. This work should start from the usage scenarios for SNMP,
> > NETCONF and other protocols and how we see them used by
> operators in
> > real life deployments. The example given by David was maybe talked
> > about many times, but was not (to my knowledge) put in any document.
>
> RFC3411 was a great piece of work, but turned out to be
> fatally flawed.  The first time it was put to the test,
> introducing a new security model, it proved unusable.  At the
> same time, the IESG said it was immutable and the isms
> working group wasted years squaring that circle, producing
> RC5590 which is, to any independent observer, replacing parts
> of RFC3411.  So great piece of work, causing much damage.
> With the benefit of hindsight, the isms working group should
> have said 'Mission Impossible' and refused to continue until
> it was allowed to replace RFC3411 (but I did not see that
> until 2008:-(
>
> I see no reason to suppose we would do any better now, be it
> a single or multi protocol architecture.

Does this mean that we should not / need not try?

<tp>
I think that our resources are limited, and tend to decay with the age of a
working group, so I would rather see them applied elsewhere.  I look back at the
effort that went into RFC3411, over many years, and yet it fell at the first
hurdle, not accommodating the move of security from deep inside the engine to
off the bottom of the radar; why should we do any better this time?

I see comparisons with the architecture of syslog and netconf, and yet ...
There is a structure of layers, hardly an architecture.  syslog was doing nicely
without it, and I am not sure that it is any better with it.  netconf has been
debating recently how and where the messages should be delineated within a
stream transport, with various views of what it means in architectural terms,
yet I see the architecture as no help in resolving the issue of delineation.

So, potentially much work, for little or no gain.

Tom Petch

>
> At the same time, there is activity currently taking the
> Management out of OAM, in the mpls-tp nexus but in other
> related activities as well and it is that that I think needs
> tackling.  What is management?  Can we agree an IETF wide
> definition any more? I see draft-ietf-opsawg-mpls-tp-oam-def
> as just the tip of this iceberg.
>

One of the points that draft-ietf-opsawg-mpls-tp-oam-def makes is that
management is not part of OAM, the M in the trinity standing for
Maintenance. Right now draft-ietf-opsawg-mpls-tp-oam-def is being
returned by the IESG to the OPSAWG with the recommendation to broaden
its scope beyond mpls-tp. I would agree that it's still the tip of the
iceberg.

> Tom Petch
>
>
>
>
> >
> > 2. I think this discussion exceeds the scope of ISMS. I suggest to
> > move it on [email protected]
> >
> > Dan
> >
> >
> > > -----Original Message-----
> > > From: David Harrington [mailto:[email protected]]
> > > Sent: Friday, September 17, 2010 4:24 PM
> > > To: 'Eliot Lear'; [email protected]; Romascanu, Dan (Dan);
> 'Ron Bonica'
> > > Subject: RE: [Isms] status and future of the isms working group
> > >
> > > Hi,
> > >
> > > NMRG worked on information/data models (RFC3444) and XML-based NM
> > > (e.g., through proxies).
> > >
> > > I don't believe NMRG ever tried to write a new SNMP architecture
> > > document.
> > > and in the IETF, WGs have been told that modifying the RFC
> > > 3411 architecture is definitely out of scope.
> > > The EOS and SMING and ISMS WGs were all told to "work within" the
> > > RFC3411 architecture.
> > > I think that restriction was part (but only part) of the
> reason for
> > > the failures of EOS and SMING.
> > > We only got to modify the architecture in ISMS when we needed to
> > > define a transport subsystem in rfc5590.
> > > So I don't agree this has been tried before.
> > >
> > > I think SNMP could be brought out of the 1980's, but
> first we need
> > > to make it easier to add new features, such as new
> operations, and
> > > new data modeling approaches. I think the
> > > RFC3411 architecture makes it so hard to write any
> extensions, even
> > > models that fit within the RFC3411 architecture, that it greatly
> > > increases the complexity.
> > > A simpler architecture would allow SNMP to be maintained
> and updated
> > > more easily.
> > >
> > > Netconf can certainly do some of the things that an extended SNMP
> > > might, but netconf is designed for a different usage scenario. I
> > > certainly would think twice about using Netconf to
> repeatedly poll
> > > sysuptime from multiple devices across my network as a
> liveness and
> > > reachability detector.
> > >
> > > dbh
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eliot Lear [mailto:[email protected]]
> > > > Sent: Friday, September 17, 2010 9:48 AM
> > > > To: David Harrington; [email protected]; 'ext Romascanu, Dan
> > > (Dan)'; Ron
> > > > Bonica
> > > > Subject: Re: [Isms] status and future of the isms working group
> > > >
> > > >  While I agree with Juergen on the logistics, I think Dave
> > > highlights
> > > > interesting work to consider undertaking.  My only concern
> > > is that it
> > > > seems like people have tried to do this before, in
> > > particular in the
> > > > NMRG.  What's the trigger for success?
> > > >
> > > > Eliot
> > > >
> > > > On 9/17/10 12:11 PM, Juergen Schoenwaelder wrote:
> > > > > On Fri, Sep 17, 2010 at 11:57:31AM +0200, David
> Harrington wrote:
> > > > >
> > > > >> I would like to recommend a new work item for ISMS -
> design a
> > > > >> new
> > >
> > > > >> architecture standard for SNMP development.
> > > > >> I recommend developing "A Simple Architecture for Describing
> > > > >> SNMP
> > >
> > > > >> Frameworks" that is more consistent with the simpler layered
> > > > >> architectural models used for Netconf [RFC 4741,
> section 1.1]
> > > > >> and
> > >
> > > > >> Syslog [RFC 5424 section 3], to bring simplicity
> back into SNMP
> > > > >> standards development.
> > > > > ISMS stands for "Integrated Security Model for SNMP" and it
> > > > seems the
> > > > > work you are proposing really calls for a different working
> > > > > group,
> > >
> > > > > likely located in the OPS area not in the security
> area (as can
> > > > > be
> > >
> > > > > seen by the ADs you have put on the CC).
> > > > >
> > > > > /js
> > > > >
> > >
> > >
> > _______________________________________________
> > Isms mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/isms
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.