Subject: [Seamoby] Section 5.2 in CT Requirements

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Jul 2002 04:14:16 -0700

Folks,

So recently I had another look at the CT Requirements document and I was
suprised to find Section 5.2. It says this:

    5.2 Transport Reliability

       This section is intentionally left blank as the working group is
       waiting for a questionnaire from the transport directorate. The result
       of the questionnaire will create requirements that will be added in this
       section in a later revision of this specification.

It is completely unacceptable that we sent this document to the IESG with this
section in it. When a document passes through last call, it should be complete.
As WG chairs, Pat and I naturally must accept responsibility for this, but this
should really have been caught in WG Last Call.

I would like suggest replacing Section 5.2 with the following:

    5.2 Transport Requirements

        This section contains requirements on the context transfer transport.

    5.1 Independence of Underlying Transport

        The context transfer solution MUST be independent of the underlying
transport. It SHOULD be possible to transfer
        context directly on top of reliable transports, such as TCP or SCTP,
unreliable transports, such as UDP, or as an
        option or extention on another protocol, such as handover signaling.

Comments?

            jak
   u

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

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 18 Jul 2002 11:16:26 -0400

James:

 There was a long and arduous debate over transport reliability.
The wording you are objecting to was, I believe, Allison's suggestion.
At the very lease, it was inserted with her approval in order to move
the requirements forward.

 Of course, you can open the debate again, but I don't expect it to
be resolved any better then it was the last time through. The problem
is that there seems to be some very different ideas in the wg as to
what the CT protocol looks like, with contradicting assumptions as
to what is needed from a transport layer.

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: July 18, 2002 07:14
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Seamoby] Section 5.2 in CT Requirements
> 
> 
> Folks,
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 18 Jul 2002 16:00:19 -0500

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 6:14 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Seamoby] Section 5.2 in CT Requirements

Folks,

       This section is intentionally left blank as the working group is
       waiting for a questionnaire from the transport directorate. The
result
       of the questionnaire will create requirements that will be added in
this
       section in a later revision of this specification.

It is completely unacceptable that we sent this document to the IESG with
this
section in it. When a document passes through last call, it should be
complete.
As WG chairs, Pat and I naturally must accept responsibility for this, but
this
should really have been caught in WG Last Call.

        This section contains requirements on the context transfer
transport.

Comments?

Madjid>>
I second Gary's comments. The wording was suggested to us.
I also remember the very long debate of reliability and the fact
that some folks wanted reliability and some didn't.
Our TEXT proposal shows that you can add reliability to CT if
you want it and is not offered to you.

Good suggestion on 5.1. 
I am ok with your 5.1 formulation, I think it should make everybody
happy by leaving enough flexibility there. However, I am not sure how
I can prove independance of transport for our proposal even, i.e. the
first MUST in 5.1.
Don't know why the 5.2 (This section....) is still there.

Madjid

            jak
   u

---

From: [email-masked]
Date: Fri, 19 Jul 2002 11:37:33 +0300

Hi James,

A suggestion.  Could we ask from Allison to defer this discussion (i.e. -
drop the requirement completely from the requirements).  A much better
way forward would be someone to produce a short document discussing
different protocols that CT could use.  The pros & cons of each.

The list that has been discussed (if I remember correctly) are:

	1) UDP
	2) TCP
	3) SCTP
	4) PR-SCTP (formerly U-SCTP)
	5) ICMP 
	6) DCCP (formerly DCP) - this one wasn't discussed, but is possible.

Additionally, we have discussed a possible framework approach for CT solutions,
so I am not sure if we need to specify a single transport protocol - if
we go down a framework path.

John

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:00:46 -0400

The question is whether there is wg consensus. Which was not
reached at time of writing section 5. I'm not defending 
the situation, simply informing you. Perhaps this time it will 
not be an issue.

The *technical* problem with your requirement - and I am only
trying to recapture what others objected to - was that there
was a significant number of people who wanted to define a
transport solution for CT, based upon CTs unique needs. Some
wanted transport capabilities built into CT. The melt down came 
when the wg started debating these needs, as the CT solution was 
not (and is not) defined, the transport needs are pure speculation, 
or based upon individual approaches. Thus, the decision to defer the 
CT transport evaluation until a CT solution - and the transport needs 
- where better known.

