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 (or...@microsoft.com) > 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" > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
