IETF Logo Mail Archive

Re: [lp-wan] re-order header field request

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Wed, 21 June 2017 08:02 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7B1317ED for <lp-wan@ietfa.amsl.com>; Wed, 21 Jun 2017 01:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 NS-rMxCJChaM for <lp-wan@ietfa.amsl.com>; Wed, 21 Jun 2017 01:02:50 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F901317DF for <lp-wan@ietf.org>; Wed, 21 Jun 2017 01:02:50 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5L82liG042813; Wed, 21 Jun 2017 10:02:47 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 850AC1D53C1; Wed, 21 Jun 2017 10:02:46 +0200 (CEST)
Received: from 83.55.156.17 by webmail.entel.upc.edu with HTTP; Wed, 21 Jun 2017 10:02:17 +0200
Message-ID: <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu>
In-Reply-To: <b1ae6a91-b3a3-6197-2648-d9001a9eff1e@ackl.io>
References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <ec067ef04c60b3fa38ea4887aa455314.squirrel@webmail.entel.upc.edu> <b1ae6a91-b3a3-6197-2648-d9001a9eff1e@ackl.io>
Date: Wed, 21 Jun 2017 10:02:17 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Arun <arun@ackl.io>
Cc: lp-wan@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.99.2 at violet
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 21 Jun 2017 10:02:47 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/xE9CrKxhWjINU2Ha1fY7w2YPqYw>
Subject: Re: [lp-wan] re-order header field request
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jun 2017 08:02:52 -0000

Hi Arun,

The point here is that the Rule ID field in fragments except the last one
will not use the W bit (or equivalently, have one bit less than the Rule
ID field in the last fragment as per current formats).

So I'm wondering if this "additional bit" in the Rule ID of the last
fragment could have any useful purpose or not, or conversely would just
complicate the structure and uniformity of fragmentation headers.

Thoughts?

Cheers,

Carles



> Hi Carles,
>
>  Having the uniform header format seems to be an ideal solution but
> Tx'ing additional bit without any significance seems contentious.
> Will wait for more feedbacks or comments :)
>
> thanks,
> Arun

v2.23.0 | Report a Bug | By Email