Subject: [NSIS] NSLP versioning

From: Martin Stiemerling <[email-masked]>
Date: Thu, 1 Jun 2006 10:03:57 +0200

Dear all,

There is still a not completely solved issue back from the old days  
(2004) about NSLP versioning. It is about wether an NSLP can have  
multiple versions or not.
The old emails have been mainly exchanged privately amongst the NSLP  
and NTLP authors.

Take a look and give some comments! (there are two emails included in  
this email)
The topic has shown up as well in these recent emails from Robert and  
Roland:

http://www1.ietf.org/mail-archive/web/nsis/current/msg05130.html
http://www1.ietf.org/mail-archive/web/nsis/current/msg05140.html

The baseline in the old days has been that a new NSLP version would  
require a new NSLP, thus a new NSLP ID.

   Martin

Henning Schulzrinne wrote:

> Martin Stiemerling wrote:
>
>>> The NTLP doesn't care what format the NSLPs use for their messages
>>> (so they can easily do totally different things to one another).
>>> The NTLP also has some significant differences from the NSLPs with
>>> regard to message content requirements. Even so, it still seems
>>> useful to make some attempt at co-ordinating the design, even if it
>>> is only to make implementors' lives easier.
>>>
>>
>> Very good idea, indeed we need some coordination between all NSIS
>> components .
>>
>
> Having a common way of representing all NSLPs also makes it possible
> to have a debugger or protocol analyzer that can show the outline of
> the packet even if it does not understand the semantics of each NSLP.
>
> Thus, I'd argue that there'd have to be a really strong reason *not*
> to
> do this...
>

Good. :-)

>> I would prefer to have a version number, since allocating a new NSLP
>> number for a new NSLP version might not be appropriate.  Allocating a
>> new NSLP number will include some sort of IANA action, a new version
>> number probably not.
>>
>
> Versioning is a tricky topic. This is not just about allocating
> version numbers in the protocol field. Indeed, there seem to be few
> successful instances of multiple versions of the same protocol. (HTTP
> is an example
> of a not-very-successful transition, even though it mostly works in
> practice.
>
> I would argue that there are only two interesting cases:
>
> (1) It's effectively a new protocol, even if it re-uses some parts of
> the old one, if an existing implementation can't make use of the
> information (not backwards-compatible). In that case, little is gained
> by having a version field unless you have a really small NSLP field
> (which we should avoid).
>
> (2) The new 'protocol' just adds a few options, but an old
> implementation can understand this (backwards compatible). In that
> case, the version doesn't help at all and you might as well just
> include the fields as optional.
>

This was more-or-less the conclusion I came to in thinking about the  
QoS NSLP. If there is a mechanism to extend the current version with  
new objects in a backwards compatible way, then you don't need or  
want to change version numbers for that. Changes that are big enough  
to cause an increase in version number are likely to be rare enough  
and significant enough that allocating a new NSLP identifier is  
reasonable.

>>  - NSLP protocol version number.
>>
>
> Not a good idea; see above.
>
>
>>
>>  - number of TLVs in NSLP message
>>
>
> Not a good idea; just means that there is one more field to keep
> consistent.
>

Yes, I agree. It doesn't seem to add anything particularly helpful,  
just more error cases to check.

>>  - NSLP message type (NATFW NSLP uses this field to distinguish the
>>    action to be taken, e.g., create pinholes in firewall
>>
>
> Yes.
>

Agreed.

The current QoS NSLP common header has message type and flags (with  
the flags currently depending on the message type). Does this sound  
useful to other people?

>>> We've also got the concept of 'objects', which tend to be specified
>>> as some sort of TLV (or AVP). Currently GIMPS defines its objects
>>> as a type and length. The QoS NSLP has a length and type which is
>>> split into 'class' and 'type', in a similar way to RSVP. This is
>>> useful where you have a number of objects which are alternatives
>>> for one another (e.g. IPv4 src/dst vs IPv4 src/dst/proto/ports vs
>>> IPv6 src/dst/flow-label). Otherwise it seems rather a waste of the
>>> type-space. The QoS NSLP makes use of the class/type split in two
>>> cases at the moment: 'Scoping' and 'QSpec' (where the 'type' with
>>> the QSpec class is the QoS model id). The 'alternatives' construct
>>> can also be defined using a BNF definition of the messages.
>>> Questions:
>>> c) which comes first, 'type' or 'length'?
>>> d) does 'length' include the length of the 'length' or 'type+length'
>>> fields? e) should 'type' be split into class/type or just be a flat
>>> number space?
>>>
>>
>> For c): First 'type, second 'length'.
>> For d): To make implementer's live easier: 'length' is total length
>> of the object (TLV header plus data)
>>
>
> Agreed.
>

