Subject: [Speermint] I-D ACTION:draft-ietf-speermint-srv-naptr-use-00.txt

From: [email-masked]
Date: Mon, 16 Oct 2006 15: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		: Use of DNS SRV and NAPTR Records for SPEERMINT 
	Author(s)	: T. Creighton, G. Khandpur
	Filename	: draft-ietf-speermint-srv-naptr-use-00.txt
	Pages		: 9
	Date		: 2006-10-16
	
   The objective of this document is to specify the Best Current 
   Practice (BCP) adopted by a Voice Over IP (VoIP) service provider in 
   order to locate another VoIP service provider to peer with in the 
   context of Session PEERing for Multimedia INTerconnect. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-srv-naptr-use-00.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-srv-naptr-use-00.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-srv-naptr-use-00.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: Otmar Lendl <[email-masked]>
Date: Mon, 16 Oct 2006 23:17:23 +0200

> 	Filename	: draft-ietf-speermint-srv-naptr-use-00.txt

I may be missing something, but is there anything in this draft
which isn't just a summary of RFCs 3263 and 2782?

The abstract says:

Given the discussions on-list and at the meetings: This does not
describe what the current practice is. It just describes the theory in
the current RFCs. The current practice is either manually nailed down
peerings or a fabric which resolves numbers to ingress points.

Does this describe what we want to establish as the "best future
practice"? Can we really do that before we have nailed down the
requirements?

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Benny Prijono <[email-masked]>
Date: Wed, 18 Oct 2006 12:31:08 +0100

> 	Filename	: draft-ietf-speermint-srv-naptr-use-00.txt

Some comments.

Talking from the point of view of a person who's just implemented SRV, 
I think I would welcome this document as additional information about 
how SRV should work, because frankly I was having difficulties in 
finding some information on the subject.

But in general, I felt that probably we could add some "depths" into 
the information, or otherwise one might view this document as just 
stating the obvious (things like "everybody SHOULD implement highly 
scalable and fault-tolerant servers", without suggesting *how* one can 
achieve it).

So probably the draft can say something, preferably with some SRV 
setting samples, about configuring SRV for this, considering the 
throughput desired, load-balancing, fail-over requirements, etc. 
Something like this probably:
http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00800a9818.shtml

Another thing that we could add is how fail-over should happen in 
various SRV configurations, especially when both load-balancing and 
fail-over are used. For example, given the configuration below:

  ;;          Priority Weight Port   Target
      IN SRV  0        10      5060   sip1.example.com
      IN SRV  0        10      5060   sip2.example.com
      IN SRV  0        10      5060   sip3.example.com
      IN SRV  1        10      5060   sip4.example.com

if sip1.example.com fails, then where should the client send the next 
request to? sip2/sip3, or sip4? IMO it's sip4. I think it's quite 
important to mention this, so that both sides of the network can 
expect the same behavior to happen in case of failures. And frankly I 
couldn't find a clear explanation for this anywhere, so I thought this 
document could be the best place to mention this.

Last. In some places, probably it's best to just give pointer on how 
to get the information instead of duplicating the information. For 
example, in "3.1 TARGET Determination", probably it's best to just 
give pointer to relevant section in RFC 3261, because, for one thing, 
the target determination is a little bit more than that (for example, 
";lr" parameter in Route header needs to be considered).

Just my $0.02p.

-benny

-- 
Benny Prijono
http://www.pjsip.org