Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement

Tom Taylor <tom.taylor.stds@gmail.com> Sat, 06 September 2014 10:41 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: time@ietfa.amsl.com
Delivered-To: time@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DAC1A0267 for <time@ietfa.amsl.com>; Sat, 6 Sep 2014 03:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR0qgEJD17pJ for <time@ietfa.amsl.com>; Sat, 6 Sep 2014 03:41:32 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5281A0081 for <time@ietf.org>; Sat, 6 Sep 2014 03:41:32 -0700 (PDT)
Received: by mail-ig0-f175.google.com with SMTP id uq10so607347igb.8 for <time@ietf.org>; Sat, 06 Sep 2014 03:41:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4BxKniFMxj6Lf2lqVBz65Q9mOmsYmgzT+Io/IgylSSI=; b=nQw2jmmptvRktegz+xLzqTjxchnJ0W1xbganKorvQghei0BXLRseaeSQMA1/To1qNQ bYwTJSOYkJ0qmBKQdqul3nPUnEPxEImmVr/aCIkpLwtxOL0w6aB5YWq8VbpE99i+qUXW pWU08HW7pkQhugcJnYHhQx9cgSirjLks3ZUzsjgL1oe+HcQpF4WyTO0yH8f3WEBo0d1m farqqL2WgF+r9Bf7uU+OFDEi+7/gaEMFOURCQeNXVk6LekttaOSCoeMvAbZYw/NuZaRB WEFcWi0kpivsoWrJTdzPnwpfhjTk9QmWyYrynky56MsVUnOr9xhTJkCopHP3XtLMqFJL LWUQ==
X-Received: by 10.50.4.9 with SMTP id g9mr10997932igg.42.1410000091479; Sat, 06 Sep 2014 03:41:31 -0700 (PDT)
Received: from [192.168.97.8] ([67.210.160.130]) by mx.google.com with ESMTPSA id vn5sm5885135igb.1.2014.09.06.03.41.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 03:41:31 -0700 (PDT)
Message-ID: <540AE4DF.5010500@gmail.com>
Date: Sat, 06 Sep 2014 06:41:35 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Jouni <jouni.nospam@gmail.com>
References: <5409DA04.2020200@gmail.com> <461483BC-58E7-483D-8B81-FB15C015C4B7@gmail.com>
In-Reply-To: <461483BC-58E7-483D-8B81-FB15C015C4B7@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/time/CB1Hu7V163BMWnGOtqPEymoiPOE
X-Mailman-Approved-At: Sat, 06 Sep 2014 05:20:58 -0700
Cc: "time@ietf.org" <time@ietf.org>
Subject: Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <time.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/time>, <mailto:time-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/time/>
List-Post: <mailto:time@ietf.org>
List-Help: <mailto:time-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/time>, <mailto:time-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Sep 2014 10:41:34 -0000

Thanks, Jouni. We can work on that.

Tom

On 06/09/2014 6:10 AM, Jouni wrote:
>
> Tom,
>
> I had a read on this document. Good stuff. I have one lame comment though. The preamble building the "background and justification" is just too verbose and tries to address to many cases. When we get to problem statement part and the architecture part it was hard to put everything together in my head. I admit I have not spent much time on this specific topic but still.. I would try to illustrate the background with one concrete use case example that people can easily relate to and then state "there are other out there..".
>
> - Jouni
>
>
> On Sep 5, 2014, at 6:43 PM, Tom Taylor wrote:
>
>> Qin Wu drafted me as editor of the Problem Statement I-D.
>>
>> There has been a lot of activity behind the scenes. When I  was brought into the picture, I was given a version -03 of draft-ww-opsawg-multi-layer-oam as a starting point. This built on the published -02 version but had a lot more text up front and in the future work section. It also dropped "Architecture" from the title, removing it as a focus.
>>
>> My view was that the Problem Statement had to be tightly focussed precisely on that topic, and the future work section would become the core of a gap analysis document. This view was accepted. As a result, I have prepared an Editor's Proposal, draft-edprop-opsawg-multi-layer-oam-ps-00, which I plan to submit on Monday after some people have looked it over. It is much stripped down from the original text and has a lot of new text, but I hope it is not a shock to TIME/LIME participants. A key issue was extremely careful attention to terminology and nuances of meaning.
>>
>> The concluding Problem Statement section is fairly brief, so I'll quote it here:
>>
>> 5.  Problem Statement
>>
>>    Operators have a need for a management subsystem satisfying the
>>    objectives stated in Section 3.  The analysis presented above
>>    indicates that the solution lies in the direction of a consolidated
>>    management function that operates in the first instance on a
>>    technology and layer independent view of network and service
>>    performance.
>>
>>    There is value in attempting to define an architecture for
>>    consolidated management that may reasonably be argued to meet the
>>    stated objectives.  If this attempt succeeds, it can be followed up
>>    with a gap analysis, which in turn will define a further program of
>>    standardization.
>>
>>    At the detailed level, Section 4.3.1 and Section 4.3.2 deal with the
>>    matter of abstraction and its relationship to the specification of
>>    YANG modules.  This is work beyond the initial definition of
>>    architecture and awaits justification and prioritization by the gap
>>    analysis.  A similar consideration relates to the solution to the
>>    ECMP problem.
>>
>>    The remaining issue is the OAM interworking issue identified in
>>    Section 4.3.3.  This is architectural in nature, and should be
>>    addressed by the proposed work on architecture.
>>
>> Tom Taylor		
>>
>> _______________________________________________
>> Time mailing list
>> Time@ietf.org
>> https://www.ietf.org/mailman/listinfo/time
>
>