Re: [TICTOC] submission of TICTOC modularization draft

Mark Townsley <townsley@cisco.com> Thu, 18 October 2007 15:33 UTC

Return-path: <tictoc-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXNj-0002Rm-L2; Thu, 18 Oct 2007 11:33:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiXNh-0002Gw-OW for tictoc@ietf.org; Thu, 18 Oct 2007 11:33:53 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiXNg-0005vg-Gv for tictoc@ietf.org; Thu, 18 Oct 2007 11:33:53 -0400
X-IronPort-AV: E=Sophos;i="4.21,296,1188802800"; d="scan'208";a="24904888"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 18 Oct 2007 08:33:51 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9IFXpSo006163; Thu, 18 Oct 2007 08:33:51 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9IFXFt5004524; Thu, 18 Oct 2007 15:33:50 GMT
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, 18 Oct 2007 11:33:47 -0400
Received: from rtp-townsley-vpn1.cisco.com ([10.83.1.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 11:33:47 -0400
Message-ID: <47177CE2.3010708@cisco.com>
Date: Thu, 18 Oct 2007 17:33:54 +0200
From: Mark Townsley <townsley@cisco.com>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Yaakov Stein <yaakov_s@rad.com>
Subject: Re: [TICTOC] submission of TICTOC modularization draft
References: <457D36D9D89B5B47BC06DA869B1C815D055120D8@exrad3.ad.rad.co.il>
In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D055120D8@exrad3.ad.rad.co.il>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Oct 2007 15:33:47.0408 (UTC) FILETIME=[466B8100:01C8119C]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15490.002
X-TM-AS-Result: No--23.893100-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2194; t=1192721631; x=1193585631; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20<townsley@cisco.com> |Subject:=20Re=3A=20[TICTOC]=20submission=20of=20TICTOC=20modularization= 20draft |Sender:=20; bh=cLOEo9OgzBX+zY/EyMhX+8ar7BAmiOJmIW58EZe0v40=; b=WuWqk5zF6dv0ySUofeAPS7qjaRr4bxgAA4CmNYGfPpSjAxshSTdg6oJj3x8yhR9Rn19aBzsv EBDtEnlcDUTjNvOeucWhy09oKcs/MNPF/B6DbyI+5ZxYjMR6InDYEful;
Authentication-Results: sj-dkim-4; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: tictoc@ietf.org
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
Errors-To: tictoc-bounces@ietf.org

All,

I've read an earlier version of this draft, and found it very helpful in 
understanding the problem space. I think that it is important that the 
group look this over, and quickly focus on which of the "modules" need 
be in scope for the potential WG, and which not. I really like that the 
problem space is outlined in its entirety in the doc here, but when it 
comes time to charter a WG we will need to identify which of the modules 
are in scope for IETF documents and protocol work, assign milestones 
accordingly, etc.

Next, within each module, we need an idea of what the WG will produce 
and the direction it is headed. If there is a good idea of what protocol 
exists or needs to be extended and how, great. If not, some boundaries 
on what the WG will create, extend, choose among and how, etc. are needed.

The last BoF sufferred mostly from lack of scope for WG creation. This 
draft outlines the natural wide scope of this problem space in a way 
that can be broken down, digested, and discussed. It's a great first 
step. Now we need to pick out what the WG is really going to focus on. 
The more that is done on this before Oct 25, the better, as this is the 
day that the IETF and IAB sit down to discuss which BoFs to approve, and 
which not, for Vancouver.

Thanks,

- Mark

Yaakov Stein wrote:
> Hi all,
>  
> You will recall that one of the outcomes of the BOF in Prague
> was that we needed to to separate the TICTOC problem into small modules
> and to more clearly identify the deliverables.
> Stewart, Karen, and I promised to write a "modularization draft"
> to solve this problem.
>  
> I have submitted the promised TICTOC modularization draft.
>  
> Unfortunately, the automatic tool had some problems with our
> author's names, and so time consuming manual intervention
> will be needed. So I am attaching the draft to this email.
>  
> Comments would be appreciated.
>  
> Y(J)S
>  
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www1.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www1.ietf.org/mailman/listinfo/tictoc