Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02)

From: <[email-masked]>
Date: Mon, 7 Jun 2010 07:59:00 +0200

Hi John,
Thank you for your comments:
Here are my view.

REQ-1:
I think that REQ-1 is still a justification, because not each Operator will use SIP-T for tunnelling purposes.
If you pass an untrusted domain SIP-T should not part, because it could include restricted numbers or other information that should not be presented to untrusted networks.

Also only for passing the Q.850 Cause code to encapsulate the whole ISUP is a little over dimensioned.
The SIP-T MIME can be lost due to the interdomain trust relation ships which the Reason header cannot.

For in an multi carrier/service provider environment like Germany is, it will not be secure that each operator will support SIP-T. 

REQ-2
It must be possible to provide an accurate indication to a 
UAC, so that the UAC can provide a suitable indication to the 
user.

So that is the proposal for REQ-2.

REQ-3 
   A UA may have the ability to display ISUP specific release causes or
   show a equivalent text.

So that would be sufficient enough for REQ-3. If people would like to see such text.

REQ-3/4
Your comment with regard to the type of UA is correct. I tried to satisfy people. The fact is that is not intended to include the Q.850 cause by an SIP end device. So the conclusion is changing REQ-3 and deleting REQ-4.

So now I would like to ask the people which requirements they would like to see in the draft.
As I understand John he sees only one (REQ-2)

I propose REQ-1, -2 and -3.

Opinions?

Thank you and Best Regards

Roland

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628-2766 (Tel.)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobil)
E-Mail: mailto:[email-masked]
http://www.telekom.com  

Erleben, was verbindet. 

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Dienstag, 18. Mai 2010 21:37
An: Jesske, Roland; [email-masked]
Betreff: RE: Reason In responses(draft-jesske-dispatch-reason-in-responses-02)

Roland, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 18 May 2010 15:57
> To: Elwell, John; [email-masked]
> Subject: AW: Reason In 
> responses(draft-jesske-dispatch-reason-in-responses-02)
> 
> Hi John,
> Thank you for your comments. 
> It was asked to split the draft into requirements and at 
> least procedures.
> 
> You are right that within the requirements draft is more that 
> requirements. It is also the motivation, justification and 
> examples. I can change the title if people are happy with it. 
> Question is if such a draft is also needed as RFC or if it 
> only seen as a temporary document during the discussion.
[JRE] I was not proposing a title change, and I have no problem combining motivation with requirements, although I do feel the examples look too much like solution and are unnecessary. Although some people asked you to split the draft, in my opinion it was wasted effort, but it is done now.

> 
> With regard to REQ-1 I propose the following re-wording:
> 
> It should be possible to support within native SIP 
> environment PSTN-SIP-PSTN scenarios where the reason of a 
> call release can be transferred though the SIP domain
> without any loss of information and no change of reason.
> 
> I think this was discussed lengthy during the last meeting 
> and email discussion.
> Not each PSTN GW will support ISUP MIME encapsulation. At 
> least the 3GPP IMS has no SIP. The IMS is not using SIP-T.
[JRE] I don't think the new wording makes any difference. SIP-T is a means for tunnelling a Q.850 cause through a native SIP domain. The IETF already defines SIP-T as the solution, and if this solution is not sufficient, you need to cite reasons why not and identify a requirement that cannot be met using SIP-T. Just saying that IMS does not use SIP-T doesn't sound like a sufficient reason to me, because clearly IMS could be made to use SIP-T.

To be clear, I am not saying that the Reason header field should not be used in this situation, if the header field is defined for use in responses in general in order meet other requirements. I am simply saying that REQ-1 is not sufficient justification for allowing the Reason header field in responses, since REQ-1 can be satisfied using an existing mechanism.

> 
> REQ-2 and REQ-3
> Yes it looks similar.
> 
> REQ-3 was added because it was seen from user device 
> perspective that the Device have the possibility to show the 
> Q.850 cause but that such a End Device does not include Q.850 
> causes. Of course a MGC should have this possibility.
> 
> I would be happy to shrink REQ-2 and 3 to your proposed text.
> 
> REQ-2
> It must be possible to provide an accurate indication to a 
> UAC, so that the UAC can provide a suitable indication to the 
> user. Whether this be an announcement, a textual message, an 
> icon, a flashing lamp, a tone, a vibration, an odour or 
> whatever, is a user interface matter.
[JRE] I did not intend the second sentence to be part of the requirement - it was just for illustration of why the existing text, which focused on textual display, was inadequate.

