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

[Orit Levin <[e-mail]>]

Hi Tom,
I am really sorry that you didn't get the original email. I didn't sent it directly to the authors assuming that [e-mail] contains authors' names... 

I read your reply and looked at the diff between -12 and -13. I agree and like your changes - thank you very much! The only nit is that I would add the reference to the mulihoming draft/RFC in the Abstract (as in you did in your reply) instead of saying "elsewhere" (as in -13).

Unfortunately Gonzalo's email got trimmed so I am including the rest of my comments below. Hopefully it will not take much time to go over them.

------------------------------------------------------------------------------------------------------------------------------------------------------------
3.2.3 
Par. 2 Bullet 1: All "may" occurrences need to be capitalized. 

3.3.1
Add reference to Section 5.4, which uses a more formal language and provides more details.

4. LOCATOR_SET Parameter Format
Par. 1: "The LOCATOR_SET parameter ... defined by [RFC7401]" seems to be a mistaken statement.
Last paragraph: Describe what  a "sufficient scope" means.

5.1
Par.1 Remove "In a typical implementation" or explain the meaning of "typical".

5.2 and 5.3
Replace in the titles and in the text "LOCATOR_SETs" with "a/the LOCATOR_SET". Since handling of multiple SETs is left for future study, the current language is confusing.

5.2
Par. 1: Remove "Basically".

5.6
Ed. Par. 1: Replace "The following algorithm meets the security considerations" with "The following algorithm addresses the security considerations".


Additional editorial suggestions throughout the document:
1. Replace "--" with "i.e., ".
2. For each item or a list of items in brackets specify whether it is the full list (by adding i.e.,) or a list of examples (by adding e.g.,). 
3. Replace all/most low case appearances of "must" with "need(s) to". 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks!
Orit.

> -----Original Message-----
> From: Tom Henderson [mailto:[e-mail]]
> Sent: Tuesday, September 06, 2016 11:08 PM
> To: Gonzalo Camarillo <[e-mail]>; Orit Levin
> <[e-mail]>; [e-mail]
> Cc: General Area Review Team <[e-mail]>
> Subject: Re: Gen-ART Last Call review of draft-ietf-hip-rfc5206-bis-12
> 
> On 08/31/2016 12:42 AM, Gonzalo Camarillo wrote:
> > Hi Tom,
> >
> > could you please address the review below as well?
> >
> > Thanks,
> >
> > Gonzalo
> 
> Orit, thank you for the review; for some reason, I did not get the
> original email. The updates due to your comments will appear in draft
> version 13.
> 
> >
> > 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.
> 
> OK
> 
> 
> 2. Remove "general" in "a
> >> general LOCATOR_SET parameter" since it introduces confusion rather
> >> than adds clarification.
> OK
> 
> 
> 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?
> 
> I have replaced the term here, although in my experience, the term
> 'elements of procedure' is commonly used in protocol specifications; e.g.:
> 
> https://tools.ietf.org/html/rfc1157#section-4.1
> 
> Since we use the term extensively throughout the draft, I would prefer
> to retain its use in general.
> 
> 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.
> 
> Note, I am not sure about the term 'multihosting' above and also below--
> do you mean multihoming?
> 
> I decided to list this as an 'out-of-scope' list item, as follows:
> 
>        While the same LOCATOR_SET parameter supports host multihoming
>        (simultaneous use of a number of addresses), procedures for host
>        multihoming are out of scope, and are specified in
>        [I-D.ietf-hip-multihoming].
> 
> 
> >>
> >> Introduction and Scope: Par. 3: Remove "generalized" as explained
> >> under Abstract.
> 
> OK
> 
> Par. 3: Replace "SA" with "security association
> >> (SA)" since it is being used for the first time.
> 
> the abbreviation is already expanded in paragraph 1
> 
> Par. 4: Replace
> >> "elements of procedure" with "a basic procedure" as explained under
> >> Abstract.
> 
> changed to 'procedures'
> 
> 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".
> 
> see below Par. 5 response:
> 
> >> 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.
> 
> I shortened the whole sentence as follows:
> 
>        This document also specifies the messaging and elements of
>        procedure for end-host mobility of a HIP host.
> 
> 
> 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.
> 
> I decided to address this and the the comment above about scope with a
> slight reorganization of 'in scope' and 'out of scope' so that the items
> are grouped together.
> 
> 
> > 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".
> 
> This was reworded and simplified in the edit mentioned above.
> 
> >>
> >> Terminology and Conventions: LOCATOR_SET: Remove "The name of" from
> >> the definition.
> 
> OK
> 
> Locator and Address: Replace "A name" with "A
> >> parameter" or "A field" in both definitions.
> 
> Here I would like to keep 'A name' since such terminology refers back to
> the RFC 4423 HIP architecture document, on names and namespaces.
> 
> 
> Preferred locator: Add
> >> an explanation and/or a definition of the "scope" of a preferred
> >> locator.
> 
> I tried to handle this comment with a rewrite of the definition:
> 
>     Preferred locator.  A locator on which a host prefers to receive
>        data.  Certain locators are labelled as preferred when a host
>        advertises its locator set to its peer.  By default, the locators
>        used in the HIP base exchange are the preferred locators.  The use
>        of preferred locators, including the scenario where multiple
>        address scopes and families may be in use, is defined more in
>        [I-D.ietf-hip-multihoming] than in this document.
> 
> 
> >> Credit Based Authorization: Remove the first sentence.
> 
> OK
> 
> >> 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."
> 
> Replaced with:
> 
>             A mechanism allowing a host to send a certain amount of data
>             to a peer's newly announced locator before the result of
>             mandatory address 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.
> 
> 
> OK
> 
> Ed. Par. 5: Change
> >> "Second" to "Secondly".
> 
> OK
> 
> >>
> >> 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".
> 
> OK
> >>
> >> 3.2 Protocol Overview Par. 1: Remove "However, for the (relatively)
> >> uninitiated reader" because this is not a standardization
> >> language.
> 
> OK
> 
> 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".
> 
> OK
> >>
> >> 3.2.1 Par. 1: Replace "as in the first address" with "as in the
> >> previous address"
> >>
> 
> 
> OK
> 
> Are there more comments beyond 3.2.1?  (I am wondering if I may have
> missed another message).
> 
> - Tom