Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 23 Jul 2002 15:54:33 -0500

Rajeev,

please see below,

Regards,

Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 3:43 PM
To: James Kempf
Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

Madjid, Jim,

I have few comments.

- it is not clear to me, from the proposed text, what requirements do the
requirements on feature context specification impose on the CT protocol.
Shouldn't we be concerned with requirements of the CT protocol in this
particular document ?

Madjid>> Agreed, That is why I have been advocating for SHOULDs whenever
there is a requirement that is not needed for all features, and striving
to keep requirements as generic as possible.

- regarding the transport text, if a particular feature indicates UDP/TCP
or SCTP, isn't that sufficient ? Even if it can provide more information,
how
is that going to be useful if it is not supported by the underlying
transport
protocol ?

Madjid>> First of all, not everybody and every feature need an advanced
transport and I know we agree on this.
However, say in 6 months we are debating an specific feature that does need
reliability. This text is to protect us from sloppy design. 
If you remember Jeff Schiller saying: Don't come and say use
IPSec if you want security, you need to work on the security details.

Example of a case which even SCTP is not going to cut it (this is
answer to your next question as well): say you are sending a very
dynamic context (packet count or HC context) and you want reliability
(and you got time to resend stuff...).
You send the context, but due to do channel conditions don't get it through,
next time, you have to send updates. This has to come from the feature unit
and
not from transport layer. If had just said use SCTP for reliability that
would not be a robust design.

- which scenarios demand context updates ?
It seems to me that once you transfer state, you would
like to use the state on the new node as soon as possible (right away) and
stop
using state on the old node as the reference.
Since this does not impose any special requirements on the CT protocol
itself, I do not have objections, but only wondering about the usage
scenarios..

Thanks,

-Rajeev

James Kempf wrote:

> Madjid,
>
> The additions look fine to me. I'll fold them into the proposed text. We
need to
> wait until Gary is back from vacation to see what he has to say.
>
>             jak
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>; <[email-masked]>
> Sent: Monday, July 22, 2002 3:55 PM
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context
> Specifications
>
> > James,
> >
> > thanks for making the effort you made on this section.
> > and thanks for trying to expedite this process.
> >  I like most of it except a few minor comments
> > based on the history of discussions.
> >
> > Please see below.
> >
> > BR,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: James Kempf [mailto:[email-masked]]
> > Sent: Friday, July 19, 2002 8:26 PM
> > To: [email-masked]
> > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context
> > Specifications
> >
> >
> > I'd like to propose the following new section for the CT requirments
listing
> > requirements on feature context specifications. Note that this section
does
> not
> > place requirements on the feature context protocols themselves, but only
on
> > their specifications.
> >
> >             jak
> >
> > ------------------------------------------
> >
> > 5.8 Feature Context Specifications
> >
> > The context transfer protocol provides a basic framework in which
feature
> > contexts of varying types can be transfered. Recognizing that the
particular
> > feature contexts may have very different needs with regard to update,
> > synchronization, and transport, this section contains requirements on
the
> > feature context specifications. Note that these requirements do not
constrain
> > the actual feature context protocols themselves, but only their
specification.
> >
> > 5.8.1 A feature context specification MUST contain an IANA assigned type
code
> > for the particular feature context. If an experimental feature context
> protocol
> > is being developed, a type code from the context transfer protocol's
> > experimental range SHOULD be used. The type code is used in the context
> transfer
> > container to identify the feature context.
> >
> > 5.8.2 A feature context specification MUST define the byte layout of the
> > individual elements of the feature context, and how those map into the
context
> > transfer protocol's container. The byte layout SHOULD obey standard IETF
> > conventions with regard to mapping of data into on the wire format.
> >
> > 5.8.3 A feature context specification MUST define the transport to be
used. If
> > the feature context is transferred using an IETF transport layer
protocol ,
> then
> > the feature context specification MUST include the full details of how
the
> > transport layer protocol is used.
> >
> > Madjid>> This would impose a little bit of vertical design and might
again
> lead to
> > heated debates on whether to use UDP/SCTP.... Don't know if the
following
> > addition within <> helps:
> >
> > Madjid>>
> > "If the feature context is transferred using an IETF transport layer
protocol
> ,
> > <and relying on specific mechanisms of the transport layer protocol,
such as
> > reliability or timing mechanisms>, then
> > the feature context specification MUST include the full details of how
the
> > transport layer protocol is used. <One must note that employing
different
> > transport mechanisms for different feature context might lead to limited
> > possibility of multiplexing various feature contexts>"
> >
> >
> >
> > If the feature context is transferred as an
> > option on another IETF protocol, then the feature context specification
MUST
> > define the mapping of the context transfer container into the other
protocol's
> > standard option format. If the feature context is transferred through a
> non-IETF
> > protocol (such as IAPP [4]), then the feature context protocol
specification
> > MUST define how the standard context transfer container is mapped into
the
> > non-IETF transport.
> >
> >
> >
> > 5.8.4 A feature context specification MUST indicate whether update to
context
> > information is allowed if changes in the source occur after the context
is
> > transferred. If such changes are allowed, the feature context
specification
> MUST
> > define the change protocol message format using the standard context
transfer
> > container, and MUST include details of how the update is accomplished
<and
> triggered>.
> >
> > Madjid>> See the addition above. The external trigger might be needed.
> >
> > 5.8.5 A feature context specification MUST indicate whether the context
> transfer
> > is tightly synchronized with external events, such as handover. The
freature
> > context specification MUST indicate what event or events trigger
transfer.
> >
> > 6.0 References
> >
> > [4]  "Recommended Practice for Multi-vendor Interaccess Point
Interoperability
> > via an Inter-access Point Protocol Across Distribution Systems
Supporting IEEE
> > 802.11 Operation," IEEE Std. 802.11f/D3,  January, 2002.
> >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby

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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Jul 2002 14:24:23 -0700

Hello Madjid,

Nakhjiri Madjid-MNAKHJI1 wrote:

> and not from transport layer. If had just said use SCTP for reliability that

When you have to send an update, you do it whether or not SCTP failed to
get it through in the first case, right ? What SCTP or a reliable transport
protocol will offer you is the ability to send a message reliably. When you
have a new message or an update, I agree the feature code has to supply it
(and SCTP has to get to the destination reliably)!

I hope you are not indicating that each feature has to design its own reliable
transmission protocol. The way each feature uses SCTP or UDP is internal
to the feature, and is not a function of the CT protocol itself. The
CT protocol
should define a set of messages that can be carried over different transport
protocols.

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Jul 2002 14:24:23 -0700

Hello Madjid,

Regards,

-Rajeev