[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New version of charter text



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