Re: Proposed response to LS from 3GPP RAN2

Hi,

Thanks for the feedback, unfortunately it was too late. The LS was
approved on Friday and have been sent.
https://datatracker.ietf.org/liaison/1638/

I will work with my informal contacts with the people working on this to
request that they inform me and the ROHC list about progress.

Cheers

Magnus

On 2019-03-30 22:31, Carsten Bormann wrote:
> 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 =
=93avoid late surprises=94).
>
> Thank you for taking care of this.
>
> Gr=FC=DFe, 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 1=
3:00 CET. Appreciate any comment you may have. =

>> Cheers
>>
>> Magnus
>>
>> Title: In Response to 3GPP RAN2=92s 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 robus=
t header compression (ROHC). We are happy to answer your questions. See bel=
ow for our response to your questions. But let us first provide some backgr=
ound 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 wor=
k item to the TSVWG would be a possibility. The IETF could also consider fo=
rming 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 necessi=
ty for such work in IETF. In case 3GPP would see a need for combining compr=
ession of ethernet with several sets of high layer protocols, for example E=
thernet/IPv6/UDP and Ethernet/IPv6/TCP etc. there might be wider interest w=
hich may motivate doing such work in IETF.
>> The ROHC framework is defined to allow for additional profiles and allow=
s 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 u=
nder the Specification Required policy defined in RFC 8126.
>>  =

>> Q1: Does IETF or IEEE have any concerns with 3GPP defining new RoHC prof=
ile 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 profil=
e needs to be registered with IANA. This registry operates under a Specific=
ation Required policy. A 3GPP technical specification meet the formal requi=
rements of this policy and enable registration.
>>
>> There is also an IANA expert review, this review is to verify that the r=
egistration is for a ROHC profile with an interoperable description. The IA=
NA registration process should be accomplished from submitted request to co=
mpletion in a couple of weeks (2-4) given no issues are identified. When th=
e 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 an=
d 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 implementat=
ion, 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 request=
ing 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 a=
ssign a profile identifier that can be added to the 3GPP specification. Con=
tinued 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 b=
e 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: =

>> [email protected]
>>
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Rohc mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/rohc
>

-- =


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: [email protected]
----------------------------------------------------------------------