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

"James M. Polk" <jmpolk@cisco.com> Thu, 02 November 2006 19:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfhpj-0005dc-Cq; Thu, 02 Nov 2006 14:02:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfhph-0005dO-GN; Thu, 02 Nov 2006 14:02:33 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfhpd-0005GD-FL; Thu, 02 Nov 2006 14:02:33 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2006 11:02:29 -0800
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAJjNSUVAZnme/2dsb2JhbAA
X-IronPort-AV: i="4.09,381,1157353200"; d="scan'208"; a="47680590:sNHT27811758"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2J2TgK023015; Thu, 2 Nov 2006 14:02:29 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA2J2SDO000082; Thu, 2 Nov 2006 14:02:28 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 14:02:28 -0500
Received: from jmpolk-wxp.cisco.com ([10.89.16.15]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 14:02:27 -0500
Message-Id: <4.3.2.7.2.20061102124821.03caff08@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 02 Nov 2006 13:02:26 -0600
To: Pekka Savola <pekkas@netcore.fi>, Sam Hartman <hartmans-ietf@mit.edu>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <Pine.LNX.4.64.0611021232070.11394@netcore.fi>
References: <tslhcxihmw3.fsf@cz.mit.edu> <E1GfLJY-0003B5-Pg@ietf.org> <tslhcxihmw3.fsf@cz.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 02 Nov 2006 19:02:27.0623 (UTC) FILETIME=[70783370:01C6FEB1]
DKIM-Signature: a=rsa-sha1; q=dns; l=3233; t=1162494149; x=1163358149; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:Re=3A=20WG=20Review=3A=20Recharter=20of=20Internet=20Emergency=20Prepare dness=0A=20=20(ieprep) |To:Pekka=20Savola=20<pekkas@netcore.fi>, =20Sam=20Hartman=20<hartmans-ietf@m it.edu>; X=v=3Dcisco.com=3B=20h=3DEIY0N7OdW1pH9v9jYzUFdvup8e4=3D; b=cKDuHXmoqA97Y737tqJ68+0bRCrlTRXg3tLEQ8lPzpC65/p8WdqJYKZSdMgqyP7M4T2dQSK9 RjZa871xPCxmGxwO1EupKAYIN1VsuqGn3DEMT0tHA5/axesQxldP2pm9;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: Kimberly King <kimberly.s.king@saic.com>, ietf@ietf.org, ieprep@ietf.org, Scott Bradner <sob@harvard.edu>
Subject: [Ieprep] Re: 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

At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote:
>On Wed, 1 Nov 2006, Sam Hartman wrote:
> > I don't believe the new charter of ieprep working group belongs in the
> > IETF.  I understand why we chartered it here, and I believe that by
> > doing as much work as we have done so far in the IETF, we have done
> > something useful.  We've described the broad problem and have helped
> > to explain how it fits in the Internet context.  That was an important
> > thing for us to do.
>
>I think I'll agree with Sam.

I do not agree with Sam

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

This is because the charter of the past didn't allow such work.

This new charter was supposed to allow such work AND investigate if 
protocol mods were needed to accomplish those arch and peering guideline 
efforts.

>This should already provide
>sufficient information how to continue the work.

continue the work.... where? by who? by another SDO?  Why?


>What isn't clear to me is what's the deployment level of these
>frameworks and various mechanisms.

there are no "various mechanisms" defined, there are only framework and 
requirements. Little can be accomplished with just that IMO.

>  We seem to have spent at least
>~4 years on this.

with both hands tied behind our backs, typing with with toes (so to speak).

>Overprovisioning and intra-domain TE seems to have been a popular approach,

in which IEPREP doc was "Overprovisioning" and "intra-domain TE " discussed?

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

I believe folks are assuming IEPREP has accomplished more than it was 
allowed to accomplish to date, and they ought to walk before they are 
allowed to run.  A framework doesn't allow IEPREP to even walk.

IEPREP was so constrained RFC 4542 had to be driven through another WG 
(TSVWG) because it wasn't allowed in IEPREP. Strike that, it would be 
allowed, but it would still be an individual ID because the charter 
wouldn't allow it to be a WG item even today.

SPeaking of RFC4542, it was a INFO instead of a BCP because of the IESG, 
which didn't want an explanation of more than a dozen EXISTING mechanisms 
and techniques to be considered a BCP (isn't that by definition a BCP 
<explaining how to put together a series of standards track RFCs>?).

>and frameworks, let this rest for 5 years and then come back to look if 
>there is something more to be said on the subject.
>
>--
>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