[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt
Inline
> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: dinsdag 21 januari 2003 14:54
> To: Wijnen, Bert (Bert)
> Cc: Tewg (E-mail)
> Subject: RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt
>
>
> Hello Bert,
>
> >> -----Original Message-----
> >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> >> Sent: 21 January 2003 10:42
> >> To: Francois Le Faucheur (flefauch); Tewg (E-mail)
> >> Subject: RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt
> >>
> >>
> >> > Well, all the detailed requirements are grouped under section
> >> > 4 and they
> >> > are all "marked" with a "must" (or "should/may"). Seems like a
> >> > reasonably clear way to present them.
> >> > There is some (non-requirement) text preceding the actual
> >> requirements
> >> > to provide background/definition for the formulation of the
> >> > requirement.
> >> > I think it is best to keep all that together so one can
> >> understand the
> >> > requirements.
> >> >
> >> > The reason we did not capitalise the "must/should/may"
> is that this
> >> > document is going for Informational track so we were not sure
> >> > MUST/SHOULD/MAY were appropriate. Sounds like they are,
> so we will
> >> > follow your suggestion and capitalize them.
> >> >
> >> Mmmm.. take a look at RFC3216 sect 4 for example. I think
> such a form
> >> makes it really clear as to what exactly the requirement
> is and what
> >> type of requirement it is and what the motivation/explanation is.
> >>
>
> Yes, very neat. The structuring makes all of this very
> obvious, and I'll
> certainly look at this as a good model for requirements documents.
>
> But, while you cannot just have a quick look at the diff-te-reqts
> document and immediately count how many items are mandatory
> and how many
> are optional, my impression is that when you read the various
> sub-sections of section "4 Detailed Requirements", it is reasonably
> clear whether something is background, example, mandatory
> requirement or
> optional (It will be even clearer when capitalised). It is
> not as neat,
> since you do have to read the whole text and couldn't easily fill-in
> "compliance statements" saying we meet items x,y,z and don't
> meet items
> a,b,c; But practically speaking it has proved quite appropriate for
> guiding us in developping the DS-TE protocol extensions (which are due
> for WG Last Call very shortly).
>
> So, considering that the WG has been in agreement on the
> actual content
> for a while, and that the corresponding protocol extensions based on
> this are ready for Last Call, I'm inclined towards the
> approach of "not
> perfect, but does the job" and avoid significant editing changes just
> for easier identification of same content. This is all in the view of
> finalising that document asap, since it conditions all the DSTE work.
>
You should also wonder: can people who need to evaluate your protocol
specs (which I guess will go also through IETF Last Call, they
are intended for stds track, are they not?) can easily check how you
do in terms of meeting the requirments.
> Is there any way you could live with the current structure (ie
> background/definition + requirement/MUST in same sub-section)?
>
Although I think such a major editorial change would be VERY helpful
and useful, I can understand that you are a bit reluctant.
A simpler change could be in the following form (this is one example):
Take top of Page 12. It says:
Note that by definition:
- for a given Class-Type, there may be one or multiple TE-classes
using that Class-Type, each using a different preemption priority
- for a given preemption priority, there may be one or multiple TE-
Class(es) using that preemption priority, each using a different
Class-Type.
DS-TE must allow all LSPs transporting Traffic Trunks of a given
Class-Type to use the same preemption priority. In other words, DS-
TE must allow a Class-Type to be used by single TE-Class. This
effectively allows the network administrator to ensure that no
preemption happens within that Class-Type, when so desired.
If you would change it to (assuming I have destilled the requirement
correctly):
Note that by definition:
- for a given Class-Type, there may be one or multiple TE-classes
using that Class-Type, each using a different preemption priority
- for a given preemption priority, there may be one or multiple TE-
Class(es) using that preemption priority, each using a different
Class-Type.
MANDATORY REQUIREMENT: DS-TE must allow all LSPs transporting
Traffic Trunks of a given Class-Type to use the same preemption
priority. In other words, DS-TE must allow a Class-Type to be
used by single TE-Class. This effectively allows the network
administrator to ensure that no preemption happens within that
Class-Type, when so desired.
So start each paragraph that actually is a short description of
a requirement statement such that is is prefixed with the text
MANDATYORY REQUIRMENT: or OPTIONAL REQUIREMENT: as the case may be.
So they would still not be numberd (which makes referencing them much
easier) but at least they clearly stand out.
Maybe you could even do: MANDATORY REQUIREMENT nn:
where nn is a sequential number for each of the requirements, so
they in fact CAN be easily referenced later.
Bert
> Thanks
>
> Francois
>
> >> I was not so much worried aboutMUST/SHOULD/MAY not being
> capitalized.
> >> More that the explanantory text and the actual requirements and
> >> sometimes examples/scenario-text is all mixed.
> >>
> >> For example, could you easily tell me how many mandatoty and
> >> how many optional requirements there are?
> >>
> >> Bert
> >>
>