Re: Yet anoter charter version

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

imho this is in very good shape,

thanks, marcelo

El 14/02/2005, a las 12:40, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Ok, sorry for the delay. Thanks to Scott, John and Joe for providing
> spell checks.
>
> I have yet to get my head completely around what to write about the
> "hints". I have made an attempt to explain it with a few more words
> below, I am afraid it only got less clear :-(.
>
> Comments are welcome, and text even more so :-)
>
> Best regards,
>
> - - kurtis -
>
> - -----	
>
> Site-multiHoming by IPv6 interMediation (shim6)
>
> Description of Working Group:
>
> The shim6 WG is to produce specifications for a complete IPv6
> site-multihoming solution 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-l3shim-arch-00.txt
>   draft-ietf-multi6-functional-dec-00.txt
>   draft-ietf-multi6-l3shim-00.txt
>   draft-ietf-multi6-failure-detection-00.txt
>   draft-ietf-multi6-hba-00.txt
>   draft-ietf-multi6-app-refer-00.txt
>
> The shim6 WG is to publish, as standards track RFCs, specifications 
> with
> enough details to allow full interoperable implementations of the shim
> layer approach to multihoming as agreed on by the multi6 WG. These
> implementations will have the ability to take advantage of
> multihoming without adding to the growth of the global routing table
> by using aggregates already announced by upstream providers.
>
> Since the solution requires state to be maintained at both ends of a
> communication, the protocol specification document needs to contain a
> state machine description.
>
> Some state transitions may result from external events, however, such
> as failure detection rather than from protocol events. These should be
> documented in a separate document.
>
> Multihoming is today also often used to achieve various other
> features, such as traffic-engineering. The Shim6 WG should document
> the use of the shim6 solution in these cases in an applicability
> document.
>
> 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 Solutions 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.
>
>       o Solutions 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 solutions are also useful when both ends support the
> shim.
>
>       o Congestion control and explore how this and other QoS and
>         traffic engineering issues may interact with the use of
>         multiple locators at both ends.
>
>       o The relationships 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. However, the WG will consider developing methods
> for the shim6 level to handle transport layer events (or indicators)
> to the shim6 layer as in scope. These events will include any (if at
> all) interaction between the application layer and the shim6 layer as
> well as documenting what interaction is required between the transport
> and the application layer. How various transport layers such as
> SCTP and DCCP will handle a scenario with a shim6 layer under it is
> not in scope to start with, but should be addressed in a separate
> document later. Whether this is a topic for the shim6 WG or a transport
> area WG is left for a future IESG decision, once the shim6 solution
> has been more worked out.
>
> Milestones
>
> MAY 05    First draft of architectural document
> MAY 05 	  First draft of protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on multihoming triggers description
> MAY 05 	  First draft on applicability statement document
>
> SEP 05    WG last-call on architectural document
> SEP 05	  WG last-call on applicability statement document
>
> NOV 05 	  WG last-call on protocol document
> NOV 05    WG last-call on cryptographic locators, if required
> NOV 05    Submit completed architectural document to IESG
> NOV 05	  Submit applicability statement document to IESG
>
> JAN 06    WG last-call on multihoming triggers description
> JAN 06    Submit document on cryptographic locators to the IESG, if
>      	 	 required
> JAN 06	  Submit protocol document to the IESG
>
> MAR 06    Submit draft on multihoming triggers description to the IESG
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQhCOLaarNKXTPFCVEQJkNwCgnNuouBRxQdFDz09RbZ3nTio7MOMAoOYz
> s/xs1E5/Wpi35IH2+LI+wfSZ
> =NewB
> -----END PGP SIGNATURE-----
>
>