Re: [Fecframe] David Harrington's Discuss on draft-ietf-fecframe-framework-14: (with DISCUSS)

Vincent Roca <vincent.roca@inrialpes.fr> Wed, 30 March 2011 19:28 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B983A6BB3; Wed, 30 Mar 2011 12:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.248
X-Spam-Level:
X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMbsE66Hk5Wi; Wed, 30 Mar 2011 12:28:46 -0700 (PDT)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id AE2BD3A67ED; Wed, 30 Mar 2011 12:28:44 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.63,269,1299452400"; d="scan'208,217"; a="104079867"
Received: from 78-80-198-253.tmcz.cz (HELO macbook-de-roca.local) ([78.80.198.253]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 30 Mar 2011 21:30:21 +0200
Message-ID: <4D9384CD.3010702@inrialpes.fr>
Date: Wed, 30 Mar 2011 21:30:21 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: David Harrington <ietfdbh@comcast.net>
References: <20110315213931.22139.58807.idtracker@localhost>
In-Reply-To: <20110315213931.22139.58807.idtracker@localhost>
Content-Type: multipart/alternative; boundary="------------060400000904040508090001"
Cc: fecframe-chairs@tools.ietf.org, "fecframe@ietf.org" <fecframe@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-fecframe-framework@tools.ietf.org
Subject: Re: [Fecframe] David Harrington's Discuss on draft-ietf-fecframe-framework-14: (with DISCUSS)
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 19:28:47 -0000

David,

Please find below our proposal in order to try to address
your two comments. Thanks.

Cheers,

    Vincent and Ali

---

9.6.  Baseline Secure FEC Framework Operation

    This section describes a baseline mode of secure FEC Framework
    operation based on the application of the IPsec security protocol,
    which is one possible solution to solve or mitigate the security
    threats introduced by the use of the FEC Framework.
*<new text>*
    All the FEC Framework implementations MUST implement this baseline
    secure mode of operation, even if it is not mandatory to use it.
*<end new text>*

    Two related documents are of interest.
[...]


10.  Operations and Management Considerations

[...]

10.1.  What are the Key Aspects to Consider?

    Several aspects need to be considered since they will directly impact
    the way the FEC Framework and the associated FEC schemes can be
    operated and managed.

    This section lists them as follows:
[...]

*<new text>
*   o Interoperability Considerations: generally speaking, it is highly
      desirable that devices coming from different vendors, possibly
      designed for different use-cases, interoperate. However the FEC
      Framework has been designed in such a way to accommodate a large
      variety of situations. Many options are left open in the current
      document and can only be clarified in the context of a given
      use-case.
*<end new text>
*
10.2.  Operational and Management Recommendations

[...]

*<new text>
*    o Interoperability Considerations: in the general case, it is
       difficult to provide clear recommendations on how to achieve
       interoperability by mandating the use of certain protocols, tools
       or configurations, since such considerations are usually use-case
       dependent. However the following is representative of the way the
       FEC Framework MAY be used over the Internet:
         - use RTP/RTCP over FEC Framework over UDP;
         - use either point to point or point-to-multipoint, bidirectional
           communications;
       In order to increase the probability that devices coming from
       different vendors interoperate, the following is RECOMMENDED:
         - if there is a risk a client does not support the FEC Framework
           or the sender's FEC scheme(s), then it is RECOMMENDED to use RTP
           framing of FEC repair packets, with different RTP Payload Type
           (PT) values.
         - if there is a risk a client does not support the grouping 
semantics
           [RFC 5956], then it is RECOMMENDED not to use it (otherwise this
           client would not understand the bindings).
         - it is RECOMMENDED that the clients and server support regular 
RTCP
           reports.
*<end new text>*
---

On 15/03/11 22:39, David Harrington wrote:
> David Harrington has entered the following ballot position for
> draft-ietf-fecframe-framework-14: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> updated for -14-
>
> The new revision has added significantly improved operations and management considerations and security consdierations.
> I think the text is still lacking a bit, and the fix should be fairly easy.
>
> 1) In the operations and management consideration section, it says:
>     In particular, this section discusses the questions of
>     interoperability across vendors/use cases and whether defining
>     mandatory to implement (but not mandatory to use) solutions is
>     beneficial.
>
> The section however fails to discuss interoperability across vendors at all (teh term interoperability is only in the above text).
> A paragraph should be added explaining how interoperability of management across vendors will be achieved, at least when the framework is used in the Internet..
>
> 2) The Security Considerations says:
>     The goals of this section are to state the
>     problem, discuss the risks and identify solutions when feasible.  It
>     also defines a mandatory to implement (but not mandatory to use)
>     security scheme.
> IPsec appears to be the baseline security, but the language surrounding IPsec is not specified in RFC2119 langauge that would make this mandatory to implement. Please specify the mandatory to implement security scheme in RFC2119 REQUIRED/MUST language.
>
>
>
>
>
>
>
>
>