Re: Some comments on draft-ietf-multi6-v4-multihoming-02.txt
Kurt Erik Lindqvist <[email protected]> Tue, 2 Nov 2004 15:00:12 +0100
| Newsgroups | gmane.ietf.multi6 |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (as co-author) On 2004-11-02, at 08.02, Thierry Ernst wrote: > - A table of contents is missing Good catch. I guess that will get caught in the nits check. Thanks! > Introduction > > - a sentence detailing the structure of the document (from section 2 > till end) would help. Do you think the document is long enough to need this? > - particularly, the abstract nor the introduction give me a hint of the > content of section 5. Ok. > Section 2: > > - all terms but one (mullti-addressed) are defined in RFC3582, why not > saying it ? (I'm OK with repeating the definitions, though) As they are so few I thought it made it more readable to repeat them. > Section 4.3 > > - I don't get the meaning of "having their upstreams remove those on > announcement". Their upstreams what ? The same occurs in orher parts > of > the text. "those" refer to the private ASes. > Section 5 > > - what is the purpose of this section ? It says "analysis of the > features...". Is this an analysis which goes through the > goals/requirements defined in RFC3582. May sound like it since the > "Simplicity", "Transport-Layer Survivability" etc are defined in > RFC3582. (I know draft-v4-multihoming is about the "IPv4 experience", > but it's not so clear from reading the text which document inherits > from > the other one, so this paragraph or Section 1 may be improved). Originally these where written as compliments to each other. Not sure if that still holds to 100%. > Section 5.4 > > - Typo in "A single-home client a multi-homed site" Thanks. > Section 6.1 > > - Typo: remove 's' in 'might explains' Thanks! > - higher growth: in what ? In the (number of) the multihomed sites ? yes, and to me that is pretty obvious from that sentence. > - I would also suggest "state" -> amount of state. It might be useful > to > specify what kind of state, for the novice reader (unless we assume > this is obvious to the reader). Agreed. > - no need for a section "6.1" if there is no section 6.2. Thanks! As the table of contents is a show-stopper for the nits checking, I need to make an update anyway and will include the other remarks. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQYeS9qarNKXTPFCVEQJxqwCglKDNM7CuZvBhoNSPNRA+rO9qhl4AoKX8 M0szxsxv5mOTyLuwmQiWJJPq =YDbX -----END PGP SIGNATURE-----