Re: [rohc] Proposed response to LS from 3GPP RAN2

Carsten Bormann <cabo@tzi.org> Sat, 30 March 2019 21:31 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rohc@ietfa.amsl.com
Delivered-To: rohc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37C41202A9 for <rohc@ietfa.amsl.com>; Sat, 30 Mar 2019 14:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k6EaDV95MeZ0 for <rohc@ietfa.amsl.com>; Sat, 30 Mar 2019 14:31:00 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D932F1202DA for <rohc@ietf.org>; Sat, 30 Mar 2019 14:30:59 -0700 (PDT)
Received: from [192.168.217.120] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44WsGn269hzygk; Sat, 30 Mar 2019 22:30:57 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <HE1PR0701MB252254CA77C5608B4E5CF8E095580@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Date: Sat, 30 Mar 2019 22:30:56 +0100
Cc: "rohc@ietf.org" <rohc@ietf.org>
X-Mao-Original-Outgoing-Id: 575674254.590294-7761c9f2e3c775def7d9a52f60101a58
Content-Transfer-Encoding: quoted-printable
Message-Id: <F14800D1-BABC-4E80-8DB0-863592AEC0F1@tzi.org>
References: <HE1PR0701MB252254CA77C5608B4E5CF8E095580@HE1PR0701MB2522.eurprd07.prod.outlook.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rohc/2CX1ojVdGJJZRyVpT1JgmxIH1TU>
Subject: Re: [rohc] Proposed response to LS from 3GPP RAN2
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rohc/>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2019 21:31:03 -0000

Sorry for the late response (too much mail backlog from IETF104):
Maybe it would be worth to also encourage involving the ROHC mailing list even before a version is sent for registration and expert review (as in “avoid late surprises”).

Thank you for taking care of this.

Grüße, Carsten


> On Mar 27, 2019, at 08:31, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
> Hi, 
> The IESG is targeting to approve the response on Friday sometime after 13:00 CET. Appreciate any comment you may have. 
> Cheers
> 
> Magnus
> 
> Title: In Response to 3GPP RAN2’s LS on RoHC utilization for Ethernet header compression
> To: 3GPP RAN2
> Cc: IEEE 802
> From: IETF
> From Contact: Magnus Westerlund
> Purpose: In Response
> Reference: R2-1902372
>  
>  Body:
> Greetings,
>  
> The IETF appreciate 3GPP RAN2 reaching out to IETF on the topic of robust header compression (ROHC). We are happy to answer your questions. See below for our response to your questions. But let us first provide some background information.
> It has been 9 years since the ROHC WG was closed, IETF currently has no established community working on ROHC. However, for minor work adding a work item to the TSVWG would be a possibility. The IETF could also consider forming a new WG if there would be good reasons for more substantial work on header compression. However, for a single ROHC profile there are no necessity for such work in IETF. In case 3GPP would see a need for combining compression of ethernet with several sets of high layer protocols, for example Ethernet/IPv6/UDP and Ethernet/IPv6/TCP etc. there might be wider interest which may motivate doing such work in IETF.
> The ROHC framework is defined to allow for additional profiles and allows registration of ROHC profiles from both IETF and external bodies, such as 3GPP. The IANA registry for ROHC Profile Identifiers (https://www.iana.org/assignments/rohc-pro-ids/rohc-pro-ids.xhtml#rohc-pro-ids-1) is operating under the Specification Required policy defined in RFC 8126.
>  
> Q1: Does IETF or IEEE have any concerns with 3GPP defining new RoHC profile for Ethernet header compression?
> 
> Answer: IETF has no issues with 3GPP defining a ROHC profile as long it is registered with IANA.
> 
> Q3: In case 3GPP is allowed to develop RoHC profile for Ethernet header compression, does it have to be registered with IANA. If yes, how long can such process take?
> 
> Answer: For 3GPP to be assigned a ROHC profile identifier the new profile needs to be registered with IANA. This registry operates under a Specification Required policy. A 3GPP technical specification meet the formal requirements of this policy and enable registration.
> 
> There is also an IANA expert review, this review is to verify that the registration is for a ROHC profile with an interoperable description. The IANA registration process should be accomplished from submitted request to completion in a couple of weeks (2-4) given no issues are identified. When the expert has approved the registration the IANA will assign the profile an identifier.
> 
> Q4: According to IETF, what are the actions needed of 3GPP to specify and maintain a ROHC profile?
> 
> 3GPP defines and documents the ROHC profile in a technical specification. When the content of the specification is mature and describes a solution that fits the ROHC framework RFC 5795 and enables interoperable implementation, then 3GPP can submit a registration request to IANA (https://www.iana.org/protocols/apply) for a ROHC Profile Identifier. If there are any issues the expert will communicate such issues to the 3GPP contact person requesting the registration, so they can communicate these to the 3GPP RAN2 WG so that they can be resolved. When registration has been approved, IANA will assign a profile identifier that can be added to the 3GPP specification. Continued maintenance of the ROHC profile is solely under 3GPP responsibility.
> Please note that the registration request can be sent prior to the 3GPP specification is 100% complete, but the ROHC profile description needs to be mature enough for the expert to determine that the profile will result in interoperable implementations.
> 
> -- 
> 
> Magnus Westerlund 
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: 
> magnus.westerlund@ericsson.com
> 
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www.ietf.org/mailman/listinfo/rohc