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

["James Kempf" <[e-mail]>]

Gary,

Design teams are only closed while they are designing. The last word on the
design comes from the working group. If the design team neglects something that
you think is important, then you're perfectly free to bring it up after the
initial design is complete. If the working group agrees, then it will become
part of the design.

            jak

----- Original Message -----
From: "Gary Kenward" <[e-mail]>
To: "'Nakhjiri Madjid-MNAKHJI1'" <[e-mail]>; "'James Kempf'"
<[e-mail]>; <[e-mail]>
Sent: Friday, October 04, 2002 1:41 PM
Subject: RE: [Seamoby] Reminder: Last Call for CT Requirements Ends Wed.


> 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>
> >
>
>

_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby