[Openv6] Comments on draft-karagiannis-aponf-problem-statement-02

Tom Taylor <tom.taylor.stds@gmail.com> Wed, 09 July 2014 01:49 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7E5821A0240 for <openv6@ietfa.amsl.com>; Tue, 8 Jul 2014 18:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E7PLRpOrqd_0 for <openv6@ietfa.amsl.com>; Tue, 8 Jul 2014 18:49:14 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC441A023E for <openv6@ietf.org>; Tue, 8 Jul 2014 18:49:14 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id rd18so5697333iec.3 for <openv6@ietf.org>; Tue, 08 Jul 2014 18:49:13 -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:subject :content-type:content-transfer-encoding; bh=AXKHpV+duO82v9K4iWzQ3aplmau/jE0T4qcnYKvts+0=; b=RQtnLXkg+Qgv8REv9Z77c9j2uoZA4wu2w+vEQjZZrTmBANRjGdZv7J/CrbGVNk7f4v k9JuT9cHnURwr9QlYdaW+HzOEsFlSFfaPYX8ustj8/w7+CoO0vrbNvNEFEcFvETwKm1D 2U3Zd7CS8Z9oOW2Fpp3KqpHX0veYAU12rjLbmbXu+x7qsC1wls0nHK/uCGKzTOSE3+s+ j805BR3qr4nyK+WW03NCUTBXBYtkj5HC3v3OD/R4QVlz75o61l4RyP+vkdxIgmjimO3n tcWMULIeCq5JStxIRFnnP437gXIS8xpHKdHiJFLfSXLOR/367fIUERSSYynlHm86JLKh umjA==
X-Received: by with SMTP id y10mr8297999igl.10.1404870553641; Tue, 08 Jul 2014 18:49:13 -0700 (PDT)
Received: from [] (dsl-173-206-11-121.tor.primus.ca. []) by mx.google.com with ESMTPSA id ga11sm10789992igd.8.2014. for <openv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 18:49:13 -0700 (PDT)
Message-ID: <53BC9F97.20704@gmail.com>
Date: Tue, 08 Jul 2014 21:49:11 -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: openv6@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/0wEBREh1ke43ZB9xr94pe3DJNCI
Subject: [Openv6] Comments on draft-karagiannis-aponf-problem-statement-02
X-BeenThere: openv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <openv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openv6>, <mailto:openv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openv6/>
List-Post: <mailto:openv6@ietf.org>
List-Help: <mailto:openv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openv6>, <mailto:openv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2014 01:49:15 -0000

The APONF problem statement is definitely shaping up, although I think 
there are still some extraneous elements that were pasted in from the 
draft charter but don't really belong in the draft. I complained about 
the presence of architectural descriptions in earlier versions, but I 
suggest a summary figure showing the high-level architecture would be 
helpful in the description of the different aspects of total problem as 
they relate to different WGs. Here is the figure I have in mind, based 
on my reading of the problem statement:

                     |  End user   |
                     | application |
                  AECON-developed interface
                    SFC-developed model
                   | Network management |
                   |   application      |
                            |     APONF
                            |   transport
                            | (SFC-developed
                            |  templates?)
                   | Network management |
                   |      control       |
                   | ... and then a     |
                   | miracle happens :) |
                   |   APONF-developed  |
                   |     mapping?       |
                   To individual devices

My suggestion is to have this at the end of the introduction and get rid 
of Section 5, which just repeats the same information.

I like the way the draft draws conclusions from the use cases and 
reflects them in the requirements. I will give that section closer 
scrutiny in a later E-mail.

Given that the draft draws attention to GIST as a candidate protocol, it 
would be good to include text explaining why this protocol in particular 
seems to be a good fit to the requirements.

Tom Taylor