> 
> REQ-4 was the consequence of REQ-3 where we do not allow the 
> inclusion of a Q850 cause by a end device.
> 
> So the trick is not allow the SIP end device to include a 
> Q850 cause and in some certain cases to allow an service 
> provider controlled application server to include a Reason 
> header with a Q.850 cause. But it should not be done 
> generally by SIP applications. So normally a ISUP 
> implementation will use ISUP causes but not SIP implementations.
> But there are SIP Application servers out in the world that 
> will have a ISUP application (or ISUP like application that 
> reacts and behaves as within a ISUP network).
[JRE] I found REQ-3 rather confusing. On re-reading it, the first sentence is a requirement concerning reception, and the second sentence seems (if I understand correctly) to be a statement about sending. Assuming my understanding is correct, making a statement, within a requirement, that something is out of scope seems to suggest it is not part of the requirement.

In addition, the way SIP is specified, there is no real distinction between different types of UA. In other words, SIP procedures for UAs apply to UAs in general, not to specific types of UA like ASs. So writing a requirement that tries to distinguish between different types of UA does not seem to make sense.

> 
> Question is now how to proceed further.
> 
> Are people happy to have the documents split or put again 
> together with striking out the examples ect?
> Or to have the documents as they are with some transfer of 
> text to the draft-jesske-dispatch-reason-in-responses-02 draft?
[JRE] I don't have a strong opinion about document structure, although my personal preference would have been to leave it as one document, as it was originally. My main concern is trying to come up with a meaningful set of requirements, and in my opinion it reduces to a single requirement - being able to convey a Q.850 cause from PSTN (or similar) to a UAC so that the UAC can render meaningful information to the user.

John

> 
> Comments?
> 
> Thank you and Best Regards
> 
> Roland
> 
> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Donnerstag, 13. Mai 2010 09:24
> An: Jesske, Roland; [email-masked]
> Betreff: RE: Reason In 
> responses(draft-jesske-dispatch-reason-in-responses-02)
> 
> Roland,
> 
> In my view, there is a simple requirement to convey Q.850 
> causes in SIP response messages, so that the UAC will receive 
> a more accurate indication of the reason for rejection when 
> rejection comes from PSTN. The cause mapping table helps to 
> illustrate this. This is not rocket science, and I am 
> disappointed that we have not found a quick way of 
> dispatching this and just getting the work done. In my 
> opinion the split into separate documents was unnecessary 
> (take as an example the recently-published RFC 5876, which 
> combines motivation and solution in one document), but it has 
> been done now. Unfortunately I don't think it has moved us 
> any further forward.
> 
> I don't think the requirements in section 3 are particularly 
> well expressed. REQ-1 can already be met by tunnelling in 
> accordance with SIP-T. I would not expect the IETF to provide 
> a new solution specifically for that requirement.
> 
> I think REQ-2 and REQ-3 boil down to the same thing - it must 
> be possible to provide an accurate indication to a UAC, so 
> that the UAC can provide a suitable indication to the user. 
> Whether this be an announcement, a textual message, an icon, 
> a flashing lamp, a tone, a vibration, an odour or whatever, 
> is a user interface matter.
> 
> I also find REQ-4 rather problematic. If we have a solution 
> for PSTN, we would also have a solution for some other form 
> of gateway into a domain that provides a "PSTN-like service". 
> Unfortunately, if you try to bring this out as a separate 
> requirement, it raises the question of what exactly is this 
> "PSTN-like service", and if it is somehow SIP-based, why it 
> needs to be "PSTN-like", and so on.
> 
> Basically I think there is only a single requirement here - 
> provision of a correct indication to a UAC when rejection 
> comes from the PSTN. I think that is a reasonable requirement 
> and we should just go ahead and do it, rather like we did 
> with RFC 5876 when we extended the range of messages that 
> PAI/PPI could be used in.
> 
> I find the statement in REQ-3 "A inclusion of [Q.850] causes 
> is out of scope." very strange. I thought the whole idea was 
> to convey Q.850 causes, so why say they are out of scope? I 
> assume this is some sort of typo.
> 
> I think one of the consequences of deciding to split 
> requirements and solution into separate drafts is that the 
> requirements draft has to stick to motivation and 
> requirements. I find too much in the draft (particularly the 
> examples) that smells of solution.
> 
> John
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of [email-masked]
> > Sent: 13 May 2010 03:05
> > To: [email-masked]
> > Subject: Re: [dispatch] Reason In responses 
> > (draft-jesske-dispatch-reason-in-responses-02)
> > 
> > Dear all, 
> > I have asked for comments on the two drafts mentioned below. 
> > So far I didn't get any. Does that mean that people are happy 
> > now with the content and we could proceed with it? 
> > 
> > Thank you and Best Regrads 
> > 
> > Roland 
> > 
> > 
> > _____________________________________________ 
> > Von:    Jesske, Roland  
> > Gesendet:       Donnerstag, 8. April 2010 09:46 
> > An:     [email-masked] 
> > Betreff:        Reason In responses 
> > (draft-jesske-dispatch-reason-in-responses-02) 
> > 
> > Dear all, 
> > During the discussion concerning the Reason header field in 
> > Responses I was asked to split the document into an 
> > requirements part and an protocol part.
> > 
> > So please feel free to comment on the drafts. 
> > 
> > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo
> > nses-02 
> > <http://64.170.98.42/html/draft-jesske-dispatch-reason-in-resp
> > onses-02>  
> > 
> > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r
> > esponses-00 
> > <http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-
> > responses-00>  
> > 
> > Best regards 
> > 
> > Roland Jesske 
> > 
> > 
> > Deutsche Telekom Netzproduktion GmbH 
> > Zentrum Technik Einführung 
> > Roland Jesske 
> > Heinrich-Hertz-Straße 3-7, 64295 Darmstadt 
> > +49 6151 628-2766 (Tel.) 
> > +49 521 9210-3753  (Fax) 
> > +49 171 8618-445  (Mobil) 
> > E-Mail: [email-masked] <mailto:[email-masked]>  
> > www.telekom.com <http:www.telekom.com>   
> > 
> > Erleben, was verbindet. 
> > 
> > Deutsche Telekom Netzproduktion GmbH 
> > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) 
> > Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), 
> > Albert Matheis, Klaus Peren 
> > Handelsregister: Amtsgericht Bonn HRB 14190 
> > Sitz der Gesellschaft: Bonn 
> > USt-IdNr. DE 814645262 
> > 
> > Große Veränderungen fangen klein an - Ressourcen schonen und 
> > nicht jede E-Mail drucken. 
> > 
> > 
> > 
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Jun 2010 16:27:57 +0200

