Adrian: > -----Original Message----- > From: Adrian Farrel [mailto:[email protected]] > Sent: Friday, March 13, 2009 2:07 PM > To: Ben Campbell; PAPADIMITRIOU Dimitri; General Area Review Team > Cc: [email protected]; [email protected] > Subject: Re: Gen-ART LC review of > draft-ietf-ccamp-gmpls-ason-routing-ospf-07 > > Hi Ben, > > Thanks for your review. > > Dimitri, need your help! > See in line below. > > Adrian > > > Minor issues: > > > > -- Section 9.1: > > > > This section shows the sub-TLV types as TBD, but at least > some of the > > references sections specify type numbers. > > OK, I found section 9.1 > | Value Sub-TLV > Reference > | ----------- -------------------------------------------- > ---------- > | TBD Local TE Router ID > [This.ID] > > But, in section 5.3 > | The Type of the Local TE Router-ID sub-TLV is 5 > > Similarly, > | TBD Local and Remote TE Router ID > [This.ID] > > But, section 5.2 > | The Type of the Local and Remote TE Router-ID sub-TLV is 17 > > Also, > | TBD Node IPv4 Local Prefix > [This.ID] > | TBD Node IPv6 Local Prefix > [This.ID] > > But in section 3 > | - Node IPv4 Local Prefix sub-TLV: Type 3 - Length: variable > | - Node IPv6 Local Prefix sub-TLV: Type 4 - Length: variable > > Dimitri, are these values: > - required > - desired > - suggested?
The former. > > Nits/editorial comments: > > > > -- general: > > > > It would be helpful to have referenceable numbers for the > TLV format > > figures. > > Yeah, might be nice, but since the figures are not referenced > outside the > section in which they appear, I think we won't bother this time. usually we ref. the sub-section itself. > > Using non-mnemonic citations as if they were nouns in a > sentence creates > > extra work for the reader, who must flip back to the references to > > understand the sentence. That is, the form "...defined > in [xxx]". It's > > better to say "defined in foo [xxx]". It's not as bad with > mnemonic > > citations (e.g. "defined in [foo]"), but it can still > cause confusion if > > text is quoted in other documents without the associated reference > > section. > > Hmmm. > This notation seems to be used pretty widely. > I'd hate to see text that said "..defined in RFC 1234 [RFC1234]." :-) it is correct but as most IETF refs. are RFCs it reads often like Adrian states. > > -- section 2, 2nd paragraph: "The > > limit of the subdivision results is an RA that contains just two > > sub-networks interconnected by a single link." > > > > I don't follow the last sentence. Is it possible "results > is" was meant > > to be "results in"? > > Yes. Thanks. > > > -- section 3.1, last paragraph, first sentence: "The local > addresses that > > can be learned from Opaque TE LSAs." > > > > incomplete sentence. Is "that" spurious? > > Good catch. > OLD > The local addresses that can be learned from Opaque TE > LSAs. That is, > router address and TE interface addresses SHOULD NOT be advertised > in the node IPv4 local prefix sub-TLV. > NEW > The local addresses that can be learned from Opaque TE > LSAs (that is, > the router address and TE interface addresses) SHOULD NOT be > advertised in the node IPv4 local prefix sub-TLV. > > > section 3.2, first paragraph after the figure: "Length is > set to Sum[n] [4 > > + #32-bit words/4] where n is the > > number of local prefixes included in the sub-TLV." > > > > I'm not sure I understand the expression. > > But you think you might? :-) > > Hard doing scientific notation in ASCII, isn't it? > OLD > Length is set to Sum[n][4 + #32-bit words/4] where n is the > number of local prefixes included in the sub-TLV. The > encoding of > each prefix potentially using fewer than four 32-bit words is > described below. > NEW > Length is set to the sum over all of the local prefixes > included in > the sub-TLV of (4 + (number of 32-bit words in the prefix)/4 ). > The encoding of each prefix potentially using fewer than four > 32-bit words is described below. correct. > > -- section 4.1, 3rd paragraph: > > > > Please expand LSC and PSC on first use. > > oke > > > -- section 6, 3rd paragraph: > > > > s/informtation/information > > oke > > > -- idnits reports the following: > > Who can keep up with the IPR change rate? > All IPR notices correct at time of submission. > No doubt they will be updated and correct many times in the > next weeks. is there something specific here to be done from my side ? much thanks, -dimitri. > Many thanks, > Adrian > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
