comments about the draft charter

[marcelo bagnulo braun <[e-mail]>]

Hi all,

imho the draft looks good,
just some comments below...
>
> Site multiHoming by IPv6 interMediation (shim6)
>
> Description of Working Group:
>
> The shim6 WG is to produce specfifications for a complete IPv6 site
> multihoming solutions based on the architecture developed by the IETF
> multi6 WG. The multi6 WG was tasked with investigating solutions to
> the site multihoming problem that will allow the global routing system 
> to
> scale. The outcome of the multi6 WG is a specific network layer shim
> architecture for addressing and address handling of sites and nodes. 
> This
> includes switching to different locator addresses when connectivity 
> changes,
> but without the changes of address being visible to upper layers, 
> which see
> a fixed Upper Layer Identifier address (ULID).
>
> The shim6 WG is to complete this work with the required protocol 
> developments
> and complete the architecture and security analysis of the required 
> protocols.
>
> The background documents to be considered by the WG include:
>
>  RFC 3582
>  draft-ietf-multi6-things-to-think-about-01.txt
>  draft-ietf-multi6-multihoming-threats-03.txt
>
> The input documents that the WG will use as the basis for its design 
> are:
>
>  draft-huston-solution-stilltobewritten
>  draft-ietf-multi6-functional-dec-00.txt
>  draft-ietf-multi6-l3shim-00.txt [to be published shortly]
>  draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
>  draft-ietf-multi6-hba-00.txt
>  draft-ietf-multi6-app-refer-00.txt
>
> [Comment - We specifically omitted the IPv4 document and Geoff's
> architecture analysis - we're assuming that will be replaced for
> the new WG by his solution architecture.]
>
> The shim6 WG is to submit, as standards track RFCs, specifications with
> enough details to allow full interoperable implementations of the shim
> layer appproach to multihoming as agreed on by the multi6 WG. These
> implementations should have the ability to take advantage of
> multihoming without adding to the growth of the global routing table,
> by using the aggregates already announced by their upstream providers.
>
> Since the solution requires state to be maintained at both ends of a
> communication, the protocol specification and the state machine will 
> be designed
> somewhat independently. Some state transitions may result from external
> events such as failure detection rather than from protocol events. 
> More work
> items and milestones might need to be added at a later date to
> complete all implementation details needed.
>
> In addition to the basic network layer shim solution, the shim6 WG
> is specifically chartered to do work on
>
>      o A solution for site exit router selection that works when each 
> ISP
>        uses ingress filtering, i.e. when the chosen site exit needs to 
> be
>        related to the source address chosen by the host. This solution
>        should work whether or not the peer site supports the shim6 
> protocol.
>

i would add an additional item here:

- A solution to establish new communications after an outage has 
occurred that does not requires shim support from the non-multihomed 
end of the communication. The wg will explore if such solution is also 
useful when both ends support the shim.

imho this is relevant becuase it would provide an incremental 
deployment model to the solution. If this is not provided, it is all or 
nothing approach w.r.t. to fault tolerance i.e. if the other end 
support the shim, then you get all the benefits but if the other end 
does not supports the shim then no additional fault tolerance is 
achieved.

>      o Explore how congestion control and other QoS and traffic 
> engineering
>        issues may interact with the use of multiple locators at both 
> ends.
>
>      o Investigate relationship between Upper Layer Identifiers (ULIDs)
>        and Unique Local Addresses.
>
>      o ICMP error demuxing for locator failure discovery.
>
>      o If necessary, develop and specify formats and structure for
>
>        - Cryptographically protected locators
>
>        - Carrying the flow label across the shim layer
>          defined in the multi6 architecture.
>
> The WG will consider whether the proposed model is exposed to
> any security threats in addition to those documented in
> draft-ietf-multi6-multihoming-threats-03.txt. In any case,
> the specifications must specifically refer to all applicable threats
> and describe how they are handled,  with the requirement being that
> the resulting solution not introduce any threats that make the
> security any less than in today's Internet.
>
> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative
> identifier formats.
> [What other topics are explicitly out of scope?]
>

enhanced security?
i mean, it is a non goal to provide better security than current 
single-homed ipv6 internet

regards, marcelo


> Milestones
>
>
> MAY 05    First draft of architectural and protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on state managment
>
> SEP 05    WG last-call on architectural/protocol document
>
> NOV 05    Submit complete architectural/protocol document to IESG
> NOV 05    WG last-call on cryptographic locators, if required
>
> JAN 06    WG last-call on state management
> JAN 06    Submit draft on cryptographic locators to the IESG, if 
> required
>
> MAR 06    Submit draft on state management to the IESG