Subject: RE: [Seamoby] Candidate for New WG Draft

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 26 Jun 2003 09:49:20 +0300 (EEST)

Hi,

I haven't reviewed the draft yet, but it might be a good idea to have in 
Seamoby something like the DCCP User Guide draft. Something that tells 
more than RFC3374. Still, the document should talk about more than one use 
case, though.

Jukka

On Wed, 25 Jun 2003 [email-masked] wrote:

> Hi James
> 
> I support this idea.  Actually, it simplifies the CTP document,
> I have an open issue (not logged) to provide more of this kind of
> detail to CTP.  If this is in a seperate doc, it simplifies things
> greatly.
> 
> John
> 
> > -----Original Message-----
> > From: ext James Kempf [mailto:[email-masked]]
> > Sent: 24 June, 2003 21:18
> > To: [email-masked]
> > Subject: [Seamoby] Candidate for New WG Draft
> > 
> > 
> > Folks,
> > 
> > As a compliment to the CT draft, Pat and I think it would be 
> > sensible to
> > have a draft that describes how CT could be used for a 
> > particular context.
> > In the past, Seamoby has not focussed on this, since our 
> > position has been
> > it is up to other WGs that have responsibility for the 
> > particular feature to
> > do the design work for that feature, but we keep getting the 
> > question "give
> > me a concrete example of what CT would be used *for*?" We'd rather not
> > include this in the base CT draft, because then people would 
> > think that it
> > is required to implement that particular context when implementing the
> > transfer protocol. So, since transfer of header compression 
> > context is the
> > candidate easiest for people unfamiliar with CT to 
> > understand, we'd like to
> > recommend that the WG consider the following draft for WG 
> > draft status:
> > 
> >     
> > http://www.geocities.com/kempf42/draft-koodli-seamoby-hc-reloc
> > ate-02.txt
> > 
> > This is a draft that was originally submitted two years ago 
> > and expired. It
> > defines a way to transfer ROHC header context between access 
> > routers. The
> > original draft defined its own CT protocol. In this update, 
> > Manish Tiwari
> > has agreed to act as editor and has modified the protocol to 
> > use the Seamoby
> > CT protocol defined in draft-ietf-seamoby-ctp-02.txt.
> > 
> > The draft was submitted to the drafts editor yesterday, but 
> > after the 00
> > deadline. It isn't clear whether the drafts editor will 
> > consider it a 00
> > draft (since the original expired), in which case, the draft won't be
> > accepted until after IETF 57, or a continuation of the 
> > original, in which
> > case, the draft will show up in the drafts directory prior to 
> > IETF 57. In
> > any case, we'd like to encourage people to read the draft and 
> > comment on the
> > mailing list. Manish will discuss mailing list comments at 
> > IETF 57 and we'll
> > see whether the WG thinks the draft is a good candidate for 
> > WG draft status.
> > If we do decide to accept it, Pat and I (with Allison's help) 
> > will recruit
> > some reviewers from the ROHC list to make sure the header compression
> > details are correct.
> > 
> > Please give the draft a good read and comment to the list. Thanx.
> > 
> >             jak
> > 
> > 
> > _______________________________________________
> > 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: "James Kempf" <[email-masked]>
Date: Thu, 26 Jun 2003 08:55:57 -0700

Jukka

> more than RFC3374.

I took a very quick look at draft-ietf-dccp-user-guide-00.txt and I could
see some benefit in a similar document for CTP, though, since the intent is
to take CTP to experimental (unlike DCCP) I don't think such a document is
needed right now. Remember, the intent of the header compression CT draft is
to provide a concrete example of real value that would come out of CT, since
some people (and in particular some IESG members and some members of the
Seamoby CT review board) are skeptical. A User's Guide assumes that people
already see the value of the protocol, and is primarily about how to use it.

What do other people think?

>Still, the document should talk about more than one use
> case, though.
>

I'm not quite sure I understand. Are you proposing that specifications for
multiple different kinds of contexts should be included into one draft? If
yes, this sounds a bit impractical to me. If I am, say, interested in
implementing context transfer for header compression, why should I have to
wade through a document that describes context transfer for AAA, and IPsec,
and... Small, focussed specifications tend to do better in IETF, and they
are also easier to review and achieve concensus on approval. Although we
want the header compression CT document as a concrete example, it will also
serve as the (experimental) reference specification for implementing a
header compression context and will be used for that purpose.

            jak

---

From: [email-masked]
Date: Wed, 25 Jun 2003 09:44:17 +0300

Hi James

John

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 27 Jun 2003 08:34:42 +0300 (EEST)

Hi,

I have tried for the last years to figure out how
seamless/smooth/fast/[your favorite term here] handovers with QoS support
can in real life be accomplished. I personally have come to the conclusion
that although QoS and mobility management mechanisms seem to be somewhat
in order, a CT framework would be the "final blow" in the whole system.
More specifically, being able to do CT for IPSec and AAA is THE key, well,
to me at least.

Thus, I would like to see a WG guide on how you do IPSec and AAA CT, and 
how you couple that with the applications using the security mechanisms, 
for example, RSVP and a given mobility management mechanism.

To go to the point, finaly, I would like the see the mentioned Seamoby
"user guide" for CT, but it should also include the mentioned two
additional use cases. I know that Seamoby is trying to close the work, but
I think it might still be a good idea to try to write such an
informational document.

My 2 cents,
Jukka

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 26 Jun 2003 22:46:00 -0700

Hello Jukka,

I agree with you that QoS context transfer is a crucial piece.
In fact, in a way the QoS support was one of my main
motivating factors for working on this problem.  I'm happy
to say that we have achieved a certain degree of success
with our prototype.

However, it may be procedurally impossible to publish a document
towards that goal within seamoby.  I would definitely support
putting this work item on the charter, but it seems to me that the
goal of the authority structures surrounding seamoby is to shut
down the working group, for whatever reason (I do not understand).

Maybe the work should proceed in another working group exactly
like seamoby, but with more enthusiastic IESG support.  I'm not sure
how to engender that result, though.

Regards,
Charlie P.