Subject: Agenda
From: Kurt Erik Lindqvist <[email-masked]>
To: [email-masked]
Date: Mon, 28 Feb 2005 06:16:27 +0100

All,

below is the agenda for the shim6 BOF in Minneapolis.

1. Administrivia, Chairs (5 mins)
	- Agenda
	- Scribes

1. Introduction, Chairs (5 mins)

2. shim6 solutions architecture overview, Geoff Huston 
draft-huston-l3shim-arch-00.txt (15 mins)

3. review proposed charter, Chairs (25 mins)

3.1 General goals and scope
3.2 Specific deliverables and milestones

4. AOB, chairs (10 mins)
	- Next steps

Kurtis + Brian

Delivery-date: Fri, 25 Feb 2005 11:16:33 +0000
To: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Scribe and Jabber scribe
Date: Fri, 25 Feb 2005 12:15:45 +0100

The BOF chairs are looking for two volunteers

o a meeting minutes scribe
o a Jabber scribe

If you would like to volunteer please contact me [email-masked] or 
Brian Carpenter [email-masked]

- - kurtis -

Delivery-date: Wed, 23 Feb 2005 08:42:50 +0000
Date: Wed, 23 Feb 2005 09:42:06 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Multi6 <[email-masked]>, [email-masked]
Subject: FYI: Meeting times in Minneapolis

The multi6 WG will meet for one hour, currently scheduled
for 15:30 on Tuesday March 8.

The shim6 BOF will meet for 2.5 hours, currently scheduled
for 09:00 on Friday March 11.

     Brian

Delivery-date: Sun, 20 Feb 2005 00:44:41 +0000
To: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Charter v4
Date: Fri, 18 Feb 2005 11:27:01 +0100

	

Ok, last update with changes proposed by John.

I only have two positives by Marcelo and John. I assume that means that 
everyone things that we are ready for the BOF in MPLS? Here silence 
will assumed to be consent :-)

- - kurtis -

Site-multiHoming by IPv6 interMediation (shim6)

Description of Working Group:

The shim6 WG is to produce specifications for an 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 fully 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

Delivery-date: Tue, 15 Feb 2005 17:51:07 +0000
Cc: <[email-masked]>
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Re: Yet anoter charter version
Date: Tue, 15 Feb 2005 18:52:42 +0100
To: <[email-masked]>

	John,

On 2005-02-15, at 11.53, <[email-masked]> wrote:
> Looks good, some small comments:
>
>> The shim6 WG is to produce specifications for a complete IPv6
>
> -> Could we drop 'complete' - there are some things, like multihoming
> policy that is out of scope, but probably is needed to actually
> get the thing running.

Makes sense to me.

>> The shim6 WG is to publish, as standards track RFCs, specifications 
>> with
>> enough details to allow full interoperable implementations of the shim
>                        -> fully

Thanks!

>> 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.
>
> Otherwise, I think this looks good.

Ok, thanks!

- - kurtis -

Delivery-date: Tue, 15 Feb 2005 10:57:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Yet anoter charter version
Date: Tue, 15 Feb 2005 12:53:41 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Kurt,

Looks good, some small comments:

> The shim6 WG is to produce specifications for a complete IPv6

-> Could we drop 'complete' - there are some things, like multihoming
policy that is out of scope, but probably is needed to actually
get the thing running.

> 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).
>=20
> The shim6 WG is to complete this work with the required protocol =
developments
> and complete the architecture and security analysis of the required=20
> protocols.
>=20
> The background documents to be considered by the WG include:
>=20
>   RFC 3582
>   draft-ietf-multi6-things-to-think-about-01.txt
>   draft-ietf-multi6-multihoming-threats-03.txt
>=20
> The input documents that the WG will use as the basis for its design=20
> are:
>=20
>   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
>=20
> The shim6 WG is to publish, as standards track RFCs, specifications =
with
> enough details to allow full interoperable implementations of the shim
                       -> fully

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

Otherwise, I think this looks good.

John

Delivery-date: Mon, 14 Feb 2005 15:45:02 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Yet anoter charter version
Date: Mon, 14 Feb 2005 16:44:51 +0100
To: Kurt Erik Lindqvist <[email-masked]>

imho this is in very good shape,

thanks, marcelo

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

> -----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 -
>
> - -----=09
>
> 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=20
> 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=20=

> 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=20=

> 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
> =3DNewB
> -----END PGP SIGNATURE-----
>
>

Delivery-date: Mon, 14 Feb 2005 11:38:51 +0000
To: [email-masked]
From: Kurt Erik Lindqvist <[email-masked]>
Subject: Yet anoter charter version
Date: Mon, 14 Feb 2005 12:40:20 +0100

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

