Document: draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
Review: Michael A. Patton
Date: 27 oktober 2004 

Summary: This draft is ready for publication as an Informational RFC

I managed to comprehend the whole document, in isolation.  But,
without an understanding of the several ITU references, none of which
I've read, I can't comment on whether it is really a good set of
requirement definitions.



General comment:  There's a bit of cognitive disonance in the
terminology because of the meshing of circuit switching and packet
switching in the descriptions.  I don't think this is enough to slow
the document.  If the document does go through another round, I might
be persuaded to catalog some of them.  However, once I realized that I
needed to do a TPC to TCP mapping of terminology, it all became clear.


In sections 4.5.1 and 4.5.4 the term SRLG appears, but is never
expanded or explained.  While it may be explained in one of the
references, at least expanding it at first use would be nice.  Neither
of the references is important enough to make this a restrictive
problem, but it would be nice to have an expansion.


typos
-----

Section 3 "provides among other capabilities support"
       => "provides, among other capabilities, support"

bottom of pages 5 and 13 have orphaned section headings.

Section 4.2 "SHOULD not" => "SHOULD NOT"

Section 4.2 the last sentence of paragraph 3 ("This MAY be achieved
   using a number of mechanisms.") doesn't really say anything.  It's
   the way you lead into a list of the said mechanisms, but there
   isn't a list, so that construct is meaningless.  I think what they
   meant was "This specification does not restrict the mechanisms by
   which this may be achieved."

Section 4.5.4 under "Connection Types" shouldn't the abbreviation for
   "Termination Connection Point" be TCP (a confusing one, I must
   admit, but not as confusing as having them both be the same)?  It
   certinly seems to be referenced this way at other points in the
   document.  And later that assumption is verified by the Terminology
   section.



One typo seems to be systematic, the word "bounded" is used where
"bound" is obviously meant.  Interestingly enough there are a few
places where the words are used correctly.  These are the erroneous
uses that I found:

Section 4 "at each RC bounded to the same RA"
       => "at each RC bound to the same RA"

Section 4.2 "RC(s) bounded to a RA" => "RC(s) bound to a RA"

Section 4.5.2 "the advertisement is bounded"
	   => "the advertisement is bound"

Section 6 "RCs bounded to different" => "RCs bound to different"

and the related one:

Section 6 "when multiple RCs bound to a single RA"
	should either be
		"when multiple RCs are bound to a single RA"
	or	"when multiple RCs bind to a single RA"
	I think the first of those two is more correct.