RE: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs-00.txt

"Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com> Thu, 29 April 2004 12:09 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23264 for <avt-archive@odin.ietf.org>; Thu, 29 Apr 2004 08:09:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAGP-0006kR-SH for avt-archive@odin.ietf.org; Thu, 29 Apr 2004 08:03:38 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TC3bAJ025940 for avt-archive@odin.ietf.org; Thu, 29 Apr 2004 08:03:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJACw-0005Zz-V3; Thu, 29 Apr 2004 08:00:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJA8S-0004tR-7w for avt@optimus.ietf.org; Thu, 29 Apr 2004 07:55:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21916 for <avt@ietf.org>; Thu, 29 Apr 2004 07:55:17 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJA8I-00057b-Gw for avt@ietf.org; Thu, 29 Apr 2004 07:55:14 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJA7G-0004vP-00 for avt@ietf.org; Thu, 29 Apr 2004 07:54:11 -0400
Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BJA6v-0004k1-00 for avt@ietf.org; Thu, 29 Apr 2004 07:53:49 -0400
Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TBroPA028976 for <avt@ietf.org>; Thu, 29 Apr 2004 13:53:51 +0200 (MEST)
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 13:53:50 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <JQ35L0SZ>; Thu, 29 Apr 2004 13:53:50 +0200
Message-ID: <A943FD84BD9ED41193460008C7918050072E9568@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: 'Colin Perkins' <csp@csperkins.org>, Kristofer Sandlund <kristofer.sandlund@effnet.com>
Cc: avt@ietf.org
Subject: RE: [AVT] Comments on draft-ietf-avt-hc-mpls-reqs-00.txt
Date: Thu, 29 Apr 2004 13:53:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 29 Apr 2004 11:53:50.0571 (UTC) FILETIME=[A31CBBB0:01C42DE0]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

Colin, Kristofer, and others,

> > Comment 1:
> > **********
> > When reordering is discussed in section 3, it is not made clear how 
> > the HC scheme is supposed to handle reordering. Is the requirement 
> > that the decompressor should be able to correctly decompress all 
> > reordered packets, or is it enough that it can ensure no 
> > incorrectly decompressed packets will be forwarded, i.e. avoid
> > context damage? I assume that correct decompression is the intention,
> > but it could be made more clear.
> 
> I would suggest that the requirement is that packet 
> reordering MUST NOT cause incorrectly decompressed packets
> to be forwarded on from the decompressor. We would clearly
> like a solution that lets the decompressor correctly
> decompress reordered packets, but that's an optimisation
> rather than a hard requirement.

What does a use of MUST NOT in this context actually mean? Does
it mean the compressed (or uncompressed) header must be protected
by a CRC of infinite size? Seriously, I agree with the content of
your comment, not forwarding incorrect packets is the hard 
requirement. However, this example just makes me more convinced we
should not use 2119 keywords in this document, but instead write
what we actually mean our intentions are. 

Cheers,
/L-E

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt