RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt

[Jim Boyle <jboyle@pdnets.com>]

Jerry - it is already specified in the requirements document that the
bandwidth constraint model must be specified in the technical solution
document:

	"The DS-TE technical solution must specify one
   default bandwidth constraint model which must be supported by any
   DS-TE implementation"

How = IETF process, Where = TEWG.  Do we really need to state that?

As for making comparisons between models in the draft, I don't think it's
called for.  I think making references to documents which describe them is
also something that isn't necessary in the requirements document.  As for
adding some text as to the decision must be made on "hard information" - I
see that as a no-value addition to the document.

What objection do you and Wai have to having this discussion in the
context of draft-ietf-tewg-diff-te-proto-00.txt ?

Jim

On Mon, 3 Jun 2002, Ash, Gerald R (Jerry), ALASO wrote:

> > The discussion on what should be the default bandwidth constraint
> > model should be done in the context of the solution draft.
>
> This should be stated as a requirement in Section 3.3 of the requirements draft.
>
> > The paragraph you quote makes it clear that the requirements draft leaves that
> > discussion squarely with the technical solution.
>
> Nowhere in Section 3.3 of the requirements draft is it stated how or where the technical solution will be decided.  It should be stated as a requirement in Section 3.3 that "the default BC model will be decided in the context of the technical solution draft."
>
> > I don't see a need for any text revision of the requirements draft before
> > sending it on to the IESG.
> > Anyone else have any comment?
>
> Yes.  An additional requirement should be added in Section 3.3:
> "the default BC model must be based on available hard information, such as analysis given in [forthcoming lai-id] [other relevant references]."
>
> Also, Wai Sum's suggested short explanation of the essence of his analysis is highly relevant to Section 3.3, and shouldn't be rejected out of hand.
>
> Jerry
>