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

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 13:20:25 -0400

James:

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: July 19, 2002 21:26
> 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.

What is "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. 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.

Does this mean that the fcs must describe how the ARs perform the update?
Doesn't this address router functionality?

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

For what purpose? The fcs should define the context information
that the destination is to expect. What would the destination
router do with this information? 

It is apparent what the source router might do with this information,
but why does it need to be standardized? E.g. if a router manufacturer
wishes to update context every 10,000 clock ticks, what concern is
this to the IETF?

Gary

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

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

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 13:31:41 -0400

Madjid:

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: July 22, 2002 18:56
> To: 'James Kempf'; [email-masked]
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on 
> Feature Context
> S pecifications
> 
> 

*snip*

> 
> If the feature context is transferred as an

What did you mean by "standard option format"? CT, as we have
been discussing it, is a container protocol, defined around 
context "chunks". Are you implying that it should also allow
for encoding of context into the option fields of other protocols???

Gary

*snip*

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 13:31:41 -0400

*snip*

Gary

*snip*

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 6 Aug 2002 13:20:25 -0400

What is "wire format"?

Gary

Looks good.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 8 Aug 2002 15:57:27 -0500

Gary,

I am sorry, I think you took the "context" out of the discussion by snipping
the rest of the comments :)
The following text suggested by James captures the issue:

Madjid

> 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
> experimental range SHOULD be used. The type code is used in the context
transfer

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, August 06, 2002 12:32 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked]
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S
pecifications

*snip*

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 8 Aug 2002 15:57:27 -0500

Gary,

Madjid

code
protocol
transfer

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, August 06, 2002 12:32 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'James Kempf'; [email-masked]
Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context S
pecifications

*snip*