Hi Ben,
New revision just out fixes the issues.
Thanks again.
Adrian
----- Original Message -----
From: "Ben Campbell" <[email protected]>
To: "PAPADIMITRIOU Dimitri" <[email protected]>
Cc: "Adrian Farrel" <[email protected]>; "General Area Review Team"
<[email protected]>; <[email protected]>; <[email protected]>
Sent: Tuesday, March 17, 2009 7:54 PM
Subject: Re: Gen-ART LC review of
draft-ietf-ccamp-gmpls-ason-routing-ospf-07
For the record, this email along with Adrian's address all of my
comments.
Thanks!
Ben.
On Mar 13, 2009, at 8:19 AM, PAPADIMITRIOU Dimitri wrote:
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