OK for (c).

For (d), would have argued it the other way. However, from a brief  
survey including the header length does seem more common for Internet  
protocols (TCP, SCTP, RSVP, DIAMETER), whilst ASN.1 BER and XDR don't  
include the TLV header length.

By including the length of the header, you have additional special  
error cases to deal with (e.g. if the object header is 4 bytes long,  
lengths of 0, 1, 2, or 3 are special cases which can never be valid).  
In other ways, I'm not sure it makes much difference to implementors  
with respect to parsing the data. Not including the header length  
probably gives you a bit more freedom on how you manage your buffer/ 
pointers.

>> The exact allocation of type, i.e., whether to split into class and
>> type could be left to the particular NSLP.  For instance, NATFW NSLP
>> won't split into class and type.
>>
>
> There are really two parts here, namely (written a bit differently
> than
> the RSVP case)
>
> - meaning ("this is the flow label describing the packets") = class
>
> - format ("this is an IPv4 version")
>
> Protocols like SMTP separate the two meanings, and I think this is a
> good idea. However, the format labeling can be done inside the object,
> as a common part of the object.
>
> Again, this primarily simplifies parsing and protocol analyzers. You
> can just pass the object to a routine, which will know whether it can
> handle the protocol version.
>

We've used this sort of thing in the current QoS NSLP draft in two  
places: the SCOPING object and the QSPEC (where the sub-type is used  
to indicate the QoS model). Interestingly, Rob suggested a different  
approach for the Flow-Routing Information in the GIMPS-01 draft.

It doesn't seem to be something that is needed particularly often,  
and, certainly, you can always do it by including the sub-type/format  
discriminator inside the object itself.

>>> The other thing we've talked about in the QoS NSLP work is whether
>>> there ought to be some flags to indicate how to process objects
>>> with a type number that an implementation might not know about
>>> (RSVP and DIAMETER have functionality of this sort). This is used
>>> to aid extensibility, and indicates the required behaviour when a
>>> node encounters an object it does not know about - should it
>>> forward it as is? remove it from the message? abort and send back
>>> an error? Question:
>>> f) Should we define some standard unknown-object processing
>>> indicators (drop/forward/error)?
>>>
>>
>> That's a good issue to further discussion.  Can we be put this on
>> hold, since (at least) I didn't have thought about this right now.
>>
>
> Yes, a mandatory bit may be needed *instead* of the useless version
> identifier.
>

Yes, that was my thought. Some existing protocols that do this sort  
of thing are RSVP (two high bits of class-num indicate reject  
message, ignore+drop object, or ignore+forward object), DIAMETER  
('Mandatory' bit), X.509 (critical/non-critical extensions), SCTP  
(flags indicating behaviour for unknown chunk types), etc.

> Another alternative is to use the option labeling mechanism used in
> SIP which identifies capabilities instead of protocol elements.
> Semantics
> are "if you don't understand the label, don't process the message; if
> you understand the label, you by definition understand the necessary
> message components". This works pretty well and can yield somewhat
> better diagnostics in case of failures.
>
> Imagine that you have capability
> foo: requires A, B
> bar: requires B, C
> zong: requires A, C
>
> If the node understands foo and zong, but not bar, it will indicate
> "sorry, can't do C", but it's harder to figure this out. If you
> understand bar and zong, but not foo, you can't return anything.
>
> This is a bit contrived, but I think labeling semantics instead of
> syntax elements is a better idea in general.
>