> Sent: 07 June 2010 06:59
> I think that REQ-1 is still a justification, because not each 
> Operator will use SIP-T for tunnelling purposes.
> If you pass an untrusted domain SIP-T should not part, 
> because it could include restricted numbers or other 
> information that should not be presented to untrusted networks.
> 
> The SIP-T MIME can be lost due to the interdomain trust 
> relation ships which the Reason header cannot.
> 
> For in an multi carrier/service provider environment like 
> Germany is, it will not be secure that each operator will 
> support SIP-T. 
[JRE] This helps to explain why SIP-T is not sufficient. IF SIP-T requires you to include additional information that you may not want to include when going outside a domain, that would be a reason for requiring a different solution. This was not made clear before.

John

> Your comment with regard to the type of UA is correct. I 
> tried to satisfy people. The fact is that is not intended to 
> include the Q.850 cause by an SIP end device. So the 
> conclusion is changing REQ-3 and deleting REQ-4.
> 
> [JRE] I was not proposing a title change, and I have no 
> problem combining motivation with requirements, although I do 
> feel the examples look too much like solution and are 
> unnecessary. Although some people asked you to split the 
> draft, in my opinion it was wasted effort, but it is done now.
> 
> > 
> [JRE] I don't think the new wording makes any difference. 
> SIP-T is a means for tunnelling a Q.850 cause through a 
> native SIP domain. The IETF already defines SIP-T as the 
> solution, and if this solution is not sufficient, you need to 
> cite reasons why not and identify a requirement that cannot 
> be met using SIP-T. Just saying that IMS does not use SIP-T 
> doesn't sound like a sufficient reason to me, because clearly 
> IMS could be made to use SIP-T.
> 
> To be clear, I am not saying that the Reason header field 
> should not be used in this situation, if the header field is 
> defined for use in responses in general in order meet other 
> requirements. I am simply saying that REQ-1 is not sufficient 
> justification for allowing the Reason header field in 
> responses, since REQ-1 can be satisfied using an existing mechanism.
> 
> 
> > 
> > REQ-2 and REQ-3
> > Yes it looks similar.
> > 
> [JRE] I did not intend the second sentence to be part of the 
> requirement - it was just for illustration of why the 
> existing text, which focused on textual display, was inadequate.
> 
> > 
> [JRE] I found REQ-3 rather confusing. On re-reading it, the 
> first sentence is a requirement concerning reception, and the 
> second sentence seems (if I understand correctly) to be a 
> statement about sending. Assuming my understanding is 
> correct, making a statement, within a requirement, that 
> something is out of scope seems to suggest it is not part of 
> the requirement.
> 
> In addition, the way SIP is specified, there is no real 
> distinction between different types of UA. In other words, 
> SIP procedures for UAs apply to UAs in general, not to 
> specific types of UA like ASs. So writing a requirement that 
> tries to distinguish between different types of UA does not 
> seem to make sense.
> 
> > 
> [JRE] I don't have a strong opinion about document structure, 
> although my personal preference would have been to leave it 
> as one document, as it was originally. My main concern is 
> trying to come up with a meaningful set of requirements, and 
> in my opinion it reduces to a single requirement - being able 
> to convey a Q.850 cause from PSTN (or similar) to a UAC so 
> that the UAC can render meaningful information to the user.
> 
> John
> 
> 
> > 
> > Comments?
> >

