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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Jul 2002 09:36:01 -0700

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Jul 2002 09:36:01 -0700

Madjid,

            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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Jul 2002 13:42:38 -0700

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 ?

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

- 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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Jul 2002 13:42:38 -0700

Madjid, Jim,

I have few comments.

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Jul 2002 16:03:03 -0700

Rajeev,

> Shouldn't we be concerned with requirements of the CT protocol in this

The intent of the requirements on feature context specification is to clarify
why certain aspects of the CT protocol requirements are unspecified or not
required, to provide the IESG with a more crisp description of why the
requirements are as they are. For example, if we decide either to specify that
any transport can be used or leave it unspecified, adding the section requiring
feature context specifications to nail down the transport explains why, rather
than that the general CT protocol requirements are vague.

Do you have a suggestion about how to better to do this? Perhaps not include the
requirements on the feature contexts as requirements, but as some explanatory
text in a separate paragraph?

> is that going to be useful if it is not supported by the underlying transport

WhatI had in mind here was things like retransmits for UDP or exponential
backoff, the kinds of details required by implementors who want to implement the
protocol. Typically, these don't tend to be such a problem with TCP (also maybe
SCTP thought I have never used it so I couldn't say for sure), but often there
is more to specifying transport with UDP than just saying to use UDP.

> itself, I do not have objections, but only wondering about the usage
scenarios..

Gary has some scenarios in mind. For example, proactively transferring a user's
SLA to a router well in advance of a handover, then having the SLA changed
because the user's subscription ran out or they decided to downgrade their
service. Update would not typically apply to cases where tight synchronization
with a handover was required, such as for header compression context.

                jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Jul 2002 16:27:03 -0700

> text in a separate paragraph?

Including a descriptive text makes sense and we should do that.

> is more to specifying transport with UDP than just saying to use UDP.

If a feature needs UDP and expects multiple retransmissions (more than say 2),
then it must use something like DCP. We should have normative text
discouraging features to develop their own congestion control mechanisms.

> with a handover was required, such as for header compression context.

Like many other things, this is feature-dependent. I am begining to think we should

put some text stating that each feature is responsible for defining its own
behavior and
the CT protocol itself is a carrier of message blobs. May be the paragrpah you
mentioned
above could state this as well..

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Jul 2002 16:03:03 -0700

Rajeev,

                jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Jul 2002 16:27:03 -0700

-Rajeev