RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

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.

Is there any way you could live with the current structure (ie
background/definition + requirement/MUST in same sub-section)?
 
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
>>