Agree this will improve readability. I will add them in the next version which I need to produce also to take care of Charlie's comments
Gerardo > -----Original Message----- > From: Jari Arkko [mailto:[email protected]] > Sent: Tuesday, May 18, 2010 12:01 AM > To: Enrico Marocco > Cc: [email protected]; gen- > [email protected] > Subject: Re: Gen-ART LC review of draft-ietf-netlmm-mip-interactions-06 > > Thanks for your review. Authors, do you have any responses? > > I personally support the idea of adding more term definitions. > > Jari > > Enrico Marocco kirjoitti: > > I have been selected as the General Area Review Team (Gen-ART) > > reviewer for this draft (for background on Gen-ART, please see > > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-netlmm-mip-interactions-06 > > Reviewer: Enrico Marocco > > Review Date: May 12, 2010 > > IETF LC End Date: May 17, 2010 > > > > > > Summary: This draft is on the right track but has open issues, > described > > in the review. > > > > > > Major issues: > > > > Terminology and acronyms are not used consistently, making the > document > > a very hard read for anyone who has no deep knowledge of the topic. > To > > improve readability, rather than simply referring to RFC 3753 (that > > defines only a subset of the terms used in the draft), the > Terminology > > section should provide even short definitions for terms like LMA, > MAG, > > MN, HA, AR, BCE, PBU, AR, MN-HoA, other than for CoA, HoA and HNP > that, > > as far as I understand, are synonyms of terms already defined. > > > > If the authors agree to add such definitions, then the first sentence > of > > S. 2. should be rephrased with something like: "Terminology used in > this > > document is consistent with the general mobility terminology defined > in > > RFC 3743." > > > > > > Minor issues: > > > > The RFC Editor will have a hard time taking care that the acronyms > are > > expanded the first time they appear in the text, and contracted > > thereafter (e.g. PMIPv6 and MIPv6 are used both expanded and in their > > compact form throughout the whole document, without apparently > following > > any particular logic). > > > > > > Nits/editorial comments: > > > > S. 1, third paragraph: s/all/some/ (or s/all/most of the/ if the > authors > > feel very confident). > > > > Figure 1, the preamble should be removed and replaced at the end of > the > > first bullet in S. 3 with something like "Figure 1 illustrates this > > scenario." > > > > Figure 3 and Figure 4 are actually Figure 2 and Figure 3; Figure 2 is > > Figure 4. The following comments assume correct numbering. > > > > S. 3, please provide a reference or some text describing what a > > "HMIPv6-MIPv6 interaction" is (also mentioned in S. 3.1). > > > > S. 3, sixth para: s/the above figure/the scenario illustrated in > Figure 2/ > > > > S. 3, sixth para: s/The following figure/Figure 3/ > > > > S. 3.2, first bullet in 1: provide a reference for IKEv2. > > > > S. 3.2, third bullet in 4: s/binging/bindding/ > > > > S. 4.2.1, last para: provide a reference and possibly some text > > describing the "R bit defined in NEMO". > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
