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

[Gonzalo Camarillo <[e-mail]>]

Hi Tom,

could you please address the review below as well?

Thanks,

Gonzalo

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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-hip-rfc5206-bis-12
> Reviewer: Orit Levin ([e-mail])
> 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"
>