---

From: <[email-masked]>
Date: Wed, 23 Jun 2010 09:32:32 +0200

Hi John,
After reading this thread again, I would like to propose two requirements as follows:

REQ-1:
It should be possible to support PSTN-SIP-PSTN scenarios where the reason of a call release can be transferred though the SIP domain without any loss of information and no change of reason.</t

REQ-2:
It must be possible to provide an accurate indication to a UAC, so that the UAC can provide a suitable indication 
to the user.

As an additional Option there could be a third one as follows:

REQ-3:

UA may have the ability to display ISUP specific release causes or show a equivalent text. 

Please indicate if you see this RE-3 within the scope or if it is already covered by REQ-2.

Opinions. 

If people are happy I will provide an updated draft.

Best Regards

Roland

Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628-2766 (Tel.)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobil)
E-Mail: [email-masked]
www.telekom.com  

Erleben, was verbindet. 

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Dienstag, 15. Juni 2010 16:28
An: Jesske, Roland; [email-masked]
Betreff: RE: Reason In responses(draft-jesske-dispatch-reason-in-responses-02)

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 23 Jun 2010 14:28:43 +0200

> Sent: 23 June 2010 08:33
> It should be possible to support PSTN-SIP-PSTN scenarios
> where the reason of a call release can be transferred though
> the SIP domain without any loss of information and no change
> of reason.</t
>
> REQ-2:
> UAC, so that the UAC can provide a suitable indication
> to the user.
>
>
>
[JRE] This has no impact on the protocol and therefore is out of scope.

John

> [JRE] This helps to explain why SIP-T is not sufficient. IF
> SIP-T requires you to include additional information that you
> may not want to include when going outside a domain, that
> would be a reason for requiring a different solution. This
> was not made clear before.
>
> John
>
> >
> > REQ-2

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Wed, 23 Jun 2010 12:30:32 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]

Hi John,

REQ-1:

REQ-2:

REQ-3:
UA may have the ability to display ISUP specific release causes or show a equivalent text.
_______________________________________________

For REQ-1, I would rephrase it to be something like "where an ISUP release code can be transferred transparently through the SIP domain".  Both "loss of information" and "no change of reason" are subject to interpretation -- what we're really hunting for is the ISUP release code (as a *number*) to go in one end and come out the other end unchanged.

As written REQ-2 is rather vague.  What does "accurate" mean in this context?

I think what you mean by REQ-3 is "A SIP UAC originating a dialog which terminates at a SIP-to-PSTN gateway can determine the exact ISUP release code provided by the gateway."

Dale

---

From: Tom Taylor <[email-masked]>
Date: Wed, 23 Jun 2010 12:37:43 -0400

Query on REQ-3: are we talking about ISUP or ISDN release causes being forwarded 
from the PSTN?

> If people are happy I will provide an updated draft.
...

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Wed, 23 Jun 2010 16:20:56 -0400

ISUP, though there is an overlap with ISDN

If from ISDN, then there is an interworking ISDN-->ISUP-->SIP

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Taylor
Sent: Wednesday, June 23, 2010 12:38 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] ReasonIn
responses(draft-jesske-dispatch-reason-in-responses-02)

Query on REQ-3: are we talking about ISUP or ISDN release causes being
forwarded 
from the PSTN?

[email-masked] wrote:
> It should be possible to support PSTN-SIP-PSTN scenarios where the
reason of a call release can be transferred though the SIP domain
without any loss of information and no change of reason.</t
> 
> REQ-2:
> It must be possible to provide an accurate indication to a UAC, so
that the UAC can provide a suitable indication 
...
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Wed, 23 Jun 2010 21:13:18 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of DOLLY, MARTIN C (ATTLABS) [[email-masked]]

