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

"Robert G. Cole" <robert.cole@jhuapl.edu> Mon, 06 November 2006 15:19 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6Fu-0004Rp-3X; Mon, 06 Nov 2006 10:19:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6Ft-0004Rh-4N; Mon, 06 Nov 2006 10:19:21 -0500
Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6Fp-0006aN-NJ; Mon, 06 Nov 2006 10:19:21 -0500
Received: from ([128.244.246.166]) by pilot.jhuapl.edu with ESMTP id 5502123.10908495; Mon, 06 Nov 2006 10:18:56 -0500
Message-ID: <454F52B7.4000403@jhuapl.edu>
Date: Mon, 06 Nov 2006 10:20:23 -0500
From: "Robert G. Cole" <robert.cole@jhuapl.edu>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
Subject: Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
References: <tslhcxihmw3.fsf@cz.mit.edu> <E1GfLJY-0003B5-Pg@ietf.org> <tslhcxihmw3.fsf@cz.mit.edu> <4.3.2.7.2.20061102124821.03caff08@email.cisco.com> <Pine.LNX.4.64.0611022301130.25516@netcore.fi> <454CEAA2.1040204@zurich.ibm.com> <6A5DDA18-6F3A-4AC2-A2D2-7FF8718404AB@cisco.com>
In-Reply-To: <6A5DDA18-6F3A-4AC2-A2D2-7FF8718404AB@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: Pekka Savola <pekkas@netcore.fi>, ieprep@ietf.org, Kimberly King <kimberly.s.king@saic.com>, Brian E Carpenter <brc@zurich.ibm.com>, Scott Bradner <sob@harvard.edu>, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org
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

I whole-heartedly agree.  I believe the DoD must extend its notions of 
Precedence and Preemption to all applications, voice, video, web, ftp, 
mail, etc.  Mechanisms/protocols must be defined and consistent across 
applications and their interactions with services, e.g., DNS, SIP, etc., 
and with their interactions with transport protocols, e.g., TCP, and IP. 
  Mechanisms must apply for session and non-session based applications 
and therefore cannot solely be handled through extensions to SIP 
signaling.  Mechanisms/protocols must provide the necessary security, 
authentication and access controls for all of the applications types as 
well.

I strongly believe that the IETF is the place to address these issues. 
And I think they are best served in a coordinated fashion within the 
guidance of a single working group with liaisons to other working groups 
and organizations.

Thanks,
Bob

Fred Baker wrote:
> I have to say that my discussions with US DoD and DHS/NCS, and with  
> their counterparts in other countries, doesn't suggest that the set  of 
> technical mechanisms is all specified. If we're looking only at  voice, 
> it is maybe so, but they're not looking only at voice.  Questions abound 
> around the mechanisms for sending an email and  ensuring that it is 
> delivered in a stated time interval on the order  of minutes or that an 
> indication of failure is returned to the  sender, and other things.
> 
> I am also not at this point convinced that the ITU is the right place  
> to have standards discussions regarding the Internet. There is not  the 
> demonstrated expertise, in my opinion.
> 
> So this is not all about mailing liaisons back and forth. If you want  
> the standards done right, the experts on the topics need to be doing  them.
> 
> On Nov 4, 2006, at 11:31 AM, Brian E Carpenter wrote:
> 
>> Hi,
>>
>> We now have a fair amount of guidance on how to work with other
>> SDO's in general, which would certainly include ITU-T. Just to
>> summarise:
>>
>>  "IAB Processes for Management of IETF Liaison Relationships,"
>>  BCP 102, RFC 4052, April 2005.
>>
>>  "Procedures for Handling Liaison Statements to and from the IETF,"
>>  BCP 103, RFC 4053, April 2005.
>>
>>  "Guidelines for Acting as an IETF Liaison to Another Organization,"
>>  RFC 4691, October 2006.
>>
>> We also have some specific guidance on extensions, when another
>> SDO sees a need for IETF protocols to be extended to meet their
>> system requirements:
>> draft-carpenter-protocol-extensions-04.txt (approved as a BCP, in  RFC 
>> queue).
>> A lot of IEPREP work seems to belong in the extensions category.
>>
>> The question in my mind is whether the IEPREP work items are in the
>> category where we can be confident that these mechanisms are  sufficient
>> (i.e., we can rely on another SDO to provide realistic requirements
>> in the form of liaisons) or whether we need the requirements to be
>> developed in the IETF to get them right (i.e., realistic in terms of
>> what Internet technology can actually achieve). I think the history
>> of work related to IEPREP shows that it's all too easy for people
>> steeped in the connection-oriented world to come up with unrealisable
>> requirements for a packet network.
>>
>>     Brian
>>
>> _______________________________________________
>> 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

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