BTW: the format you have used is not the standard format
     decided upon by the working group, which was to use
     section headers as the requirements (I believe this
     was Pat's suggestion). One requirement per section.

     We can, of course, change  the style, but all of
     the requirements would have to be re-written.

Gary

> Sent: July 18, 2002 18:59
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Seamoby] Section 5.2 in CT Requirements
> 
> 
> Gary,
> 
> It isn't a question of debate. We've been talking about these 
> requirements for a
> year and a half, it is time to complete them.
> We need to nail down this section.
> 
> Do you have any specific technical comments on the requirement?
> 
>             jak
> 
> ----- Original Message -----
> From: "Gary Kenward" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 18, 2002 8:16 AM
> Subject: RE: [Seamoby] Section 5.2 in CT Requirements
> 
> 
> > James:
> >

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:37:16 -0400

So into the breach, once more we go....

> Sent: July 18, 2002 19:18
> To: [email-masked]; Nakhjiri Madjid-MNAKHJI1;
> [email-masked]
> Cc: [email-masked]
> > I know that there was concern by the IESG on this very 
> topic, and the idea of
> > the above text was a compromise with the area director, who 
> was going to
> > initiate a discussion with the transport directorate. 
> Unfortunately, this
> > never occured, and the text remained. Allison had suggested 
> that we continue
> > with the non-transport discussions and that this topic will 
> resurface again
> > in the future.
> >
> > The question is whether this can occur after the document 
> can be published
> > (perhaps without the section).
> >
> 
> Harald made a comment in the IESG Plenary on Wed. nite about 
> working groups
> submitting documents with "to be defined" to the IESG. This 
> document qualifies,
> IMHO.
> 
>             jak
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:37:16 -0400

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:47:35 -0400

James:

 Frankly this discussion is getting silly - he said, she said.
You may speculate forever what did or did not transpire, but I recall
clearly the discussion, which included Allison, and the decision was
to defer the work on a transport requirements until we started working
on a solution. Note well, that this decision was made in order to get
the requirements completed, which is the same goal you strive for.

 So, let's move on. If the IESG has commented that this section is
inappropriate, or if the wg believes that it is inappropriate, then
let's change it.

 And so, we have three choices:

   1. Leave the section as is and see if the IESG buys the logic or not.
      (I personally think the IESG is smart enough to realize the complexity
       of the problem and the cart and horse situation we are dealing with
       here).

   2. Remove the section entirely
      (which I don't think will fool anyone)

   3. Attempt to resolve the issue
      (The last debate went on for, oh, about six months)

If this is truly up to the wg, then perhaps you should as the wg which
option
is preferred.

Gary

> Sent: July 19, 2002 09:04
> To: Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1; [email-masked]
> Cc: [email-masked]
> Pat,
> I don't think Allison intended that the document go to the 
> IESG with this text
> in it, though I have not had an opportunity to speak with her 
> about it. But
> ultimately
> she is not responsible for the working group documents, that is the
> working group's responsiblity. We should have pulled that 
> text out before we
> sent it to the IESG, and, ideally, had something to replace 
> it. If, at that
> point, the IESG had a technical disagreement with our 
> proposed requirement,
> then we would have heard back.
> 
> I think we at least have to propose a requirement, which is 
> what the text I sent
> was intended to do.
> 
>             jak
> 
> 
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jul 2002 10:47:35 -0400

James:

Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 10:59:09 -0500

Hi John,

I think this will just delay things, the reason:
you need to look at each protocol individually and determine
its reliability needs, not to mention design scenarios for every
person's network.

Not to mention that you have found somebody who wants to do this
study :)
I think we have waited long enough for requirement.

James' formulation is avoiding this whole discussion in a very neat way.

Regards,

madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 19, 2002 3:38 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

Hi James,

	1) UDP
	2) TCP
	3) SCTP

John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 10:59:09 -0500

Hi John,

Regards,

madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 19, 2002 3:38 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

Hi James,

	1) UDP
	2) TCP
	3) SCTP

John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 11:18:32 -0500

I think, in the interest of getting things forward, we should focus
on what IESG wants now, not 1 year ago (BTW I didn't like the
previous course of action we took). I think James is being constructive
by suggesting reliability requirements and I added my modification on it.
 
Lets go from there  and get this going :)
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 19, 2002 9:48 AM
To: 'James Kempf'; Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1;
[email-masked]
Cc: [email-masked]

James: 

Gary 

> From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> I think we at least have to propose a requirement, which is 
<https://www1.ietf.org/mailman/listinfo/seamoby>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 19 Jul 2002 11:18:32 -0500

Madjid
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Friday, July 19, 2002 9:48 AM
To: 'James Kempf'; Pat R. Calhoun; Nakhjiri Madjid-MNAKHJI1;
[email-masked]
Cc: [email-masked]

