Subject: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-01.txt

From: [email-masked]
Date: Tue, 15 May 2007 18:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: VoIP SIP Peering Use Cases
	Author(s)	: A. Uzelac, et al.
	Filename	: draft-ietf-speermint-voip-consolidated-usecases-01.txt
	Pages		: 20
	Date		: 2007-5-15
	
This document will capture the VoIP use case for SIP Peering.  It is 
        a consolidation of other Speermint use cases and will focus 
        exclusively on VoIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-speermint-voip-consolidated-usecases-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 17 May 2007 23:38:48 -0400

As with the IM document, please get comments to the editor asap so we
can come to Chicago with a -02 if necessary.

Thanks
Jason 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, May 15, 2007 6:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] I-D 
> ACTION:draft-ietf-speermint-voip-consolidated-usecases-01.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session PEERing for 
> Multimedia INTerconnect Working Group of the IETF.
> 
> 	Filename	: 
> draft-ietf-speermint-voip-consolidated-usecases-01.txt
> 	Pages		: 20
> 	Date		: 2007-5-15
> 	
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 	"FILE 
> /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas
> es-01.txt".
> 	
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 25 May 2007 07:23:39 +0100

Adam,

I have reviewed this draft and I think it needs a lot more work to use
consistent and well-defined terms and to make the distinction between
indirect and assisted use cases more clear. When I read the previous
version I thought I understood it, but now reading the present version
more carefully I find I really don't understand it. Specific comments:

1. In section 2 (terminology) there is a reference to 06 of the
terminology draft, followed by figure 1. Figure 1 uses many terms not
defined in the terminology draft and there is no further explanation of
these terms in section 2. Furthermore there is no explanation of how to
interpret figure 1. Relevant information occurs later, but as it stands
the document cannot be read in sequence.

2. There is also inconsistent terminology elsewhere, e.g., figure 2
shows LS-O, which in the accompanying text seems to be referred to as
routing database. As another example, the text accompanying figure 3
mentions a proxy, which is not shown in figure 3. In 3.1.2.1 it mentions
"The SBEs", yet the figure shows only a single SBE.

3. In section 3, terms like O-VSP, A-VSP and T-VSP are not defined.

4. In 3.1.3.1 it states "The direct peering use case with 2 SBEs is
typically seen where  both the originating and terminating domain are
SPs." It can also occur where one or both domains are enterprises,
although of course the other direct cases are also possible here.

5. Section 3.2.1 on indirect peering uses the terms A-SBE and A-DBE
without definition. Section 3 uses the term A-VSP, but that is in the
context of assisted peering, not indirect peering. Also the terms
"Assisted PSP" and "Assisted domain" are used but not defined (here or
in the terminology document). Firstly, the word "assisted" is confusing
because it seems that it should be "assisting" rather than "assisted".
Secondly the word seems more appropriate to assisted peering than to
indirect peering.

6. In fact the definitions of indirect peering and assisted peering in
the terminology draft are insufficient to make a clear distinction
between the two. If signalling is routed securely from domain A to
domain B via a proxy in a third domain, this would seem to fit both
indirect peering and assisted peering, as defined in the terminology
draft. Likewise I think it fits both indirect peering and assisted
peering as described in section 3 of the consolidated uses cases draft.

7. Furthermore there doesn't seem to be a real distinction between
figure 5 (indirect) and figure 6 (assisted). Both employ an LS-a, an
A-SBE and an A-DBE.

8. The abbreviation "T" seems sometimes to be used for "Terminating" and
sometimes for "Transit".

9. I think the terms "indirect" and "transit" are used interchangeably
at times. If so, please use just a single term - if not, clarify the
difference.

10. The indirect use case does not show egress SBEs in the originating
and transit domains. Presumably this is a possibility. It is not
feasible to show all permutations in figures, but at least there should
be some mention in text of the possibility. However, see also the next
comment, which may remove the need.

11. In general, trying to show the internal composition of a domain is
not helpful. Issues of internal organisation (i.e., whether or not there
is an egress SBE and/or ingress SBE) seem to cloud the real behaviour of
domains, and in particular gets in the way of understanding the real
differences between the 3 use cases (in particular, indirect and
assisted). I would much prefer to see each domain treated as a black
box.

12. I was asked to check whether this covered enterprise use cases
identified in draft-elwell-speermint-enterprise-usecases-00. In as far
as it goes, I guess it does in theory cover the use cases part, although
not always explicitly. In particular there is no provision for two
transit domains in series, e.g., enterprise 1 - carrier 1 - carrier 2 -
enterprise 2.  Note that the enterprise-usecases draft goes beyond use
cases and discusses some technical issues too, and these are not covered
in your draft (and indeed probably should not be covered in your draft).

I look forward to the 02 version before Chicago.

John

> From: Livingood, Jason [mailto:[email-masked]] 
> Sent: 18 May 2007 04:39
> To: [email-masked]
> Subject: RE: [Speermint] 
> I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-01.txt
> 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 25 May 2007 11:57:07 -0400

