Re: [Gen-art] Gen-ART Last Call review of draft-ietf-hip-rfc5206-bis-12

Gonzalo Camarillo <> Wed, 31 August 2016 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F9EA12D129; Wed, 31 Aug 2016 00:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.221
X-Spam-Status: No, score=-104.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, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8obYcxtKoc42; Wed, 31 Aug 2016 00:50:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7BA912D835; Wed, 31 Aug 2016 00:43:02 -0700 (PDT)
X-AuditID: c1b4fb30-ea88e980000009f9-7a-57c68a85c9c4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 65.E7.02553.48A86C75; Wed, 31 Aug 2016 09:43:01 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 09:42:59 +0200
To: Orit Levin <>, "" <>
References: <>
From: Gonzalo Camarillo <>
Message-ID: <>
Date: Wed, 31 Aug 2016 10:42:58 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM2K7n25r17FwgyMfBCz+fTrAbHH11WcW i/uLdjNbNN79w+TA4rFkyU8mj9Ydf9k99lzTCGCO4rJJSc3JLEst0rdL4Mr4O+UJW8F3jYo3 iyYxNzB+Vuxi5OSQEDCR2PXhB1sXIxeHkMB6RokTx56yQjhrGSWur1rG0sXIwSEs4CaxbHIO SIOIQK3E7onzmUBsIYEYielTZ7GB2MwCfhKr/txjBbHZBCwktty6D9bKK2Avsf9QGUiYRUBV 4uvXU2BhUaDW9X0JIGFeAUGJkzOfsIDYnAKxEus657BATDSQOLJoDiuELS+x/e0cZoit2hLL n7WwTGAUmIWkfRaSlllIWhYwMq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECAzXg1t+G+xg fPnc8RCjAAejEg/vwpNHw4VYE8uKK3MPMUpwMCuJ8BZ3HgsX4k1JrKxKLcqPLyrNSS0+xCjN waIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwMiz4Dnbv+dX3//qrOpwrkz7HP4pIL3FxuUE o84VX9HzRr7T1EXS/CctU/RikwrIZkw8ltSqGXiU+dnJn+dkP9xSeDU1uWDdG96NR5Y+FH7m b/J50bzeD/MebFCcvqCfX3VZ6Nyu9KOrPWx9JqmHZNUb/jq/Jntf5uoE8yLXqxvs9NyPKyV4 bVJiKc5INNRiLipOBACfrYgdUwIAAA==
Archived-At: <>
Cc: General Area Review Team <>, Tom Henderson <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-hip-rfc5206-bis-12
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Aug 2016 07:50:33 -0000

Hi Tom,

could you please address the review below as well?



On 24/08/2016 3:38 AM, Orit Levin wrote:
> 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 <>.
> Document: draft-ietf-hip-rfc5206-bis-12
> Reviewer: Orit Levin (
> Review Date: 2016-08-23
> IETF LC End Date: 2016-08-25  
> IESG Telechat date: unknown
> Summary:
> This draft is basically ready for publication, but has nits that should be fixed before publication. The nits below are arranged by sections of the draft. 
> The majority of nits relate to explaining the scope of the draft and its relationship to the multihome functionality. 
> Nits with suggestions for resolution are listed per section below. (Purely editorial suggestions are marked "Ed.".)
> Abstract:
> 1. Replace "extensions" to "extension" since the multihost case is addressed separately. 
> 2. Remove "general" in "a general LOCATOR_SET parameter" since it introduces confusion rather than adds clarification.
> 3. Replace "elements of procedure " with "a basic procedure".  Otherwise, the immediate question arises:  what was the criteria for specifying some "elements" of the procedure, but not the others?
> 4. Replace "While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document"  with something along these lines: "draft-ietf-hip-multihoming [replace with the future RFC number] addresses multihost functionality with HIP. At this time, coexistence of mobility and multihoming is left for future study." Reason: multihosting and mobility relate to each other hierarchically. The fact that the same parameter carrying a flat structure is used for both cases is counter-intuitive. Therefore, mentioning this fact without further explanation will only confuse the readers. My assumption is that the two extensions are expected to be implemented together, although not deployed together at this stage. This point needs to be clarified in the Abstract and, especially, in the Scope.
> Introduction and Scope:
> Par. 3: Remove "generalized" as explained under Abstract.
> Par. 3: Replace "SA" with "security association (SA)" since it is being used for the first time.
> Par. 4: Replace "elements of procedure" with "a basic procedure" as explained under Abstract.
> Par. 4: Add a brief description of the scope "by inclusion", not only by "exclusion". Describe the basic functionality  addressed by this standard in a couple of sentences. Perhaps rearrange the Scope into "in scope" and "out of scope".
> Par. 4: Replace "the sequential change" with "a change" because it is not clear what "sequential change" means without contrasting it with the "parallel change" of the multihosting case.
> Par. 5: Replace the whole paragraph with a statement along the following lines: "This standard does not address multihosting. draft-ietf-hip-multihoming [replace with the future RFC number] defines multihost functionality with HIP. At this time, coexistence of mobility and multihoming is left for future study" as explained under Abstract. This is also probably the place to add the clarification that this draft support inclusion of a single LOCATOR_SET parameter and a single ESP_INFO parameter only in support of basic mobility scenarios.
> Ed. Par. 7: Replace " there is a need for some helper functionality in the network, such as a HIP rendezvous server" with "there is a need for some assistance from the network, such as by deploying a HIP rendezvous server".
> Terminology and Conventions:
> LOCATOR_SET: Remove "The name of" from the definition.
> Locator and Address: Replace "A name" with "A parameter" or "A field" in both definitions.
> Preferred locator: Add an explanation and/or a definition of the "scope" of a preferred locator.
> Credit Based Authorization: Remove the first sentence. Replace the second sentence with "An approach [or a design choice] allowing a peer to receive a certain amount of data at the new locator before the result of mandatory verification is known."
> 3.1 Operating Environment
> Par. 2: Replace "extensions" with "extension"  and remove "and multihoming" because it is more confusing than helpful as explained above.
> Ed. Par. 5: Change "Second" to "Secondly".
> 3.1.2 Mobility Overview
> Par. 1: Replace "containing a LOCATOR_SET parameter" with "containing a single ESP_INFO and a single LOCATOR_SET parameters". 
> 3.2 Protocol Overview
> Par. 1: Remove "However, for the (relatively) uninitiated reader" because this is not a standardization language.
> Par. 3: Replace "The majority of the packets on which the LOCATOR_SET parameters are expected to be carried are UPDATE packets" with "In support of mobility, the LOCATOR_SET parameter is carried in UPDATE packets".
> 3.2.1 
> Par. 1: Replace "as in the first address" with "as in the previous address"