One thing I haven't seen discussed is what is the meaning of carrying the ISUP release code transparently if there is more than one variety of ISUP, if the same release code has different meanings in different PSTN networks.  In a perfect world, SIP would carry not only the ISUP release code, but some identification of the *system* of ISUP release codes that it was drawn from.

Dale

---

From: <[email-masked]>
Date: Thu, 24 Jun 2010 09:44:15 +0200

Hi Dale,
Perhaps some more words, like that:

REQ-2:
It must be possible to provide an accurate indication to a UAC why the call was released, so that the UAC can provide a suitable indication. 

After discussion on this requirement the proposal was to keep it generic. So now I tried to add some words to make is a little more related to the kind of indication.

As it looks like you would like to see the 3rd requirement in addition. Correct?

If yes then I changed the wording you provided to:
REQ-3 : 
A SIP UAC originating a dialog which terminates at a SIP-to-PSTN gateway can determine the exact ISDN/ISUP Q.850 release code interworked by the gateway or show an equivalent text.

The Question then is how to express it that the SIP Dialog of course terminates at the GW but the call itself is terminated within the PSTN/ISDN network. And the cause is provided by the PSTN/ISDN network. So that why I took the wording interworked by the gateway.

Other views?

Best Regards

Roland

Mit freundlichen Grüßen
Roland Jesske

Erleben, was verbindet. 

-----Ursprüngliche Nachricht-----
Von: WORLEY, Dale R (Dale) [mailto:[email-masked]] 
Gesendet: Mittwoch, 23. Juni 2010 18:31
An: Jesske, Roland; [email-masked]; [email-masked]
Betreff: RE: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02)

Hi John,

REQ-1:

REQ-2:

REQ-3:

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Jun 2010 11:00:55 +0200

> Sent: 24 June 2010 08:44
> To: [email-masked]; Elwell, John; [email-masked]
> Subject: AW: [dispatch] Reason 
> Inresponses(draft-jesske-dispatch-reason-in-responses-02)
> 
> Hi Dale,
> UAC why the call was released, so that the UAC can provide a 
> suitable indication. 
> 
> After discussion on this requirement the proposal was to keep 
> it generic. So now I tried to add some words to make is a 
> little more related to the kind of indication.
> 
> A SIP UAC originating a dialog which terminates at a 
> SIP-to-PSTN gateway can determine the exact ISDN/ISUP Q.850 
> release code interworked by the gateway or show an equivalent text.
[JRE] The words " or show an equivalent text" are user-interface specific and should be deleted. Determination of the Q.850 cause is sufficient - what the UA then does with it (e.g., displays the cause number, displays text, shows an icon, plays a tone or announcement) is outside the scope of SIP.

I still have difficult determining the need for both REQ-2 and REQ-3. If we have REQ-3, why do we need REQ-2. SIP already provides a means of satisfying REQ-2 through regular SIP response codes, since REQ-2 says nothing about information from PSTN. If we talk about Q.850 causes in REQ-2, what would be the difference between REQ-2 and REQ-3?

John

> 
> The Question then is how to express it that the SIP Dialog of 
> course terminates at the GW but the call itself is terminated 
> within the PSTN/ISDN network. And the cause is provided by 
> the PSTN/ISDN network. So that why I took the wording 
> interworked by the gateway.
> 
> Other views?
> 
> Best Regards
> 
> Roland
> 
> Mit freundlichen Grüßen
> Roland Jesske
> 
> 
> Betreff: RE: [dispatch] Reason 
> Inresponses(draft-jesske-dispatch-reason-in-responses-02)
> 
> From: [email-masked] [[email-masked]] 
> On Behalf Of [email-masked] [[email-masked]]
> 
> Hi John,
> For REQ-1, I would rephrase it to be something like "where an 
> ISUP release code can be transferred transparently through 
> the SIP domain".  Both "loss of information" and "no change 
> of reason" are subject to interpretation -- what we're really 
> hunting for is the ISUP release code (as a *number*) to go in 
> one end and come out the other end unchanged.
> 
> I think what you mean by REQ-3 is "A SIP UAC originating a 
> dialog which terminates at a SIP-to-PSTN gateway can 
> determine the exact ISUP release code provided by the gateway."
> 
> Dale
>

---

From: <[email-masked]>
Date: Thu, 24 Jun 2010 14:43:37 +0200

Hi John,
>From my side we can go with two requirements. Your comment is correct and REQ-2 and 3 are overlapping.
 
Who would like to see in addition REQ-3 please indicate and Who not. I'm waiting for your response.

Thank you.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Donnerstag, 24. Juni 2010 11:01
An: Jesske, Roland; [email-masked]; [email-masked]
Betreff: RE: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02)

John