Re: Checksum at IP layer - is it even needed ?

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 17 December 2015 07:12 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ACC1B2A39 for <ietf@ietfa.amsl.com>; Wed, 16 Dec 2015 23:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=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 q1MsA3haDEbC for <ietf@ietfa.amsl.com>; Wed, 16 Dec 2015 23:12:42 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id B30741B2A37 for <ietf@ietf.org>; Wed, 16 Dec 2015 23:12:41 -0800 (PST)
Received: (qmail 74658 invoked from network); 17 Dec 2015 06:54:17 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 17 Dec 2015 06:54:17 -0000
Subject: Re: Checksum at IP layer - is it even needed ?
To: Patrik Faltstrom <paf@frobbit.se>, ietf <ietf@ietf.org>
References: <CAOJ6w=Eu9PP1-xhk+pKWfi0dS2x2WsxdNeg-Puywx0cZZ1Gw=A@mail.gmail.com> <CAAeewD-A7-Ea3aia+_b7QrZLxABiUigRudcL9og1kkmb5L6gpQ@mail.gmail.com> <BE5A47FB-EE37-4692-9BB3-890BEA0A0FAC@puck.nether.net> <CAOJ6w=EZV+kr54Yy_OojoTKGW0X_v8nDUngbZYx6H2s_gV64wg@mail.gmail.com> <E1737903-5251-430A-AE3B-D65673865797@puck.nether.net> <566FD181.4030403@necom830.hpcl.titech.ac.jp> <20151215130035.GA5511@puck.nether.net> <56710AFE.8000004@necom830.hpcl.titech.ac.jp> <CAAeewD8ZOfYZOhjf-B_G6qCiMkrdwsWXzyF2FYy_WDSfPKgS_g@mail.gmail.com> <5671607E.5090809@necom830.hpcl.titech.ac.jp> <B0A81AEF-C5F3-46B4-94B0-B06B28ACA765@frobbit.se>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <56726064.9030200@necom830.hpcl.titech.ac.jp>
Date: Thu, 17 Dec 2015 16:12:36 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <B0A81AEF-C5F3-46B4-94B0-B06B28ACA765@frobbit.se>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/yVdG2PFpQrBfIKIvGEhlr7-FwS4>
Cc: Jared Mauch <jared@puck.nether.net>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 07:12:43 -0000

Patrik Faltstrom wrote:

> Not URI as the owner for the URI is prefixed with the service and protocol.

My misunderstanding, sorry.

> And due to the higher efficiency why I think URI is better than "HTTP
> redirect via well-known-url".

HTTP redirection redirects an entire URL to another URL and is well
defined.

However, though rfc7553 states:

   but instead of returning a hostname and port
   number, the URI record returns a full URI.  As such, it can be viewed
   as a more powerful resource record than SRV.

URI RR can not be used by applications without URL specifications,
whereas SRV can be used by any applications using hostnames (and
having IANA registered (or, well known?) service name).

Worse, even with applications with URL specifications, what happens
if the following URL:

	<scheme0>:<userinfo0>@<host0>:<port0><path0>?<query0>

invokes URI query using <scheme0> and <host0> results in:

	<scheme1>:<userinfo1>@<host1>:<port1><path1>?<query1>

How the original and the resulting components can be combined?
Obviously, scheme and host will be replaced, but how other
fields should be combined/replaced?

SRV is already bad with port numbers, which I addressed
in draft-ohta-urlsrv-00.

					Masataka Ohta