Re: CTP and CARD Drafts

> Excuse me for being new to this list, and therefore short of details!
>
> I'm interested to see that final submissions seem to have been made by
> seamoby, and I can see no evidence of plans for further work in this WG -
is
> this in fact the case?
>

The WG will be shutting down after the CARD and CTP drafts are published.

> r.e. CTP draft; whilst this clearly seems to provide a simple (always
> good!), and security considered solution to signalling for CT, I cannot
see
> where frameworks etc for Context Data Blocks or for plans (or examples?)
for
> FPT type definitions. Are these outlined elsewhere, or is this 'future
> work'? Also, for DoCoMo's implementation, have they released any details
of
> context type, description etc, or is it all 'in house'?!
>

There is a simple example of a context defined in Appendix B of the CTP
draft, for multicast listener state. The header compression context Docomo
is planning on implementing is described in
draft-koodli-seamoby-hc-relocate-03.txt. I believe Nokia IPRG has also done
some work in this area. Rajeev, who is co-author on the HC transfer draft,
was scheduled to speak about it at the MOBOPTS meeting in Seoul but we ran
out of time.

Over the lifetime of Seamoby, there have been many proposals to standardize
particular context types (PPP, AAA, IPsec, QoS, etc.) but Seamoby was never
chartered to specify particular context types, just the transfer protocol.
At the WG meeting at IETF 57 in Vienna, we discussed possibly specifying the
header compression context, which would have required a charter amendment,
but there was sufficient dispute between ROHC experts whether header
compression context transfer was necessary that we decided not to pursue it
in the Seamoby group. However,  we have encouraged Rajeev to work together
with the ROHC group to answer the technical questions that arose and pursue
a specification.

The CTP draft specifies a procedure whereby a context profile can be
approved. A Designated Expert is assigned by the AD in the topic area to
evaluate the design, and a context profile type number is requested from
IANA.

> r.e. CARD; this seems clearly aimed at discovery in single interface
> homogeneous IP networks - any thoughts on possible overlap with discovery
in
> heterogeneous, multi-interface networks, or do you feel the problems, and
> hence solutions, are seperate/out of scope?
>

Actually, it is designed for multi-interface hosts. CARD allows the AR to
advertise information about other wireless protocols available in the
surrounding geographic area. See Section 5.1.3.1 for a description of the L2
ID suboption format. The L2 ID suboption is designed to carry information
about possible heterogenous network availablilty.

            jak