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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 22 Jul 2002 17:55:36 -0500

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