Re: [Hipsec] Genart last call review of draft-ietf-hip-native-nat-traversal-27
Miika Komu <miika.komu@ericsson.com> Thu, 01 March 2018 14:13 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 9E19A12E057 for <hipsec@ietfa.amsl.com>; Thu, 1 Mar 2018 06:13:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level:
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 0yDlIjUdNGEy for <hipsec@ietfa.amsl.com>; Thu, 1 Mar 2018 06:13:01 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 BC8A5124234 for <hipsec@ietf.org>; Thu, 1 Mar 2018 06:13:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519913579; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a0VZrr9PqEfU+lE8z1RZPF+OgN4fjJzm6LzJQdMacFc=; b=TG8/ZmNT3pd5uaefLTOttzKSISuJDuFtA1j1n33/zm69MqtRYzStSu3sxhzh6ptI 0NQNiSISZW/AKV+Zowo0ZGL7E0pJ4fIPbU18/FKAi5UnrGMimyBcE+C6F5N8osqC /M8FUfE2A2iaaQDBqgpjYfdZUjfr+9nURBgiI5/Knmo=;
X-AuditID: c1b4fb25-083ff70000002d5f-ad-5a980a6a4c6f
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 69.8A.11615.A6A089A5; Thu, 1 Mar 2018 15:12:59 +0100 (CET)
Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.352.0; Thu, 1 Mar 2018 15:12:58 +0100
From: Miika Komu <miika.komu@ericsson.com>
To: Roni Even <ron.even.tlv@gmail.com>, gen-art@ietf.org
CC: hipsec@ietf.org, ietf@ietf.org, draft-ietf-hip-native-nat-traversal.all@ietf.org
References: <151965127608.31482.7946240138786040730@ietfa.amsl.com>
Organization: Ericsson AB
Message-ID: <07dbd7e2-ad0b-8483-e181-b911f3b4a7ba@ericsson.com>
Date: Thu, 01 Mar 2018 16:12:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <151965127608.31482.7946240138786040730@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7sW4214wog0d7mCw2nd7DanH11WcW i6mLJjNbPNs4n8XibzuzA6vHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUx58EO9oJvshUH Z95ia2BcJ97FyMkhIWAi8ePjRMYuRi4OIYHDjBIbFr5ngnBWM0oc+L2fFaSKTUBLYtWd68wg trCAn8ShvzvZuhg5OEQErCQ2znYBMZkFYiSal5uBVAgJOEvsmfiGEcTmF5CU2NCwG6yTV8Be Yt6B3UwgNouAisSl2R9ZQGxRgQiJzpXzWSBqBCVOznwCZnMKuEg83rMarJdZwEJi5vzzjBC2 uMStJ/OZIGx5ie1v5zCDnCAENPPiseAJjEKzkEyahaR7FpLuWUi6FzCyrGIULU4tTspNNzLW Sy3KTC4uzs/Ty0st2cQIDPuDW36r7mC8/MbxEKMAB6MSD+92hhlRQqyJZcWVuYcYJTiYlUR4 T2+fFiXEm5JYWZValB9fVJqTWnyIUZqDRUmcd45we5SQQHpiSWp2ampBahFMlomDU6qB0aVy 412L1YszeqbY1TGfqnjKXZOyTz3icnbnoYC414V/Ss6E9/j+nrTwd3bU7vlMCi3VZ4J/+BTq W03JTNWXm6uymiGhTPgSy6lLh+ct19q0y8532z+miUfDf3T83Xn5M2tc0oEdjKy++mosWusf rwmYKLX3wasOnwp+h/+bXhnUnfpz3K4vSomlOCPRUIu5qDgRAAVrbjJ3AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/NdXmLRKZzp4FYZ2hnZCfm_RYIaQ>
Subject: Re: [Hipsec] Genart last call review of draft-ietf-hip-native-nat-traversal-27
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 01 Mar 2018 14:13:03 -0000
Hi Roni, thanks for the detailed review! My comments are below. On 02/26/2018 03:21 PM, Roni Even wrote: > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-hip-native-nat-traversal-?? > Reviewer: Roni Even > Review Date: 2018-02-26 > IETF LC End Date: 2018-02-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. in section 4.2 "Gathering of candidates MAY also be performed by other means > than described in this section. For example, the candidates could be > gathered as specified in Section 4.2 of [RFC5770] if STUN servers are > available, or if the host has just a single interface and no STUN orData > Relay Server are available." I did not see this a different ways since > section 3 says "The hosts use either Control Relay Servers or Data Relay > Servers (or other infrastructure including STUN or TURN servers) for > gathering the candidates." so STUN is mentioned also here. I suggest to remove the remark in parenthesis (or other infrastructure including STUN or TURN servers). Does this solve the issue? > 2. In section 4.6.2 "The connectivity check messages MUST be paced by the Ta > value negotiated during the base exchange as described in Section 4.4. If > neither one of the hosts announced a minimum pacing value, a value of 20 ms > SHOULD be used." in section 4.4 the default value is 50 ms? Good catch! I double checked this from the ICE spec, which defaults also to 50 ms. So, I change the value to 50 ms also in section 4.6.2. > 3. in section 5.4 what about "ICE-STUN-UDP 2" ; I assume it is not > relevant but this is also the IANA registeration I think it makes sense to add the missing one as you suggest, but omit it from the IANA registration since it is already registered for RFC5770. > 4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is not new it > is in RFC5770 You're right, I'll change this. > 5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63" is the > only new one. this also relates to section 7 that says that all error values in > section 5.10 are new while the rest are in RFC5770. Also there is no mention in > section 7 of which registry is used for the error values. Good catch, I'll correct these and add the IANA registry. > Nits/editorial comments: > 1. Expand SPI and LSI when first appear in the document > > 2. in section 2 "the base of an candidate" should be "a candidate" > > 3. In section 3 "so it is the Initiator may also have registered to a Control > and/or Data Relay Server" maybe "so the Initiator may also need to register to > a Control and/or Data Relay Server" > > 4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client > registers a new server reflexive candidate for each its peer for the reasons > described" maybe "for each of its..." Thanks for spotting these, will fix as suggested. > 5. In section 4.2 I could not parse the sentence "where Ta is the value used > for Ta is the value used for the" Should be "where Ta is the value used for the"... > 6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:" change to "as > defined in section 6.7 in [RFC7401]:" Will fix this too. Should I post a new version with the suggested changes?