Re: New version of charter text

[Erik Nordmark <erik.nordmark@sun.com>]

Kurt Erik Lindqvist wrote:

> > I'm not sure we should commit to an API. We might well want to
> > specify it conceptually, i.e. a bit more than hints, but
> > not really get into the API deinition game, which the IETF
> > usually leaves to others.
>
>
> I used the word signalling in the new version. Not sure if that is 
> "conceptual" enough?

I suspect a single overloaded word such as "signaling" isn't sufficient 
to explain this; you need a sentence.


> > > TE, and perhaps ingress filtering I envisioned in the applicability 
> > > document. The new communication establishment I envisioned to be 
> > > addressed in the multihoming event trigger document (but come to 
> > > think about it, this perhaps should be somewhere else).
> >
> > It might be separate. But we could decide that later.
>
>
> So we leave it as it is? Or should we explicitly describe the 
> applicability document?

I feel the charter gets into too much detail of which documents will be 
delivered. We should focus it on which pieces remain to be worked on 
(i.e., things that multi6 didn't do or finish), and which pieces need to 
be delivered, and not worry too much whether the deliverable in fall '05 
or spring '06 consists of N or M internet drafts.

Kurt Erik Lindqvist wrote:


>>I think that area is interesting, but could be a rat hole. Those
>>issues are more about interface selection and performance
>>characteristics of the path, then about multihoming. That is, such
>>approaches would be useful (or not) even in the absence of shim6
>>below. There might be some added motivation for addressing this in the
>>multihoming context, if multihoming causes more dynamic variation in
>>the paths that are being used over time than what we see in today's.
>>However, in the case of site multihoming, I think the variation will
>>not be much different than IPv4 single prefix multihoming today when
>>routing selects different paths; it is the host multihoming case which
>>potentially makes this a more pressing issue - see the GRPS vs. WLAN
>>examples above.
>>
>>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 in
> either the architecture or the protocol document?

I'm not sure, for two reasons:
 - I don't know if 'events' imply information delivered from the shim 
to the application, or from the application to the shim (or both)
 - I'm not sure we understand how applications might have different 
needs and desires than transport protocols.

We *do* know that the shim's failure detection can make use of transport 
protocol hints (such as "things are ok" or even "I might be having 
problems"), but I don't know what else we know is needed on this front.
Note that such transport level hints should be usable when the 
retransmission layer is implemented above UDP, which means "application 
or middleware layer" from an implementation perspective.

   Erik