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 draft-ietf-hip-rfc5206-bis....@ietf.org 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:t...@tomh.org] > Sent: Tuesday, September 06, 2016 11:08 PM > To: Gonzalo Camarillo <gonzalo.camari...@ericsson.com>; Orit Levin > <or...@microsoft.com>; draft-ietf-hip-rfc5206-bis....@ietf.org > Cc: General Area Review Team <gen-art@ietf.org> > 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 > >> (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. > > 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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
