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

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

Madjid:
 
   First, I agree with your observation about architecture. In my
view, you cannot talk about mobility solutions, without having a
fairly specific functional architecture and topology in mind.
 
   Next, I guess I would say that the is exactly as I feared. At
the moment, I believe CT is still "a" protocol, not a number of
similar but different protocols. And, as I said in response to 
James, without this one to many capability, the protocol will 
not at all meet the objectives I had in mind when considering what
would be needed to enable proactive preparation for handovers 
and thus improve handover performance significantly. Consider
that 2G and 3G soft handovers require the equivalent of a 
one-to-many transfer of context to establish the active set.
 
  This requirement is now effectively eliminated from 
the list - that is, what you are stating is that it has been reduced
to a MAY so that the design team can ignore it . Since the design team
is a closed group, by the time this decision is apparent, it will
be too exhausting to argue that the "MAY" requirement should have
been included.
 
  There are many others requirements related to proactive CT
which very likely have no real meaning. I wonder if the IESG 
will spot them?
 
Gary

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[e-mail]]
Sent: October 4, 2002 16:13
To: Kenward, Gary [CAR:AN10:EXCH]; 'James Kempf'; [e-mail]
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.


 Gary,
 

reading your email, I was thinking to myself that many of the requirements
are in fact 
architectural requirements/features, until you mentioned it at the bottom of
your email.
 
I agree with you on the distinction, but I doubt if you can use CT as a
protocol
without paving the way for its use in the architecture. Otherwise there
would be no 
difference between CT and any messaging protocol.
 
 
Having said that, at this point, I felt that this support of this specific
feature would
cause conflict for some protocol design approaches that don't even need such
a feature.
While, the other features did not cause an alarm at the time of reading the
draft.
So call it may, call it Must optional, if that means I don't have to twist
the design to support
something that may not be needed in the first place. 
 
Regards,
 
Madjid
 
-----Original Message-----
From: Gary Kenward [mailto:[e-mail]]
Sent: Friday, October 04, 2002 9:44 AM
To: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; [e-mail]
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.



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]
<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]
<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
<https://www1.ietf.org/mailman/listinfo/seamoby>  
> _______________________________________________ 
> Seamoby mailing list 
> [e-mail] 
> https://www1.ietf.org/mailman/listinfo/seamoby
<https://www1.ietf.org/mailman/listinfo/seamoby>  
>