Subject: Re: [OPS-AREA] [Isms] status and future of the isms working group

From: "t.petch" <[email-masked]>
Date: Mon, 20 Sep 2010 09:28:49 +0200

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David Harrington" <[email-masked]>; "Eliot Lear" <[email-masked]>;
<[email-masked]>; "Ron Bonica" <[email-masked]>
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.

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.

Tom Petch

>
> 2. I think this discussion exceeds the scope of ISMS. I suggest to move
> it on [email-masked]
>
> Dan
>
>
> > -----Original Message-----
> > From: David Harrington [mailto:[email-masked]]
> > Sent: Friday, September 17, 2010 4:24 PM
> > To: 'Eliot Lear'; [email-masked]; 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-masked]]
> > > Sent: Friday, September 17, 2010 9:48 AM
> > > To: David Harrington; [email-masked]; '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-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 12:28:06 +0200

Hi Tom,

See in text. 

Regards,

Dan

> From: t.petch [mailto:[email-masked]] 
> Sent: Monday, September 20, 2010 9:29 AM
> To: Romascanu, Dan (Dan); David Harrington; [email-masked]; Ron Bonica
> Cc: [email-masked]
> To: "David Harrington" <[email-masked]>; "Eliot Lear" 
> <[email-masked]>; <[email-masked]>; "Ron Bonica" <[email-masked]>
> > 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 

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-masked]
> >
> > Dan
> >
> >
> > > 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.
> > > We only got to modify the architecture in ISMS when we needed to 
> > > define a transport subsystem in rfc5590.
> > > 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
> 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
> > >
> > >
> > > > >> I would like to recommend a new work item for ISMS - 
> design a 
> > > > >> new
> > >
> > > > >> architectural models used for Netconf [RFC 4741, 
> section 1.1] 
> > > > >> and
> > >
> > > > > likely located in the OPS area not in the security 
> area (as can 
> > > > > be
> > >

---

From: "t.petch" <[email-masked]>
Date: Mon, 20 Sep 2010 11:57:49 +0200

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "t.petch" <[email-masked]>; "David Harrington"
Cc: <[email-masked]>
Sent: Monday, September 20, 2010 12:28 PM

<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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 20 Sep 2010 10:04:37 -0700

Hi -

> From: "t.petch" <[email-masked]>
...
> off the bottom of the radar; why should we do any better this time?
...

The problem as I see it was that RFC3411 was intended to be the glue
describing how a particular set of specifications fit together, *not* as
*the* architecture for all future SNMP work.  *Requiring* extensions,
additions, and embellishments to adhere to that architecture is in
my opinion a huge mistake.  From my perspective, the real problem
addressed by RFC 3411 was that some of the preceding proposals
for securing SNMP had so many convolutions and interactions that
a lot of folks had trouble wrapping their heads around them.  The
modularity brought by RFC 3411 was modularity of *specification*,
not necessarily implementation.  The ASIs were rather controversial
because folks were (rightly, in retrospect) concerned that they would
be understood in a prescriptive sense, rather than descriptive sense
in which they were intended.

More importantly, I think focusing energy on this "problem" (which is
tempting because it's something we think we understand) would be
a huge distraction from the *real* problem: the kinds of information models
this infrastructure should provide access to.  If the information models
can't support the high-value functions administrators / operators need,
then embellishing the protocol engine architecture is a waste of time.

Randy

---

From: Jon Saperia <[email-masked]>
Date: Mon, 20 Sep 2010 13:43:43 -0400

I could not agree more. 

I would add  that additional protocol/architecture/framework on any of the management infrastructures we have does not address the key point I took from Randy's post.  What we need are widely implemented objects (however you want to call the structures) that give real visibility into what is going on in the devices and networks.  That has always been the problem and until we address that who cares how we transport the data. I would settle for RFC2549, if it contained the right information.

/jon
On Sep 20, 2010, at 1:04 PM, Randy Presuhn wrote:

> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 20 Sep 2010 11:43:29 -0700

>>>>> On Mon, 20 Sep 2010 09:28:49 +0200, "t.petch" <[email-masked]> said:

tp> RFC3411 was a great piece of work, but turned out to be fatally
tp> flawed.  The first time it was put to the test, introducing a new
tp> security model, it proved unusable.

Well, I'm not sure that's an entirely fair characterization.  The
problem wasn't that the model was flawed, it was that it wrapped *only*
around its own notion of the SNMP protocol.

When ISMS came along and the decision was to outsource the security to
something in a lower layer, then yes the original model had issues with
that because it didn't take that possibility into account.  5590 simply
fixed that.  Interestingly enough by providing some extra transmission
lines to the model and extra information to the data passed via the
ASIs.

However, the ISMS solutions were the first "standardized" ones.  More
documents and code have been written to provide other security models
that were either implemented or partially implemented and worked just
fine without changing the underlying 3411 model: KSM (which is now being
brought forward again) and SBSM (which is how the ISMS working group got
started but went the SSH-underneath route instead of an
in-SNMPv3-protocol integrated model).
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "t.petch" <[email-masked]>
Date: Mon, 20 Sep 2010 22:31:33 +0200

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "David Harrington"
<[email-masked]>; <[email-masked]>; "Ron Bonica" <[email-masked]>;
<[email-masked]>
Sent: Monday, September 20, 2010 8:43 PM
> lines to the model and extra information to the data passed via the

Well, yes and no.  In isms, we retained the idea of 'no sessions', and I was
interested to see in the most recent I-D ....  vacmAaaSessionID OBJECT-TYPE

I always thought that SNMP had sessions, just that some of them were rather
short, and I that that is another disconnect that took quite a lot of time to
sort out in the isms work; it would have been easier if RFC3411 or RFC5590 had
had sessions in the architecture.

And yes, I am making my point quite strongly, because I think that an 'RFC6411'
would be a poor use of IETF resources.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 20 Sep 2010 17:30:52 -0700

>>>>> On Mon, 20 Sep 2010 22:31:33 +0200, "t.petch" <[email-masked]> said:

tp> And yes, I am making my point quite strongly, because I think that
tp> an 'RFC6411' would be a poor use of IETF resources.

Well, I won't dive into "sessions" because it's way beyond a useful
argument at this point.

But, I will agree I don't think the WG should go down the path of
defining a new architecture.  It just won't help much.

As I've said before, I think it's more important that developers can or
can't make the changes need to create a feature.  The architecture was a
way to say "if you can make the architecture bend in this way, then all
the implementations should".  But because we can, in general, enumerate
the SNMPv3 stack implementations on one hand it's not hard to survey
them and say "could you implement this new feature of the protocol in
your implementation"?

Trying to define a model that will always account for every way you
might need to break the rules in the future is an impossible task.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "t.petch" <[email-masked]>
Date: Tue, 21 Sep 2010 16:22:42 +0200

----- Original Message -----
From: "Jon Saperia" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, September 20, 2010 7:43 PM

> I could not agree more.
>
> I would add  that additional protocol/architecture/framework on any of the
management infrastructures we have does not address the key point I took from
Randy's post.  What we need are widely implemented objects (however you want to
call the structures) that give real visibility into what is going on in the
devices and networks.  That has always been the problem and until we address
that who cares how we transport the data. I would settle for RFC2549, if it
contained the right information.
Jon

My current hot button is not data but protocols.  I am worried about the
explosion in 'OAM' (ie ping, traceroute etc) protocols to run in the MPLS
dataplane, that are being defined in the MPLS-TP nexus.  Before long, we might
have Y.1731 as a standards track RFC:-(

I was relieved to see the IESG sending back
draft-ietf-opsawg-mpls-tp-oam-def
but what happens next, metaphorically speaking? I would rather more people with
a background in the IETF were involved with this.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Tue, 21 Sep 2010 12:24:05 -0400

Tom,

you're mixing two different issues. Sure they intersect, but they are
different problems.

This discussion started as a suggestion that RFC3411 "An architecture
for Describing SNMP Frameworks" be suppplemented with a simpler
architecture document so doing work on SNMP specifications stopped
being so onerous. The ISMS work was tremendously difficult because we
were required by charter to abide by the RFC3411 architecture. (This
whole issue could be made easier of the area directors didn't insist
on RFC3411 being THE architecture, rather than "AN" architecture, as
it was designed to be.)

As part of that suggestion, I also suggested updating the SNMP
applicability statetment, RFC3410, to reflect current thinking of SNMP
being applicable primarily for monitoring, Netconf for config, syslog
for logging, and ipfix for flow monitoring. These are all "vertical"
network management protocols that operate at layer 7, and make
information available from multiple layers of instrumentation. 

The OAM issue you are raising is about "horizontal" protocols that
operate within-layer. This would include protocols like ping,
traceroute, VCCP, and so on. 

I share your concern that the MPLS-TP work is bringing ITU-style OAM
protocols into the IETF, and the OPS area doesn't seem to be paying
much attention to this. draft-ietf-opsawg-mpls-tp-oam-def is under
review for Proposed Standard, and proposes standardizing terminology
for all future IETF documents dealing with OAM + provisioning +
management. I have concerns this will have an immense impact on how
the Internet is managed, without adequate consideration of the impact
outside the MPLS-TP environment. I am seeing portions of Y.1731
slipping into non-MPLS-TP internet-draft proposals (sometimes without
mention of Y.1731). That may or may not be bad, but I think the IETF
needs to be very aware that this is happening. 

I also have concerns that much of the recent work in v6ops seems to be
heavily influenced by ongoing 3GPP work. That also may or may not be
bad, but I think the IETF needs to be very aware that this is
happening.

We are a volunteer organization and if most volunteers want to work
only on their own protocols and put blinders on regarding the larger
trends that are happening around them, that is their choice. I'm sure
some have paid attention, and maybe they are not concerned about this
trend.

If you are really worried about the explosion in OAM, and Y.1731 in
particular, maybe you should do a presentation at the OPSAREA meeting
explaining how Y.1731 works, and why it might be bad for the Internet.

dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Tuesday, September 21, 2010 10:23 AM
> To: Jon Saperia; Randy Presuhn
> Cc: isms; [email-masked]
> Subject: Re: [OPS-AREA] [Isms] status and future of the isms 
> working group
> 
> > I would add  that additional 
> protocol/architecture/framework on any of 
> > the
> management infrastructures we have does not address the key 
> point I took from Randy's post.  What we need are widely 
> implemented objects (however you want to call the structures) 
> that give real visibility into what is going on in the 
> devices and networks.  That has always been the problem and 
> until we address that who cares how we transport the data. I 
> would settle for RFC2549, if it contained the right information.
> >
> Jon
> 
> My current hot button is not data but protocols.  I am 
> worried about the explosion in 'OAM' (ie ping, traceroute 
> etc) protocols to run in the MPLS dataplane, that are being 
> defined in the MPLS-TP nexus.  Before long, we might have 
> Y.1731 as a standards track RFC:-(
> 
> draft-ietf-opsawg-mpls-tp-oam-def but what happens next, 
> metaphorically speaking? I would rather more people with a 
> background in the IETF were involved with this.
> 
> Tom Petch
> 
> > /jon
> > >> 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
> > > *the* architecture for all future SNMP work.  *Requiring* 
> > > extensions, additions, and embellishments to adhere to that 
> > > architecture is in my opinion a huge mistake.  From my 
> perspective, 
> > > the real problem addressed by RFC 3411 was that some of the 
> > > preceding proposals for securing SNMP had so many 
> convolutions and 
> > > interactions that a lot of folks had trouble wrapping their
heads 
> > > around them.  The modularity brought by RFC 3411 was 
> modularity of 
> > > *specification*, not necessarily implementation.  The ASIs were 
> > > rather controversial because folks were (rightly, in retrospect)

> > > concerned that they would be understood in a prescriptive sense,

> > > rather than descriptive sense in which they were intended.
> > >
> > > More importantly, I think focusing energy on this 
> "problem" (which 
> > > is tempting because it's something we think we 
> understand) would be 
> > > a huge distraction from the *real* problem: the kinds of 
> information 
> > > models this infrastructure should provide access to.  If the 
> > > information models can't support the high-value functions 
> > > administrators / operators need, then embellishing the 
> protocol engine architecture is a waste of time.
> > >
> > > Randy
> > >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 21 Sep 2010 18:43:53 +0200

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Tuesday, September 21, 2010 6:24 PM
> To: 't.petch'; 'Jon Saperia'; 'Randy Presuhn'
> Cc: [email-masked]
> Subject: [OPS-AREA] RFC3411 discussion versus OAM + P + Mgt discussion
> 
> Tom,
> 
> you're mixing two different issues. Sure they intersect, but 
> they are different problems.
> 
> This discussion started as a suggestion that RFC3411 "An 
> architecture for Describing SNMP Frameworks" be suppplemented 
> with a simpler architecture document so doing work on SNMP 
> specifications stopped being so onerous. The ISMS work was 
> tremendously difficult because we were required by charter to 
> abide by the RFC3411 architecture. (This whole issue could be 
> made easier of the area directors didn't insist on RFC3411 
> being THE architecture, rather than "AN" architecture, as it 
> was designed to be.)
> 
> As part of that suggestion, I also suggested updating the 
> SNMP applicability statetment, RFC3410, to reflect current 
> thinking of SNMP being applicable primarily for monitoring, 
> Netconf for config, syslog for logging, and ipfix for flow 
> monitoring. These are all "vertical"
> network management protocols that operate at layer 7, and 
> make information available from multiple layers of instrumentation. 
> 

This walks, sounds and looks like a new architecture but if you want to
call it something different I am fine. I think that we need it. I do not
see the resources volunteering to write it, but if there are interested
parties to work on this I am in full support. 

> 
> If you are really worried about the explosion in OAM, and 
> Y.1731 in particular, maybe you should do a presentation at 
> the OPSAREA meeting explaining how Y.1731 works, and why it 
> might be bad for the Internet.
> 
> dbh
> 

Indeed. We still have open slots on the agenda of the OPS-AREA open
meeting in Beijing, and we can accommodate such a presentation followed
by a discussion. 

Dan

---

From: "t.petch" <[email-masked]>
Date: Thu, 23 Sep 2010 14:31:23 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
Sent: Tuesday, September 21, 2010 6:24 PM

> traceroute, VCCP, and so on.

Well, when OAM (mpls-tp style) estimates one way delay variation, I call that an
application.  And if you exclude such OAM from your 3410bis, then you
are, for me, redefining network management  to exclude OAM.  I continue
to see little difference between, say, ipfix and estimating one way delay
variation
( or measuring SD in order to decide when to switch to protection or ...); and I
want the exact opposite, I want inclusion.

Tom Petch