Delivery-date: Wed, 09 Feb 2005 16:03:59 +0000
Cc: ext Kurt Erik Lindqvist <[email-masked]>, [email-masked], Erik Nordmark <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: New version of charter text
Date: Wed, 9 Feb 2005 17:03:44 +0100
To: Pasi Sarolahti <[email-masked]>

Hi Pasi,

El 09/02/2005, a las 12:24, Pasi Sarolahti escribi=F3:

> [I'm catching up a bit late... The discussion was about APIs]
>
> On Thu, 2005-01-27 at 11:17, ext Kurt Erik Lindqvist wrote:
>
>> On 2005-01-26, at 21.04, Erik Nordmark wrote:
>>> I read Marcelo's comment as a more application layer thing, i.e. a
>>> question whether we should work on an abstract API (not a binding to=20=

>>> a
>>> particular programming language) which applications can use to
>>>  - observe what is going on below (which locator pair is used now?
>>> what interface - GPRS or 802.11 - is being used?),
>>>  - express preferences (don't even try over GPRS type things) or =
some
>>> other way to control things
> [...]
>>> I don't see a need to add anything about this to the charter though.
>>
>> Ok, I think I misunderstood Marcelo then. However, I would assume =
that
>> at least some text on application layer 'events'  should be included=20=

>> in
>> either the architecture or the protocol document?
>
> There might be a bit more to this than just application layer events.
> I'd think that many systems might still want to use the conventional
> socket API for shim6 communication. Would the semantics of the
> traditional socket API functions be affected?
>
> Take bind(), for example? Would it still be possible to bind to a
> selected locator/IP address (and what would that mean), or would bind
> work on an ULID level, as one would expect if there was a new address
> family?
>

this is good point, but, imho , It is not very likely that we end up=20
with ULID that are not locators. So i think that the bind will apply to=20=

any address available, which can be used both as a locator and as=20
identifier.

I mean, as i understand it, ULID that are also locators provide a=20
better support for refferals.
The remaining case where we end up with only locators, is the case=20
where we use N-square addresses approach to perform demux of data=20
packets, but my understanding is that this approach does not have much=20=

support (and in any case, i am not sure it would make much sense to=20
allow a bind to one of the locators only addresses used in the n-square=20=

approach (this comment is not general about locators but just for the=20
case of the locators resulting from the n-square approach))

> Even though APIs are not generally in the IETF scope, it might be =
worth
> it to discuss possible interactions with the traditionally used APIs,
> and what applications can expect from the behavior of the underlying
> shim6.

agree, but i guess that the charter leaves some space for this=20
discussion

regards, marcelo

> Don't know if this would be a charter issue, though, or could it
> be included in the other planned documents, if considered useful.
>

> - Pasi
>

Delivery-date: Wed, 09 Feb 2005 11:46:44 +0000
Subject: Re: New version of charter text
From: Pasi Sarolahti <[email-masked]>
To: ext Kurt Erik Lindqvist <[email-masked]>
Cc: Erik Nordmark <[email-masked]>, [email-masked], marcelo bagnulo braun <[email-masked]>
Organization: Nokia Research Center
Date: Wed, 09 Feb 2005 13:24:53 +0200

--=-nE46zcTcck6A4xHGr2DR
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

[I'm catching up a bit late... The discussion was about APIs]

On Thu, 2005-01-27 at 11:17, ext Kurt Erik Lindqvist wrote:

> On 2005-01-26, at 21.04, Erik Nordmark wrote:
> > I read Marcelo's comment as a more application layer thing, i.e. a=20
> > question whether we should work on an abstract API (not a binding to a=20
> > particular programming language) which applications can use to
> >  - observe what is going on below (which locator pair is used now?=20
> > what interface - GPRS or 802.11 - is being used?),
> >  - express preferences (don't even try over GPRS type things) or some=20
> > other way to control things
[...]
> > I don't see a need to add anything about this to the charter though.
>=20
> Ok, I think I misunderstood Marcelo then. However, I would assume that=20
> at least some text on application layer 'events'  should be included in=20
> either the architecture or the protocol document?

There might be a bit more to this than just application layer events.
I'd think that many systems might still want to use the conventional
socket API for shim6 communication. Would the semantics of the
traditional socket API functions be affected?

Take bind(), for example? Would it still be possible to bind to a
selected locator/IP address (and what would that mean), or would bind
work on an ULID level, as one would expect if there was a new address
family?

Even though APIs are not generally in the IETF scope, it might be worth
it to discuss possible interactions with the traditionally used APIs,
and what applications can expect from the behavior of the underlying
shim6. Don't know if this would be a charter issue, though, or could it
be included in the other planned documents, if considered useful.

- Pasi

--=-nE46zcTcck6A4xHGr2DR
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-nE46zcTcck6A4xHGr2DR--