James: 

Gary

---

From: [email-masked]
Date: Mon, 22 Jul 2002 06:42:39 +0300

Hi Madjid,

> study :) I think we have waited long enough for requirement.

What I think we want to do is progress the requirements, without
a detailed discussion on reliability, as that has been a rathole.

I think we need a short document, listing some transport options,
and with some pro's & con's. This could be a living document.  I'd
be happy to edit folks suggestions into a document.

I see the following options:

	1) ICMP
	2) UDP
	3) TCP
		a) reuse existing TCP connections
		b) dynamic TCP connections
	4) SCTP
		a) reuse existing TCP connections
		b) dynamic TCP connections
		c) PR-SCTP
	5) DCCP
	6) other 
		a) routing protocol extensions
		b) ?

John

---

From: [email-masked]
Date: Mon, 22 Jul 2002 06:42:39 +0300

Hi Madjid,

	1) ICMP
	2) UDP
	3) TCP

John

---

From: [email-masked]
Date: Mon, 22 Jul 2002 06:42:37 +0300

Hi James

I disagree with your requirement, because I don't see a lot of meaning
and/or use in it.

I think that different context may have different need.  Timelyness &
reliability are 2 different and opposing needs.  This is directly
relatable to the earlier discussion on dynamicisity of context.
A situation could occur where a context goes stale during re-transmission
when running over a reliable protocol.  Some other context, such as security
may not time out, unless the end-user completely times out of the user-session.

Besides going stale, it is entirely possible that some context may
be superceded.  As this issue is fairly complex and intertwined with the
context being transfered, I suggest we don't have a reliability requirement, 
but rather we try to do an analysis of the reliability needs and then 
take this into the solution.

Additionally, I don't think that we want to get into defining new
transport protocols or behaviors.

John

===

  The context transfer solution MUST be independent of  the underlying 
  transport. It SHOULD be possible to transfer context directly on top of 
  reliable transports, such as TCP or SCTP, unreliable transports, such as UDP, 
  or as an  option or extention on another protocol, such as handover signaling.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 22 Jul 2002 18:06:57 -0500

Hi John,

Well I won't say no to a giving hand :)
If you like to take on this effort, that is fine, as long
as the reliability requirements of CT and CT requirement RFC
process does not have a dependancy on completion of this draft.

I am glad James brought the IAPP example, already we are
seeing people moving away from IETF CT because it has been
delayed so much. I think James' effort in reviving the CT
work is very valid and constructive (given that some of us now
have some hindsight with CT, we have dealt with reliability
issues in our draft making zero assumptions about transport layer.
Please let me know if I can send our draft to you).

I think James is leading in the right direction, given
that CT needs some CPR right now, and then once
we get into solutions and specific features, things will 
become more clear.

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, July 21, 2002 10:43 PM
To: Madjid Nakhjiri; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

Hi Madjid,

	1) ICMP
	2) UDP
	3) TCP

John

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 22 Jul 2002 18:06:57 -0500

Hi John,

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, July 21, 2002 10:43 PM
To: Madjid Nakhjiri; [email-masked]
Cc: [email-masked]
Subject: RE: [Seamoby] Section 5.2 in CT Requirements

Hi Madjid,

	1) ICMP
	2) UDP
	3) TCP

John

---

From: [email-masked]
Date: Tue, 23 Jul 2002 09:21:58 +0300

Hi James,

> That is exactly why I proposed this requirement. The intent 
> of this requirement,
> together with the newly proposed Section 5.8, is that it 
> would be up to the
> particular feature context profile to specify the transport.
> 
> Here's an example of why I think the requirement is needed.  
> 802.11 specifies
> its own context transfer protocol, namely IAPP. If we specify 
> that, for example,
> SCTP is required for transport, vendors on 802.11 would have 
> to implement two
> context transfer protocols, IAPP and the Seamoby SCTP-based 
> protocol. IMHO, it
> makes sense to only have one context transfer protocol and 
> leverage a particular
> transport for the feature contexts that need it.
> 
> Does this make sense?

It makes sense, but this sounds much more like solution space
than requirements.  

John

---

From: [email-masked]
Date: Wed, 24 Jul 2002 06:54:53 +0300

Hi James,

> It is solution space, but it motivates the requirement that 
> the generic CT protocol not specify a particular transport.

Sounds OK to me then, let's put this one to bed.

John

---

From: [email-masked]
Date: Wed, 24 Jul 2002 06:54:53 +0300

Hi James,

John