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

Hi Tom,

See in text. 

Regards,

Dan
 

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

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