That's an interesting idea, which I'll need to think about a bit  
further.

>>> For efficient processing it may be useful to pad all objects to 32
>>> bits in length. Questions:
>>> g) Does such a padding rule seem sensible?
>>>
>>
>> Yes, it is a good idea.
>>
>>
>>> h) How do we define the padding (and determine that it is there when
>>> processing)?
>>>
>>
>> The simplest way would be to define all options (if possible) to 32
>> bits. I have to check out for the NATFW NSLP if all objects can be
>> defined to 32 bits, or if there are some that are dynamic w.r.t.
>> size.
>>
>
> This usually works, but there may be strings, for example, that are
> not naturally multiples of 32 bits. As long as you label all
> variable-length entities, the 'left-over' is padding.
>

So, the object header gives the length including padding, and then  
you contain an extra length field inside the object itself to give  
the actual length of the data without padding?

The other alternative is that object lengths give the length without  
padding, but define that all objects must be 32-bit aligned. The  
total object length is then the given length rounded up to a 4-byte  
multiple. This is probably more efficient, but gives greater  
possibility for implementation error.

>>> Something else we might want to think about is whether there is a
>>> set of common error codes we want to agree on (e.g. 'unknown
>>> message type').
>>>
>>
>> Could be helpful for debugging.
>>
>
> Again, borrowing ideas from elsewhere, it is useful to have message
> classes, as in ftp, stmp, SIP, etc., indicating the severity of the
> failure and whether this is a progress report, a temporary failure
> ("no resources available") or a permanent failure ("your protocol
> message is invalid"). That way, you can add failure indications and
> older implementations will still do roughly the right thing (like not
> retry
> the broken message).
>

Yes, that sounds sensible.

regards,

Andrew

Anfang der weitergeleiteten E-Mail:

> Von: "Hancock, Robert" <[email-masked]>
> Datum: 18. Oktober 2004 14:41:24 MESZ
> An: <[email-masked]>, "Henning Schulzrinne"  
> <[email-masked]>, "McDonald, Andrew"  
> <[email-masked]>, "Cedric Aoun"  
> <[email-masked]>, <[email-masked]>, "Hannes  
> Tschofenig" <[email-masked]>, "Georgios Karagiannis"  
> <[email-masked]>, "Miquel Martin"  
> <[email-masked]>, "Martin Stiemerling"  
> <[email-masked]>
> Betreff: NSLP versioning
>
> dear all,
>
> back in may (!) when we discussed common message structure
> and so on, we decided not to have an NSLP version field since
> - either the new version was fully backwards compatible
>   with the old (==> no need for a new version number
>   anyway, just add optional fields)
> - or there is not backwards compatibility and so you
>   might as well have a new NSLP number provided the id
>   space is large enough (which it is, at the moment).
>
> this is what the GIMPS draft currently assumes about
> the common NSLP header.
>
> the question arises of what to do when you have a node
> which supports multiple versions (1 and 2) of the 'same'
> NSLP, and has no idea which version(s) the peer supports:
>
> Q-node                 R-node
> {1,2}   ----------->     {?}
>
> What NSLP should the Q-node put in its initial GIMPS query
> message?
> - if it sets NSLP=1 and R node supports {1,2}, how
> do they get to use version 2 (which is presumably what
> they would prefer)
> - if it sets NSLP=2 and R node only supports NSLP=1,
> then it will forward the message transparently to the
> next node downstream, since NSLP=2 is 'new' and unrelated
> to NSLP=1.
>
> What one might imagine would be that the Q node really
> wants to format the GIMPS query with the semantics "I am
> interested in QoS and I support all versions up to N",
> to which the response could be "I support version M",
> (with the implication that any NSLP data in the message
> only got interpreted if M=N). The message is intercepted
> by the R node based on the 'type' of NSLP, not version.
>
> How are the NSLP designers planning to do version
> negotiation? Or is there some style of protocol design
> which eliminates the problem?
>
> [My current proposal would be to put an open issue in the
> next version of the GIMPS draft that discusses this question.
> It basically affects the common header format in section
> C.2.]
>
> robert h
>
> -- 
>
> Visit our website at www.roke.co.uk
>
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
>
> The information contained in this e-mail and any attachments is  
> confidential to
> Roke Manor Research Ltd and must not be passed to any third party  
> without
> permission. This communication is for information only and shall  
> not create or
> change any contractual relationship.
>
> )
> A98AB OK Completed

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Fri, 02 Jun 2006 15:24:36 +0200

> multiple versions or not.

I would say yes, naturally it can. The question is probably
what can be considered as an appropriate demultiplexer.
So what is the issue exactly? Whether there should be an NSLP version
field in the NSLP protocol itself? The current alternative is to
use a different NSLP ID for each version, thus using the NSLP ID
in GIST as demultiplexing value. Since the NSLP ID is 16bit I guess
that there are no issues here. So as long as we assume GIST as
underlying transport (or some other protocol at least carrying session
ID, MRM, NSLPID and so on) there is no problem here. There is
only trouble if all you have is the NSLP data packet alone.

Regards,
 Roland

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 8 Jun 2006 09:36:38 +0200

> only trouble if all you have is the NSLP data packet alone.

The issue here is whether an NSIS initiator should have the ability to
ask with a single request message for multiple, different NSLP version.
This would require a single general NSLP-ID per NSLP and a version
information with the NSLP itself.

I do not know if this issue is solvable by now or if it should be  
handled in
the NSLP extensibility draft. Since we have only a single version anyway
of each NSLP.

   Martin

---

From: <[email-masked]>
Date: Fri, 9 Jun 2006 16:22:28 +0300

>> I would say yes, naturally it can. The question is probably what can 
>> be considered as an appropriate demultiplexer.
>> field in the NSLP protocol itself? The current alternative 
>is to use a 
>> different NSLP ID for each version, thus using the NSLP ID 
>in GIST as 
>> demultiplexing value. Since the NSLP ID is 16bit I guess that there 
>> are no issues here. So as long as we assume GIST as underlying 
>> transport (or some other protocol at least carrying session ID, MRM, 
>> NSLPID and so on) there is no problem here. There is only trouble if 
>> all you have is the NSLP data packet alone.
>
>The issue here is whether an NSIS initiator should have the 
>ability to ask with a single request message for multiple, 
>different NSLP version.
>This would require a single general NSLP-ID per NSLP and a 
>version information with the NSLP itself.
>
>I do not know if this issue is solvable by now or if it should 
>be handled in the NSLP extensibility draft. Since we have only 
>a single version anyway of each NSLP.

Is there anyone requesting this feature, it sounds extremely messy to
actually get working.

John

---

From: "Robert Hancock" <[email-masked]>
Date: Mon, 12 Jun 2006 00:53:18 +0100

hi all,

the problem here is that if the NSLP version is encoded
in the NSLPID, version negotation becomes quite hard and 
incremental deployment of a new version very hard. example:

*) node A supports versions 1 and 2;
*) it issues a query for version 1;
*) it gets a response from node B which supports version 1 and
2, but: the only version they will ever use is version 1 unless
A re-Queries for version 2 (the routing state is tied to the
NSLP version).

