Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

Miika Komu <miika.komu@ericsson.com> Mon, 18 April 2016 13:10 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C1B12D678 for <hipsec@ietfa.amsl.com>; Mon, 18 Apr 2016 06:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 a_kT5je9Sef7 for <hipsec@ietfa.amsl.com>; Mon, 18 Apr 2016 06:10:53 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D1F12D5C3 for <hipsec@ietf.org>; Mon, 18 Apr 2016 06:10:51 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-ac-5714dcd85cb9
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.26.12926.8DCD4175; Mon, 18 Apr 2016 15:10:49 +0200 (CEST)
Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Mon, 18 Apr 2016 15:10:48 +0200
To: <hipsec@ietf.org>
References: <alpine.LRH.2.01.1602230608110.18671@hymn04.u.washington.edu> <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> <56DD757B.8050002@ericsson.com> <20160328235106.GA79648@cowbell.employees.org>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <5714DCD8.7050907@ericsson.com>
Date: Mon, 18 Apr 2016 16:10:48 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160328235106.GA79648@cowbell.employees.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060500010207000509020509"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ru7NOyLhBt/vs1hMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGdf617AVbHesmL/5N1sD41/rLkZODgkBE4kfb9vZIGwxiQv3 1gPZXBxCAkcYJW7t/M8MkhASWM0ocex1BYgtLGAvcXLfLXYQW0RAVGLKh9PMEA37mCR6vn9n AUmwCWhJrLpzHayZX0BSYkPDbjCbV0BbYs/aLawgNouAqsSt06fA4qICERJP5p5khKgRlDg5 8wnYHE4Ba4nrrzoYQRYwC3QzSvQ1PmLqYuQA2qYicfFY8ARGgVlIWmYhKwNJMAvYStyZu5sZ wtaWWLbwNZRtLTHj10E2CFtRYkr3Q3YI21Ti9dGPjBC2scSydX/ZFjByrGIULU4tTspNNzLW Sy3KTC4uzs/Ty0st2cQIDP+DW36r7mC8/MbxEKMAB6MSD28Cu0i4EGtiWXFl7iFGFaA5jzas vsAoxZKXn5eqJMJrch0ozZuSWFmVWpQfX1Sak1p8iFGag0VJnDc78l+YkEB6YklqdmpqQWoR TJaJg1OqgdFMYeXHx8nKX7Yxt89cwr/o05YSdjfeOJ0D3fHNjIVvxKd/LPsabPVjnY1RXfuH Wd3zX/94bKlt5H2x+LDn21nH+cUC67dFK7Wb25y8oxcw2+e8eZFRrNP96UeynsjqdMvo6T+M 06hnnCXcNq3tTtaxw62eqgwKi1bLvZocfWgN/6k4HvnQOCWW4oxEQy3mouJEAAyK22SHAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/t7l6lhJYATPOTsnE2d1ZWjv3VpY>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2016 13:10:55 -0000

Hi,

On 03/29/2016 02:51 AM, Derek Fawcus wrote:
> On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote:
>> First he will look into adding clarifications to the existing draft
>> while still referencing the old RFC. If the group is not happy with the
>> readability after the editorial pass (or our AD does not finally let us
>> downref the old RFC), we can consider bringing material from the old RFC
>> directly into the new one.
>
> Sorry,  that I'm quite late in looking at these,  but have been doing
> so recently...
>
> I have to say that I find the it difficult to decode simply because
> of having to refer to 3 (the draft, 5770, 5245) plus possibly the
> STUN/TURN docs at once.
>
> I'd certainly find it easier to comprehend if the text from 5770 was
> incorporated (suitably modified to account for not doing STUN/TURN)
> within the draft.  That way the references to the significant pieces
> of 5245 text would be easier to nail down.
>
> As it is,  I currently find it a bit like reading an Act of Parliament!
>
> e.g. $3.8 Connectivity Checks
>     refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to
> $5.7 of 5245 and $7 of 5245,  where the exceptions (use of UPDATE instead
> of STUN) have to be applied to that $7 referencing 5389,  so possibly
> I don't have to read 5389, since hopefully it would just be packet formats.
>
>> I would also like the group to comment on the following two proposals:
>>
>> 1) the draft will allow implementers to use HIP native relays only. In
>> addition, the use of STUN and TURN relays will be optional.
>
> I'd suggest the draft be native only,  but say with an appendix referencing
> 5770 for use of STUN/TURN,  maybe indicating which bits of the 5770
> to take heed of.
>
>> 2) in addition to covering the base exchange, the draft will also cover
>> the mobility readdressing exchange.
>
> Not having read that recently,  I can't really comment.

I am going to join the author list and help to improve the draft 
according the comments on the mailing list.

Another change we plan to do is to adjust the current specification to 
new ice-bis recommendations (smaller delays, for instance). This will 
cause some delays because it's not yet an RFC.