Thank you for the feedback John. Expect a vastly re-worked version of
this draft soon. We (the multiple authors) have an avalanche of feedback
to filter through and incorporate.  Some points below to pertaining to
your feedback...

In Prague - there were some folks that took exception to the definitions
providing distinction between indirect and assisted use cases.  With
feedback from you and others, I believe we can clear up the ambiguity.  

Also, due to a suggestion from the Prague meeting - the vast terminology
section I originally has been moved to the terminology draft.  The issue
at hand is that a new version of the term draft with those additions has
not been released yet.

Adam Uzelac
Director Converged Arch.
Global Crossing
585-255-8916

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, May 25, 2007 2:24 AM
> To: [email-masked]; Uzelac, Adam
> Cc: Livingood, Jason; Rodrig, Benny (Benny)
> Subject: RE: [Speermint] 
> I have reviewed this draft and I think it needs a lot more 
> work to use consistent and well-defined terms and to make the 
> distinction between indirect and assisted use cases more 
> clear. When I read the previous version I thought I 
> understood it, but now reading the present version more 
> carefully I find I really don't understand it. Specific comments:
> 
> 1. In section 2 (terminology) there is a reference to 06 of 
> the terminology draft, followed by figure 1. Figure 1 uses 
> many terms not defined in the terminology draft and there is 
> no further explanation of these terms in section 2. 
> Furthermore there is no explanation of how to interpret 
> figure 1. Relevant information occurs later, but as it stands 
> 2. There is also inconsistent terminology elsewhere, e.g., 
> figure 2 shows LS-O, which in the accompanying text seems to 
> be referred to as routing database. As another example, the 
> text accompanying figure 3 mentions a proxy, which is not 
> shown in figure 3. In 3.1.2.1 it mentions "The SBEs", yet the 
> figure shows only a single SBE.
> 
> 4. In 3.1.3.1 it states "The direct peering use case with 2 
> SBEs is typically seen where  both the originating and 
> terminating domain are SPs." It can also occur where one or 
> both domains are enterprises, although of course the other 
> direct cases are also possible here.
> 
> 5. Section 3.2.1 on indirect peering uses the terms A-SBE and 
> A-DBE without definition. Section 3 uses the term A-VSP, but 
> that is in the context of assisted peering, not indirect 
> peering. Also the terms "Assisted PSP" and "Assisted domain" 
> are used but not defined (here or in the terminology 
> document). Firstly, the word "assisted" is confusing because 
> it seems that it should be "assisting" rather than "assisted".
> Secondly the word seems more appropriate to assisted peering 
> than to indirect peering.
> 
> 6. In fact the definitions of indirect peering and assisted 
> peering in the terminology draft are insufficient to make a 
> clear distinction between the two. If signalling is routed 
> securely from domain A to domain B via a proxy in a third 
> domain, this would seem to fit both indirect peering and 
> assisted peering, as defined in the terminology draft. 
> Likewise I think it fits both indirect peering and assisted 
> 7. Furthermore there doesn't seem to be a real distinction 
> between figure 5 (indirect) and figure 6 (assisted). Both 
> employ an LS-a, an A-SBE and an A-DBE.
> 
> 8. The abbreviation "T" seems sometimes to be used for 
> "Terminating" and sometimes for "Transit".
> 
> 9. I think the terms "indirect" and "transit" are used 
> interchangeably at times. If so, please use just a single 
> term - if not, clarify the difference.
> 
> 10. The indirect use case does not show egress SBEs in the 
> originating and transit domains. Presumably this is a 
> possibility. It is not feasible to show all permutations in 
> figures, but at least there should be some mention in text of 
> the possibility. However, see also the next comment, which 
> may remove the need.
> 
> 11. In general, trying to show the internal composition of a 
> domain is not helpful. Issues of internal organisation (i.e., 
> whether or not there is an egress SBE and/or ingress SBE) 
> seem to cloud the real behaviour of domains, and in 
> particular gets in the way of understanding the real 
> differences between the 3 use cases (in particular, indirect 
> and assisted). I would much prefer to see each domain treated 
> as a black box.
> 
> 12. I was asked to check whether this covered enterprise use 
> cases identified in 
> draft-elwell-speermint-enterprise-usecases-00. In as far as 
> it goes, I guess it does in theory cover the use cases part, 
> although not always explicitly. In particular there is no 
> provision for two transit domains in series, e.g., enterprise 
> 1 - carrier 1 - carrier 2 - enterprise 2.  Note that the 
> enterprise-usecases draft goes beyond use cases and discusses 
> some technical issues too, and these are not covered in your 
> draft (and indeed probably should not be covered in your draft).
> 
> message to 
> > > [email-masked] with the word unsubscribe 
> in the body 
> > > of the message.
> > > You can also visit
> > > logging in, type "cd internet-drafts" and then "get 
> > > draft-ietf-speermint-voip-consolidated-usecases-01.txt".
> > >