[Ieprep] Fw: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

Janet P Gunn <jgunn6@csc.com> Thu, 02 November 2006 21:53 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkV0-0000OF-Tw; Thu, 02 Nov 2006 16:53:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfkUz-0000OA-TI for ieprep@ietf.org; Thu, 02 Nov 2006 16:53:21 -0500
Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfkUy-0002wK-Jw for ieprep@ietf.org; Thu, 02 Nov 2006 16:53:21 -0500
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id kA2LrBja019997 for <ieprep@ietf.org>; Thu, 2 Nov 2006 16:53:16 -0500 (EST)
To: ieprep@ietf.org
X-Mailer: Lotus Notes 652HF83 November 04, 2004
Message-ID: <OFDEBE8228.313A25C4-ON8525721A.00782F07-8525721A.00783968@csc.com>
From: Janet P Gunn <jgunn6@csc.com>
Date: Thu, 2 Nov 2006 16:53:10 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 11/02/2006 04:52:09 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Subject: [Ieprep] Fw: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org









----- Forwarded by Janet P Gunn/FED/CSC on 11/02/2006 04:52 PM -----

Pekka Savola <pekkas@netcore.fi> wrote on 11/02/2006 04:16:01 PM:

> On Thu, 2 Nov 2006, James M. Polk wrote:
> > >Having looked at the output of the WG,
> > >it already seems to include a couple of useful framework documents and
> > >about 4 requirements documents.
> >
> > the framework RFCs are for within a single public domain.  The
> other RFCs are
> > requirements based.
> >
> > There is no architecture guidelines docs or peering guidelines or the
like.
>
> I guess by 'architecture guidelines' you refer to inter-domain
> guidelines as the framework RFCs already seem to deal at least to some
> extent with a single domain.  If you don't, you may mean something
> that operators would use.  It's not clear if one-size-fits-all
> guidelines could be made, or if this would be right place to try to
> seek it.
>
> Is there already sufficient experience of getting multi-domain work?
> AFAICS, this hasn't generally been considered an easily solvable
> problem at an operational level.
>
> Peering guidelines likely don't belong to the IETF, or has there been
> successful precendent for that kind of work in the past?  (I could say
> some examples, but I don't think those were very succesful, and those
> were from OPS area)
>
> Even if this work was in the scope of IETF, at least these two seem
> more like subjects to be pursued in the Ops&Mgmt area.
>
> > >This should already provide
> > >sufficient information how to continue the work.
> >
> > continue the work.... where? by who? by another SDO?  Why?
>
> Other SDOs if they're willing.  Organizations that actually want to
> deploy this stuff (if those exist in sufficient degree).  Vendors who
> want to push for this stuff.  That is to say -- is there enough
> deployment (and understanding what works and is deployable and what
> isn't) to justify more IETF work on the subject _right now_ ?
>
> > >Overprovisioning and intra-domain TE seems to have been a
popularapproach,
> >
> > in which IEPREP doc was "Overprovisioning" and "intra-domain TE "
discussed?
>
> draft-ietf-ieprep-domain-frame-07.txt, RFC4190, RFC43745 to name a
> few.
>
> > >but apart from that, where has this been  deployed and how?
> > >
> > >Maybe we should let ITU, vendors, and/or deploying organizations to
> > >apply the existing techniques
> >
> > What "techniques" have been defined?
>
> The framework documents talk a lot about certain kinds of DSCP PHBs,
> mappings between PSTN and VoIP, a particular end-to-end priority
> field, MPLS-like traffic engineering, access-controls to prevent
> DoSing priority treatment, active queue management techniques, drop
> priority techniques, etc. -- this already seems to be a significant
> toolbox.  It is not clear to me to what extent these have been used
> and do the job set out for IEPREP.  And if not, is the lack of use due
> to people solving the problem in other ways (or not at all) rather
> than the lack of mechanisms?
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


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