RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.

["Gary Kenward" <[e-mail]>]

My comment is past due, so it is immediately ignorable, but worth stating
if only for future reference....

When I first read through Madjid's proposed change my reaction was simply,
and honestly, I did not really care. Manufacturers and network engineers
have been known to ignore IETF recommendations in the past, so changing
SHOULD to MAY did not seem to have much impact.

However, in considering the change a second time (in the process of updating
the draft), I sensed a subtle problem in the argument; a problem that has 
been discussed in the past in this group. Madjid, if I have misinterpreted
your reasoning, please correct me. 

The CT requirements draft is NOT, as far as I know, a requirements document
for the deployment of a system that supports CT. Clearly, a deployment of CT
capabilities would be at the discretion of all the entities involved in
actually
building the network - the network operator, the network engineer, and even
as
Madjid points out, the equipment vendor. It would be reasonable to try and 
anticipate those CT features that an operator might want to be optional, 
BUT ONLY IF THIS WAS A SYSTEM REQUIREMENTS DRAFT.

The CT requirements draft IS a requirements draft for the CT protocol. It is

intended to provide a template for eventual protocol draft submissions.
Ideally, 
out of these submissions, only one proposal will be selected. A MAY in the
CT 
requirements draft essentially states that a protocol proposal need not
consider 
supporting this feature. A MAY in the CT requirements draft does NOT mean
that
the feature should be one that can be optionally enabled or disabled by
someone
implementing or deploying the CT solution. A MAY clearly indicates that
protocol
proposals can completely ignore the requirement, and if one of these
protocols
is selected by the working group, the feature will likely never be available
to
the vendor, the network engineer or the operator.

The proper way to specify requirements that must be supported by the CT
protocol,
but must also must be optional for implementation is to state that in a
second
requirement. Thus, 4.6 should not be changed to a "MAY", but should be
augmented
with a second requirement that states that 4.6 MUST be an optional feature.

In identifying this subtlety, I wonder how many of the requirements in the
CT
draft are actually system requirements and not protocol requirements. I am,
at this point, somewhat hesitant to look at this point. However, a CT
protocol
that does not support of feature means that the feature will never be
available
to anyone.

Gary Kenward

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[e-mail]]
> Sent: September 24, 2002 12:19
> To: 'James Kempf'; [e-mail]
> Subject: RE: [Seamoby] Reminder: Last Call for CT Reqirements 
> Ends Wed.
> 
> 
> Reading from 2119
> 
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course
> 
>    MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item 
> because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the 
> same item.
>    ......
>    
> 
> It means you need to fully understand the implication of not 
> supporting
> a SHOULD item, before you exclude it. On the other hand if it 
> is something
> that may be useful in some cases, a may is more appropriate. 
> 
> Looking at 4.6, I would say one-to-many context transfer is not
> an item that its "not use" needs to be investigated, but its "use" 
> needs careful considerations. 
> Example:
> If you are dealing with dynamic context that is affected by 
> flow of data
> at a specific AR (header compression, or measurement based 
> QoS context)
> sending the context through a whole bunch of ARs that may not even see
> the data causes serious synchronization issues for such context.
> 
> Based on this counter-example:
> I say this requirement should be changed to "may" unless it 
> is stated that
> SHOULD only applies to the context whose value is not 
> affected by data flow.
> 
> Madjid
> 
> -----Original Message-----
> From: James Kempf [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 11:24 AM
> To: [e-mail]
> Subject: [Seamoby] Reminder: Last Call for CT Reqirements Ends Wed.
> 
> 
> A reminder: last call for the CT requirements document
> (draft-ietf-seamoby-ct-reqs-04.txt) concludes on Wed. Sept 
> 25. So far, we have
> not received any comments. If you have any comments, please 
> send them to the
> list by that date.
> 
>             jak
> 
> _______________________________________________
> Seamoby mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/seamoby
>