Subject: [Seamoby] Candidate for New WG Draft

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Jun 2003 11:18:15 -0700

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

---

From: [email-masked]
Date: Fri, 27 Jun 2003 21:56:07 +0300

Hi James,

> If this has some relation to NSIS, would you see a problem with having an
> (experimental) QoS context transfer draft in NSIS? Provided the WG agrees,
> of course. This would be an alternative to a strictly individual draft,
> which is also OK but might be less interesting to the NSIS folks.

This is a possibility.

> The original idea was that Seamboy would not get into defining feature
> contexts, and that they would be done by the relevant WGs, but, for tactical
> reasons, we need at least one.

I agree with this strategy. We should check with our AD on this as well.

John

---

From: [email-masked]
Date: Fri, 27 Jun 2003 21:58:55 +0300

Hi,

Perhaps we could ping Dan Forsberg to resubmit it.  

John

> -----Original Message-----
> From: ext Rajeev Koodli [mailto:[email-masked]]
> Sent: 27 June, 2003 20:52
> To: Jukka MJ Manner
> Cc: James Kempf; Seamoby Working Group
> Subject: Re: [Seamoby] Candidate for New WG Draft
> 
> 
> 
> Hello Jukka,
> 
> there was a draft on AAA state relocation.
> 
> draft-forsberg-seamoby-aaa-relocate-00.txt
> 
> Let me know if you are interested but cannot find it.
> 
> Regards,
> 
> -Rajeev
> 
> 
> Jukka MJ Manner wrote:
> 
> > 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
> >
> > On Thu, 26 Jun 2003, James Kempf wrote:
> >
> > > Jukka
> > >
> > > > 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.
> > >
> > > 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
> > >
> > >
> >