second attempt:
*) node A supports versions 1 and 2;
*) it issues a query for version 2;
*) the Query is seen by node B' which only supports version 1,
so it has to bypass the Query to the next node down the path.

i think there is a relatively simple class of solutions to
this problem, where a single NSLPID defines a family of versions,
and NSLP messages include a version number. you signal your 
highest supported version by replying to messages about an
unsupported version with an error. you can even put NSLP data
in the query to conduct version negotiation as part of route 
setup.

(of course, there are loads of other solutions on the same 
general pattern. the principle point is not to use different
NSLP IDs for different versions.)

r.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 09 June 2006 14:22
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] NSLP versioning
> 
> 
>

---

From: Roland Bless <[email-masked]>
Date: Mon, 12 Jun 2006 11:56:13 +0200

Hi John, Martin, Robert, and, all

> Is there anyone requesting this feature, it sounds extremely messy to

I'm actually opposed to supporting such a version negotiation
feature. There are quite a lot of options and cases one could
imagine. I guess it's a good example of applying the
e2e argument again: the application itself should decide
which version is suitable instead of building a version negotiation
feature into GIST. Thus, it would be free to probe
versions in any order it likes given the current NSLP-IP -> version
one-to-one mapping. Furthermore, we have the limited exensibility
for yet unknown objects within each version. I guess that's flexible
enough.

