Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Thu, 24 March 2016 01:08 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896D012D192 for <xrblock@ietfa.amsl.com>; Wed, 23 Mar 2016 18:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 vNr69BgxjPSg for <xrblock@ietfa.amsl.com>; Wed, 23 Mar 2016 18:08:36 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC9312D12F for <xrblock@ietf.org>; Wed, 23 Mar 2016 18:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9133; q=dns/txt; s=iport; t=1458781716; x=1459991316; h=from:to:subject:date:message-id:mime-version; bh=UOaLWPLG/ttZEI7lsaLYaec8YDFz8gmeOdMXbaeIuIg=; b=ZQhyC21YCpXAs8pw440e4YqQadkwUwSYj+8h1nEzBXfA0lGveJIbRH5A MP9npDATu2CSE2sNFPnObeXQevyAySJKXdPFF6v+CWXkZXt0jjFVGYlZp 1NjzxZ/cHZzw3DWLGJYhFxPfOUoto29G67jbpLQzN6bFeiuIbLmfHb7ZN o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAgAOPfNW/4sNJK1egmdMU4EAtWuEb?= =?us-ascii?q?gENgXAjhWqBRTgUAQEBAQEBAWQcC4RBAQEBAwF+DQEIGGAnBIgyCA6gVaBSAQE?= =?us-ascii?q?BBwEBAQEYBIYehESEaYUpBZdaAYVwiBOPCo8GAR4BAUKCMIE1iXd+AQEB?=
X-IronPort-AV: E=Sophos; i="5.24,383,1454976000"; d="scan'208,217"; a="83957746"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2016 01:08:35 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2O18ZLq012587 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <xrblock@ietf.org>; Thu, 24 Mar 2016 01:08:35 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Mar 2016 20:08:34 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Wed, 23 Mar 2016 20:08:34 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
Thread-Index: AQHRhWmwmfCsDy67eEi0ylJgtIs/7A==
Date: Thu, 24 Mar 2016 01:08:34 +0000
Message-ID: <D318B652.5C910%mzanaty@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.244.205]
Content-Type: multipart/alternative; boundary="_000_D318B6525C910mzanatyciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/7WQHaSpVASltU_HQ9PON4xA2xaY>
Subject: Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2016 01:08:38 -0000

On 3/8/16 2:27 PM, Romascanu, Dan (Dan) wrote:
> We have two options:
> 1. Continue as planned with the approval and publication process
> 2. Not proceed with this document.

I would like to propose a third option:
3. Remove an inconsequential sentence in the draft and remove the IPR disclosure before progressing the draft.

After reading the draft, IPR disclosure and patent, it is very clear that the patent relates to a single "For example" sentence in section 3 d) of the draft ("Error Resilient Encoding") since they even share common language.

However, this "For example" sentence of the draft is purely informational background on some examples of loss concealment techniques within some video codec implementations. It is completely inconsequential to the rest of the draft, and does not even provide any additional motivation beyond the rest of the introductory sections.

I propose the authors remove this "For example" sentence and the IPR holders remove the IPR disclosure if it no longer applies to the revised draft.

https://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-video-lc-05#section-3

OLD:
d) Error Resilient Encoding
The sender encodes the message in a redundant way so that receiver
can correct errors using the redundant information.There are usually
two kinds of Error Resilient Encoding: One is that the redundant data
useful for error resiliency performed at the decoder can be embedded
into the compressed image/video bitstream. For example, the encoder
can select a crucial area of an original video frame, extract some
important characteristics of this area as the redundant information,
e.g., redundant motion vector of the first macroblock in a slice of
this area and redundant motion vector difference of other macroblocks
in this slice of this area, and imperceptibly embed them into other
parts of the video frame sent in a different RTP packet or in the
next frame, e.g., other slices of this area. The other is bit-block
level encoding, e.g., FEC.

NEW:
d) Error Resilient Encoding
The sender encodes the message in a redundant way so that receiver
can correct errors using the redundant information.There are usually
two kinds of Error Resilient Encoding: One is that the redundant data
useful for error resiliency performed at the decoder can be embedded
into the compressed image/video bitstream. The other is bit-block
level encoding, e.g., FEC.

If this third option is not possible, I suggest not progressing the draft (option 2).

Regards,
Mo