NSP should imply additional Networking services beyond what an ISP
traditionally offers.
The reason for a split like this is NSP's tend to have LARGE FAST
backbones and LOTS of routers.
ISP's may have a single router with fairly low bandwidth. They may also
sell basically ONE service (dialup, wireless ...).
I would be just as willing to call such providers SSP (small service
providers | simple service providers) but do not want to insult anyone
or any company.
I think the reason for a split like this would be because of the order
of magnitude difference in complexity when you have to manage 100's of
routers in lots of cities with 1000's of dynamic routes (NSP) vs 1 (or
10) router(s) a single static default route to an NSP (SSP|ISP).
George do we want/need a category for CSP Content service provider. Some
ISP's are moving away from providing ANY network connectivity. They
provide content and host mail/ personal web pages etc... but do NOT sell
the customer any network access. This model is becoming popular. They
would not be doing routing for the customers.
Finally I think ATM providers and other L1, L1, L3 network providers
could be covered by the NSP class but am not sure if the model will fit.
Donald.Smith@qwest.com GCIA
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC
pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC
Brian Kernighan jokingly named it the Uniplexed Information and
Computing System (UNICS) as a pun on MULTICS.
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
> Behalf Of George Jones
> Sent: Thursday, June 03, 2004 4:59 AM
> To: Ross Callon
> Cc: opsec@ops.ietf.org
> Subject: Re: Straw-man charter
>
>
> On Wed, 2 Jun 2004, Ross Callon wrote:
>
> > > The working group will produce requirements appropriate for:
> > >
> > > * Network Service Providers (NSP) Networks
> > > * Internet Service Provider (ISP) Networks
> > > * Enterprise Networks
> >
> > Is it clear what a "Network Service Provider" is? From the
> context, I
> > am figuring that it whomever offers a network service other than
> > Internet and Enterprise networks. This seems to include Layer 3 VPN
> > services. Does it also include Layer 2 VPN services? Does
> it include
> > ATM services?
>
> You're right. Definition is needed here. I was mainly trying
> to draw a distinction between large nets that provide a good
> deal of transit and
> joe-I-have-a-T1-and-provide-wireless-to-my-neighbors.
>
> Do others (Don Smith, Steve Matkoski, Fred Budd ?) have
> thoughts on defining this split ?
>
> >
> > > Once these are done, it may be appropriate to broaden
> the scope (and
> > > recharter) to address the operational security
> requirements of of:
> >
> > This sentence doesn't quite read the way that charters
> typically read,
> > and might be interpreted as saying that these *will* be
> added, rather
> > than *might* be added. How about:
> >
> > The following areas are excluded from the charter at this
> time. They
> > may be considered for inclusion in an updated charter at a later
> > time:
>
> OK.
>
> > >Methods
> > >
> > > A road-map document will be produced describing the
> scope, format,
> > > intended use and sequence of future documents. A series
> of small BCP
> > > documents will be produced covering various areas of security
> > > management functionality...
> >
> > Very minor nit: I would leave out the word "small", on the basis
> > >that the size
>
> OK.
>
> > > Much of the operational security knowledge that needs
> to be codified
> > > resides with operators. Operators have shown a tendency
> to be too busy
> > > with day-to-day operations to be as involved in
> standards bodies as
> > > one would hope. They have shown a greater tendency to
> be involved in
> > > operators forums such as NANOG and RIPE. In order to
> access their
> > > knowledge and reach the working group goal, interim
> meetings may be
> > > held at such operator forums.
> >
> > How about abbreviating this to:
> >
> > Much of the operational security knowledge that needs to
> be codified
> > resides with operators. In order to access their
> knowledge and reach
> > the working group goal, interim meetings may be held at
> operator forums
> > such as NANOG and/or RIPE.
>
> OK.
>
> >
> > >Goals and Milestones:
> > >
> > > Jun 04 Hold charter discussions on mailing list,
> > > identify chair+authors, submit charter
> > >Jul 04 Schedule Working Group
> > >Aug 04 Working Group Meeting @ San Diego
> > >Sep 04 Submit Roadmap Draft
> >
> > This is rather optimistic.
>
> That's why we're involving seasoned IETF pros :-)
>
> I think that we will be doing well to have an 80%
> > complete draft by September, as a working group document.
> There might
> > still be some discussion regarding what should be in the
> roadmap. It
> > will take some work to get this 100% completed and through working
> > group last call. I would expect that two IETFs later would be more
> > realistic (which puts it out to March 2005).
>
> Does it make sense to try to list the other documents before
> the roadmap is hammered out ? Would it make sense for the
> initial charter just to list the path to the roadmap document
> with the understanding (stated in the charter) that the
> milestones for the other docs will be set once it is agreed
> what they are ?
>
> >
> > >Oct 04 Submit In-Band, OoB and Interface Reqs Drafts
> > >Oct 04 Interim meeting @ NANOG
> > >Nov 04 Working Group Meeting @ Washington, Roadmap to IESG
> > >Dec 04 Submit Stack, Rate Limiting, Filtering Drafts...
> > >Jan 05 In-Band, OoB and Interface Reqs to IESG
> >
> > I would push the other document milestones out a bit also.
>
> If you want to take a stab at a timetable, I'd be all eyes.
>
> >
> > I am not sure whether we explicitly need to mention the interim
> > meeting at Nanog in the charter, although it seems like a
> good idea to
> > have such a meeting.
>
> The first one will serve two purposes. Generation of raw
> ideas/feedback/brainstorming about what's actually used and
> to try to further engage operators who may not attend IETF meetings.
>
> >
> > >.
> > >Aug 05 Working Group Meeting/Wrap up
> >
> > This depends upon what happens after we finish the first charter
> > items. It would seem that at that point we would want to decide
> > whether to wrap-up, or to extend the charter. I don't think that we
> > need to put this line item into the charter.
>
> OK.
>
> >
> > >Internet-Drafts (to be written):
> > >
> > > * OPSEC Roadmap (info)
> >
> > Should we call this "roadmap" or "framework"?
>
> ...or "marching orders arrived at by rough consensus". I'm
> ambivalent. If there's precident, let's follow it.
>
>
> > > * OPSEC IP Stack Requirements (BCP)
> >
> > Is there enough in IP stack to warrant its own document, or should
> > this be put into the "other" document?
>
> Perhaps not now. There used to be more. Here's a case where
> it may not make sense to name exact docs before framework doc
> is worked out.
>
> >
> > > * OPSEC Rate Limiting Requirements (BCP)
> > > * OPSEC Filtering Requirements (BCP)
> >
> > I would tend to put rate limiting and filtering in the same
> document
> > (there are of course a number of different things that you
> can do in
> > response to a filter, which rate limiting only being one of many).
>
> Sure. Let's have the discussion.
>
>
> > > * OPSEC Assurance Requirements Requirements (BCP)
> >
> > I don't understand what this is...
>
> Assurance requirements are things that are neither functional
> (do this) nor documentation, but which give some level
> assurance (or facalitate testing to attain that level of
> assurance) that the device will function as advertised.
>
> The two reqs listed here in the opsec draft are "identify
> source of IP stack" and "identify source of OS". I'm going
> to have a different level of comfort with an single-purpose
> OS developed and proven with formal methods than with, say, a
> commercial OS around which an entire anti-virus industry has
> been built (of necessity).
>
> In addition, having such knowledge allows focused
> testing...it's one thing for the marketing department to say,
> "yes, we've fixed all known bugs in the FOO OS on which our
> product is based", it's another to take it into the lab and
> see it not fall down when hit with all known FOO exploits.
>
> Having this type knowledge assists customers in assuring themselves
> that the procuct is secure. Hence, assurance requirements.
>
> OK, that was more specific and less charter than I wanted to do here.
>
> The assurance and IP stack requirements sections in the opsec draft
> may be small but may not be complete. It may be worth revisiting
> the question "are there other assurance requirements" ? "Are
> there other IP stack requirements"....perhaps the authors of
> the various drafts could drive those discussions.
>
> >
> > > * OPSEC NSP Operational Security Requirements Profile(info)
> > > * OPSEC ISP Operational Security Requirements Profile (info)
> > > * OPSEC Enterprise Operational Security Requirements Profile
> > > (info)
> >
> > I am assuming that the timeframes for these would need to
> be after the
> > other documents are done, on the basis that you can't
> decide whether
> > you need to support a feature until you define what the feature is.
>
> I don't think it would hurt for people to get started on
> profiles before the other docs are worked out....people
> thinking about reqs for one particular environment may come
> up with something that should be included in the BCPs.
> You're right though, the BCPs would have to be published first.
>
> Thanks,
> ----George
>
>