Regards,
 Roland

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 13 Jun 2006 14:25:06 +0300

dear all,

many of you will be aware of a draft on an approach to path-decoupled
signalling (see the last version at:
http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem-03.txt).

there was a presentation on this at the last IETF in Dallas (see
http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt followed
by a productive discussion at the microphone (summary at
http://tools.ietf.org/wg/nsis/minutes?item=minutes65.html).

as we approach submission cutoff deadlines, we'd like to solicit
comments and discussion additional to that expressed at the 
meeting. in particular, we'd like to understand if the WG thinks 
that the document is in a suitable state to be adopted as a working
group draft.

cheers,

robert h. et al.

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 13 Jun 2006 09:05:42 -0500

> that the document is in a suitable state to be adopted as a working

This had good support at IETF-65 to become a WG document, and I continue
to support that.  BTW, a link to the slides is at
http://www3.ietf.org/proceedings/06mar/slides/nsis-1/sld1.htm (link
above doesn't seem to work).

Jerry

---

From: <[email-masked]>
Date: Wed, 14 Jun 2006 06:22:17 +0300

As we have a number of drafts that people have been interested
in adding to our charter, I think we need to have some discussion
on this draft on the mailing list.  I'd like to get some consensus
if people feel this is a good way to go forward.

Some actual discussion & work on the draft - via mailing list
discussions - would be a good thing as well.

John 

>From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>Sent: 13 June, 2006 17:06
>To: Robert Hancock; [email-masked]
>Cc: Ash, Gerald R (Jerry), ALABS
>Subject: RE: [NSIS] partly-decoupled signalling work
>
>> http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt 
>followed by a 
>> productive discussion at the microphone (summary at 
>> comments and discussion additional to that expressed at the meeting. 
>> in particular, we'd like to understand if the WG thinks that the 
>> document is in a suitable state to be adopted as a working group 
>> draft.
>
>This had good support at IETF-65 to become a WG document, and 
>I continue to support that.  BTW, a link to the slides is at 
>http://www3.ietf.org/proceedings/06mar/slides/nsis-1/sld1.htm 
>(link above doesn't seem to work).
>
>Jerry
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Jun 2006 10:07:50 +0200

Hi all,

the working group expressed a lot of interest at last IETF meeting to 
move this work forward within the NSIS working group.

Is this a call for a hum again?
Is the question whether this document is a good starting point for the 
work on the partly-decoupled signaling work?
Is rechartering necessary before a document can be taken as a WG item?

Ciao
Hannes

[email-masked] wrote:
>>>many of you will be aware of a draft on an approach to 
>>
>>path-decoupled 
>>

---

From: <[email-masked]>
Date: Wed, 14 Jun 2006 11:17:11 +0300

Hi all,

No hum needed, but there are a number of items to add to the charter,
once GIST, QoS NSLP, NATFW NSLP, etc. get sent to the IESG.  I'm
hoping for some work to start before the document is added to our
charter.

A small rechartering may be needed.

John

>From: ext Hannes Tschofenig [mailto:[email-masked]] 
>Sent: 14 June, 2006 11:08
>To: Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [NSIS] partly-decoupled signalling work
>
>Hi all,
>
>the working group expressed a lot of interest at last IETF 
>meeting to move this work forward within the NSIS working group.
>
>Is the question whether this document is a good starting point 
>for the work on the partly-decoupled signaling work?
>> As we have a number of drafts that people have been interested in 
>> adding to our charter, I think we need to have some 
>discussion on this 
>> draft on the mailing list.  I'd like to get some consensus if people 
>> feel this is a good way to go forward.
>> 
>>>This had good support at IETF-65 to become a WG document, and I 
>>>continue to support that.  BTW, a link to the slides is at

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Jun 2006 11:38:01 +0200

Hi,

I would like to clarify a few thing. Any off-path or partly-decouple 
work would need to be chartered. My impression of the Dallas discussion 
was that people are not yet on the same page on what is needed in the 
larger scale. I know that there where views that Partly-Decoupled work 
was ready for adoption. But is this really the right way and how does it 
fit together with other proposals? So please continue discussing the 
topic and try to reach some consensus on that.

While this is ongoing the NSIS WG still has some tasks to finish.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Jun 2006 12:57:29 +0200

Hi Magnus,

I got the impression that the work on this subject over the last few 
years lead to:
http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem-03.txt

I don't see a competing proposal.

Ciao
Hannes

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 14 Jun 2006 14:40:29 +0300

hi magnus, john, all,

it is indeed clear that it's important to be precise about
what work we are actually talking about doing, especially
where the terms 'off path' and 'signalling' are used together.
we could be in problem statement/requirements territory,
framework updates, new protocol work or description of the
applicability of existing work (our draft comes into this
category), or indeed any combination of these.

when we (the authors) started down this track, our first
effort (based in part on advice from the chair) was quite
a broad survey of the problem and the possible pieces of 
different sorts of complete solution. that work was not done
in a vacuum - there was extensive discussion on the NSIS m.l.
during 2001-2 and during the NSIS w.g. session at ietf#54, 
a mini-bof in TSV at ietf#55, and a less mini-bof
(pads) at ietf#56. the drafts written around this time include 
draft-schelen-nsis-opopsig-01.txt, draft-declercq-vsn-arch-00.txt 
and draft-vandenbosch-nsis-resilience-00.txt 

anyway, we wrote our first -00 draft about a year ago, and it 
was discussed at length (albeit informally) after a WG interim;
we also got a very detailed review from Bob Braden and some
off-list feedback from the CCAMP chair. based on that, we
made revised versions (-01/-02) which became much more focussed
on a single part of the problem space, and a particular style
of solution; we discussed how the -02 ideas fitted into the
DCPEL proposal during the vancouver IETF, which was a helpful
example use case for us to understand better the sort of 
deployment considerations that have to be taken into account.
and version -03 which was discussed in Dallas parallels part 
of the work done by the EuQoS project (see draft-cordeiro-nsis-hypath-00).

so my impression of the current state of affairs is that
a) there has been extensive (very extensive) discussion of
  off-path signaling in its broadest sense
b) there is and probably never will be a single IETF view on 
  how the 'off-path' problem should actually be solved, 
  because of the huge range of different problems that the 
  heading actually covers
c) however, there is a view that the approach outlined in the 
  pds-problem draft is a valid solution to a particular technical
  problem which has applicability in a range of real scenarios.

so the issue now in a procedural sense is whether we need to
go back to the question in (b) and start again on that discussion. 
my concern is that this would be likely to turn into the sort of
open-ended ocean-boiling architectural discussion which is not
the best use of WG time. or should we be asking a more targetted
question about whether the approach proposed in pds-problem is
a useful enhancement to the applicability of all the protocol
work we are already doing (which is the question I tried to ask
in my original email). or there may be a third option.

cheers,

robert h.

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: 14 June 2006 12:38
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Jun 2006 15:20:59 +0200

Hi,

Thanks for the clarifications. I am missing most of the background on 
what has been done in this area prior. I am doing my best to catch up. 
It is also a reason I might be a bit defensive about taking on what I 
might think is new work.

I don't want to delay any re-chartering of work that the WG agrees on is 
the way. But I need to understand this before I bring it forward. Thus 
it will take some discussion on this topic before I am there.

So please consider Robert's question. I do like to see some answers on this.

Cheers

Magnus Westerlund