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

From: [email-masked]
Date: Fri, 27 Jun 2003 10:34:18 +0300

Charlie & Jukka,

I see the need for this, too.  I think that there is interest in
finishing the existing Seamoby work, though.  One solution is
to have an individual draft working on QoS Context transfers,
with discussion on the Seamoby / NSIS mailing lists.  Not 
everything needs to be a WG draft, as long as there are people
interested in the subject.  However, this would be a good 
thing to discuss in Vienna & get buy-in from the WG chairs
and ADs.

John

> -----Original Message-----
> From: ext Charlie Perkins [mailto:[email-masked]]
> Sent: 27 June, 2003 08:46
> To: Jukka MJ Manner
> Cc: Seamoby Working Group
> Subject: Re: [Seamoby] Candidate for New WG Draft
> 
> 
> 
> 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.
> 
> 
> 
> 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
> >>
> >>
> >>    
> >>
> >
> >
> >_______________________________________________
> >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: Fri, 27 Jun 2003 11:31:17 -0700

John,

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.

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.

            jak