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

From: Orit Levin <[email-masked]>
Date: Fri, 9 Sep 2016 21:02:17 +0000

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 [email-masked] 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:[email-masked]]
> Sent: Tuesday, September 06, 2016 11:08 PM
> To: Gonzalo Camarillo <[email-masked]>; Orit Levin
> <[email-masked]>; [email-masked]
> Cc: General Area Review Team <[email-masked]>
> 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
> >> ([email-masked]) 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

---

From: Orit Levin <[email-masked]>
Date: Fri, 9 Sep 2016 22:43:10 +0000

Sounds very good!
I think that you can say RFCXXX in the Abstract (as you say that this RFC obsoletes RFCYYY). If not, the RFC editor will rephrase it to best possible alternative.
Cheers,
Orit.

> Sent: Friday, September 09, 2016 2:18 PM
> To: Orit Levin <[email-masked]>; Gonzalo Camarillo
> <[email-masked]>; [email-masked]
> On 09/09/2016 02:02 PM, Orit Levin wrote:
> > 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
> > [email-masked] 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).
> 
> The only reason I refrained from doing so was that I was uncertain about
> whether Abstracts should contain citations.  If you can confirm that it
> OK, I will add it there too.
> 
> >
> > 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.
> >
> 
> 
> Thanks, I will review and publish a revision based on them.
> 
> - Tom

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 10 Sep 2016 09:37:30 +0300

Hi,

right. The rule Tom is thinking of is abstract should be self contained.
That is, they should not include external references. If the reference
is inline, as Orit proposes, it should be OK.

In this particular case, I leave it up to you two to decide what is
best. I do not have a strong opinion.

Cheers,

Gonzalo

---

From: Jari Arkko <[email-masked]>
Date: Sun, 11 Sep 2016 09:38:17 +0300

I think the wording as it is on -13 is fine. I.e., RFC number but no reference. I wouldn’t necessarily use RFC numbers even in general in abstract, but “This RFC replaces RFC nnnn.” I think is fine and appropriate.

Jari

---

From: Orit Levin <[email-masked]>
Date: Mon, 12 Sep 2016 21:25:45 +0000

Gonzalo and Jari,
To clarify, my comment was about the sentence in the Abstract saying:
"The same LOCATOR_SET parameter can also be used to support end-host-multihoming, but the procedures are out of scope for this document and are specified elsewhere."

My suggestion is to replace this with "The LOCATOR_SET parameter can also be used to support end host multihoming.  This functionality is specified in RFC[Replace with the RFC number for draft-ietf-hip-multihoming]".

If this is not an accepted language, then I suggest removing the sentence quoted above from the Abstract altogether. There is no need for it. Reference to draft-ietf-hip-multihoming already exists in the text and in the "Informative references" section of the document.

The reason behind my comment is that the current open ended sentence doesn't provide useful information and might create confusion as I explained in my original comments. I don't feel strongly about the exact way this comment gets addressed, though.

Thanks,
Orit.

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Saturday, September 10, 2016 11:38 PM
To: Gonzalo Camarillo <[email-masked]>
Cc: Orit Levin <[email-masked]>; Tom Henderson <[email-masked]>; [email-masked]; General Area Review Team <[email-masked]>
Subject: Re: Gen-ART Last Call review of draft-ietf-hip-rfc5206-bis-12

I think the wording as it is on -13 is fine. I.e., RFC number but no reference. I wouldn't necessarily use RFC numbers even in general in abstract, but "This RFC replaces RFC nnnn." I think is fine and appropriate.

Jari

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Sep 2016 11:26:08 +0200

Hi,

both replacing the sentence with Orit's proposal or removing the
sentence altogether would work for me.

Thanks,

Gonzalo