Re: [Ieprep] Proposed Revised Charter

sob@harvard.edu (Scott Bradner) Wed, 07 September 2005 17:50 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED43m-000648-54; Wed, 07 Sep 2005 13:50:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED43k-00063w-2r for ieprep@megatron.ietf.org; Wed, 07 Sep 2005 13:50:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05657 for <ieprep@ietf.org>; Wed, 7 Sep 2005 13:50:07 -0400 (EDT)
Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED46w-0005Ko-TS for ieprep@ietf.org; Wed, 07 Sep 2005 13:53:28 -0400
Received: by newdev.harvard.edu (Postfix, from userid 501) id 033854B5A9F; Wed, 7 Sep 2005 13:49:57 -0400 (EDT)
To: antonio.desimone@jhuapl.edu, KIMBERLY.S.KING@saic.com
Subject: Re: [Ieprep] Proposed Revised Charter
In-Reply-To: <431F1FCD.20302@jhuapl.edu>
Message-Id: <20050907174957.033854B5A9F@newdev.harvard.edu>
Date: Wed, 07 Sep 2005 13:49:57 -0400
From: sob@harvard.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Robert.Cole@jhuapl.edu, jon.peterson@neustar.biz, ieprep@ietf.org, sob@harvard.edu
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>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org

> suggest a rewrite of these two paragraphs
>  
> <<<<<<<<<<<<
> 2. Nested VPNs require special considerations for routing and QoS if
> nodes in the path that make these decisions generally have limited
> information.
 > >>>>>>>>>>>
> 2. VPNs in the manner of IPSec--point-to-point tunnels that encrypt payload
> and header information--require special consideration for routing and QoS
> because some nodes on the path that make forwarding and scheduling
> decisions will have limited information.  Nested VPNs (tunnels in tunnels)
> or concatenated VPNs (tunnels terminated at a gateway node) VPNs both need
> to be considered.
 
this sounds like too much of a restriction - is there a reason to
restrict the VPN issues to ones relating to encryption?

> <<<<<<<<<<<<
> 4. Considering robustness of non-real-time applications with
> preferential treatments, as voice will not be the only application used
> by IEPREP.
 > >>>>>>>>>
> 4. While voice was the driving application for IEPREP in the past, 
> preferential
> treatments will need to be applied to all applications
> essential to emergency communications. Preferential treatment must
> address robustness of both voice and non-real-time applications that share
> the same infrastructure.
 
works for me

> I think we should also include a November goal of submitting an I-D on
> DoD requirements for precedence. Is that the same as your Feb 06 item?

fine by me

Scott

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