[Lwip] New Version: draft-bormann-lwig-7228bis-01.txt

Carsten Bormann <cabo@tzi.org> Mon, 01 May 2017 18:44 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F39512E040 for <lwip@ietfa.amsl.com>; Mon, 1 May 2017 11:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 WbKtQZ83z-1W for <lwip@ietfa.amsl.com>; Mon, 1 May 2017 11:44:51 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2362C129C68 for <lwip@ietf.org>; Mon, 1 May 2017 11:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v41IfH8A007002 for <lwip@ietf.org>; Mon, 1 May 2017 20:41:17 +0200 (CEST)
Received: from client-0221.vpn.uni-bremen.de (client-0221.vpn.uni-bremen.de [134.102.107.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wGtY91pSLzDHCD; Mon, 1 May 2017 20:41:17 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
Date: Mon, 01 May 2017 20:41:16 +0200
X-Mao-Original-Outgoing-Id: 515356876.445208-4316cb9f54d5aa4b7b8e1e944e8717c4
Content-Transfer-Encoding: quoted-printable
Message-Id: <198DA5C9-EB3C-4334-B455-1198FDA399F5@tzi.org>
References: <149366386770.9804.16215974527270480028.idtracker@ietfa.amsl.com>
To: lwip@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/KlWjI4CcpgXUpQzNc2Md1MP2X_8>
Subject: [Lwip] New Version: draft-bormann-lwig-7228bis-01.txt
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 May 2017 18:44:54 -0000

We have submitted a new version of the 7228bis proposal.

There are two new things in there:

* Section 5.3 is a trial balloon for a nomenclature distinguishing
  wildly different classes of physical layer bitrates.  This probably
  needs a lot of discussion.  One alternative would be to just use a
  form of log10(bitrate), e.g. B0 for 1..10 bit/s, B1 for 10..100 etc.
  This is about burst rate (and thus direct serialization latency),
  but we also could talk about sustained bitrate, message rate etc.
* Section 3 extends the now well-known device classes 1 and 2 upwards.
  This starts by introducing a more large-grained grouping (group "M"
  for microcontrollers, group "J" for general purpose CPUs) and then
  goes ahead defining class 10 to 19 for the latter.  I'm not very
  happy with the term "general purpose CPU", but people seem to know
  what's meant (i.e., "can run Linux").  Also, the actual classes 10
  to 19 are completely arbitrary trial balloons.  Finally, we probably
  need a class 3, 4, 5 (and there even has been talk about
  subbdividing 1, 2).

All these could be done in arbitrary ways.  But this is not about
choosing a color for the bike shed, this is about creating terms (and
thus language) for intelligently talking about protocol (and system)
designs.

Feedback about how this best is accomplished would be appreciated.

https://tools.ietf.org/rfcdiff?url2=draft-bormann-lwig-7228bis-01.txt

Grüße, Carsten