Subject: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Apr 2010 16:47:16 -0400

Folks,

I wanted to bring your attention to an Internet Draft we submitted today
related to one use of the SIP OPTIONS message.  This draft describes the use
of OPTIONS as an application-level "ping" mechanism.

It is important to point out two things:
 1) We are not defining any new extensions to SIP, but merely attempt
    to define the use of OPTIONS as a "ping" mechanism in a way that
    will be interoperable. We've found a lot of equipment that does
    this and it is done inconsistently from one vendor or product
    to the next.  We believe we need to ensure that devices
    implement an OPTIONS "ping" mechanism with some level of
    consistency and suggest either a standards track document
    or a BCP-type document.
 2) These procedures are not intended to be used in lieu of a proper
    load balancing or capacity reporting mechanism: the scope is
    deliberately narrowly focused to allowing a SIP entity to
    determine the status of another entity, usually a next-hop
    neighbor.

We would welcome any comments on the draft.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Friday, April 02, 2010 11:00 AM
> To: [email-masked]
> Subject: I-D Action:draft-jones-sip-options-ping-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : Using OPTIONS to Query for Operational Status
> in the Session Initiation Protocol (SIP)
> 	Author(s)       : V. Bhargava, et al.
> 	Filename        : draft-jones-sip-options-ping-00.txt
> 	Pages           : 7
> 	Date            : 2010-04-02
> 
> This document describes a procedure for using the OPTIONS method
> defined for the Session Initiation Protocol (SIP) in order to allow one
> SIP entity to query the status of another SIP entity.  Through
> discovery of the status of a SIP entity, it is possible to expedite
> session establishment or provide diagnostic information to network
> administrators.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jones-sip-options-ping-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 02 Apr 2010 16:23:05 -0500

This text:

> When a receiving SIP entity is experiencing heavy load, but still
>    willing to accept new dialogs, it SHOULD return a 486 response code.
>    In receipt of a 486, the querying SIP entity SHOULD make an effort
>    to avoid establishing new dialogs with the heavily loaded server
>    until it subsequently receives a 200 from that server.
> 

could conceivably be interpreted by a reader in such a way that they'd
expect to receive the 200 response without having to have sent an
additional OPTIONS; anyone who understands SIP at all should not reach
that conclusion, but a change to '... until it receives a 200 response
code to a subsequent OPTIONS message sent to that server' would
eliminate any possible confusion.

This may be more than you intend to include in your draft, but in
Asterisk we use the response time to OPTIONS pings to adjust the T1
timer for future requests to that server as well, in order to reduce
delays when attempting to route calls. Since part of the purpose of this
draft is to document a method to reduce session delivery delays, is it
worth considering documenting this behavior as well?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Apr 2010 19:32:01 -0400

Kevin,

> eliminate any possible confusion.

Great suggestion.  I've made the change in my local draft to what you
propose.
 
> worth considering documenting this behavior as well?

I'm certainly open to what makes sense.  The objective, of course, is to try
to reach some form of consensus on how this ought to be done and to provide
guidance, as I'm seeing so much variation in something that should be so
simple.

My first target was really the response codes.  You'll note I didn't propose
changing the rules (at least as I understand them), but it amazes me as to
how many different response codes I've seen related to use of OPTIONS as a
ping mechanism.

I'm most certainly open to adding other recommendations to the draft.  I
don't mind playing editor and taking input from all interested parties.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 3 Apr 2010 15:12:40 -0400

Hey Paul,
Right, so I suspect most everyone would agree that this is the most common usage of OPTIONS, or at least one of 'em.  And I agree it has interop problems left and right, and requires manual provisioning and testing of specific behavior on a per hop basis. 

The problem is I suspect it would be hard to get this to be a WG doc. :(

First, because it's an ambiguous usage of the method.  You could define an option-tag to make it clear, however. (along with a header to say "I'm using this option-tag's mechanism for this request")  

But more importantly because it conflicts with two other pieces of work being done in the IETF:
1) The keep-alive portion, which is done by RFC 5626 and also being worked on in draft-ietf-sipcore-keep.
2) The overload portion, for which people are trying to form a new WG out of DISPATCH, based on RFC 5390 and the work of a design team implementing and testing various individual drafts.  If I recall right, that work actually started because the 503 Retry-After model was found to be poor.

You could, of course, just go for an individual informational publication.  But without the option-tag (which requires a standards-track doc right now), it wouldn't solve the problem of manual configuration, because different devices currently do different things than what this doc recommends.

Other, specific comments on the draft:
0) You might want to consider specifying what the To/From-URIs should be sent as, and that a receiver should be lenient.  We've seen interop problems with those URIs for OPTIONS pings.

1) Section 6 says: "When a receiving SIP entity is unable to process SIP messages, it SHOULD respond with a 503 response code."  Clearly you can't mean that literally, since OPTIONS is a SIP message and responding to it would require processing it. :)  But you presumably also don't mean when the entity is too busy, because you recommend using 486 for that case.  So what is this intended to mean?  Unable to process new dialogs?

2) Section 6 says: "A SIP entity MUST respond to an OPTIONS method with a 200 response code when it is willing and able to process SIP messages."  Again, this can't be meant literally, because two paragraphs later a 486 is indicated when it is experiencing heavy load but still willing to accept new dialogs.  Maybe just a "...unless one of the following cases apply" needs to be added at the end of the sentence.  BTW, do you really mean "SIP messages", or do you mean out-of-dialog requests other than OPTIONS, or only dialog-forming requests?

3) Section 7 says: "If a requesting entity receives a 486 or 503
   response code, it MAY send a subsequent OPTIONS messages in order to
   detect a change in operational status, but it MUST honor the Retry-
   After header field."
Do you mean it must honor the Retry-After such that it does not send the OPTIONS ping based on it?  Or do you only mean it has to honor the Retry-After for other request types?  Also, it's a nit, but the sentence should be "...honor the Retry-After header field value received in the previous response."

4) Section 5.1 says: "The OPTIONS message MUST be transmitted directly to the peer's IP address and not to an intermediary SIP entity."  What do you mean by "intermediary SIP entity"?  Either it is the next-hop, or it's not.  If your next-hop is X, send it to X.  If to get to your "peer" you have to use a proxy, then that proxy *is* your next-hop, and *is* your "peer".  Bypassing it won't help you in the general case. (in some specific cases, sure, but not generally; and in some cases it makes things worse, so it can't be a MUST)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul E. Jones
> Sent: Friday, April 02, 2010 4:47 PM
> To: [email-masked]
> Cc: 'Vivek Bhargava (vbharga)'; 'Gonzalo Salgueiro'
> Subject: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt
> 
> Folks,
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 3 Apr 2010 23:18:01 -0400

Hadriel,

> The problem is I suspect it would be hard to get this to be a WG doc.

That might be tough, but I'd be content with something less than that, such
an informational document that folks can agree to.  I think it's important
to get something that we can refer to and say "that's how it's supposed to
work" since I see many variants.
 
> First, because it's an ambiguous usage of the method.  You could define
> an option-tag to make it clear, however. (along with a header to say
> "I'm using this option-tag's mechanism for this request")

Is it ambiguous?  The fact so many people elected to use it suggests that it
makes sense to use.  What is ambiguous is the exact usage.
 
> worked on in draft-ietf-sipcore-keep.

That document covers a different problem that's not related to an
application "ping" between two devices.  One could view it as such for
active sessions, I suppose, but it really has a different focus.

> 2) The overload portion, for which people are trying to form a new WG
> out of DISPATCH, based on RFC 5390 and the work of a design team
> implementing and testing various individual drafts.  If I recall right,
> that work actually started because the 503 Retry-After model was found
> to be poor.

Likewise, this one is also different.  We're not trying to replicate the
overload work.  Everything specified in this document, I think, is what the
SIP specs say today, except that nothing states that use of OPTIONS can be
used as an application-level "ping".  The 503 response indicating that the
device is overloaded, for example, came directly from RFCF 3261 Section
21.5.4.  If there are issues with use of 503 in a "ping" between two
adjacent devices, then we ought to consider that, but in no way do I want to
replicate the work over "overload", which has a far broader scope.
 
> You could, of course, just go for an individual informational
> publication.  But without the option-tag (which requires a standards-
> track doc right now), it wouldn't solve the problem of manual
> configuration, because different devices currently do different things
> than what this doc recommends.

I'm happy to go either way, so long as folks agree.  If we can't agree to a
set of procedures, then there's not much value in publishing even an
informational document.
 
> 0) You might want to consider specifying what the To/From-URIs should
> be sent as, and that a receiver should be lenient.  We've seen interop
> problems with those URIs for OPTIONS pings.

I wanted to be rather strict in saying that only sip:192.168.4.56 was
acceptable, for example, but others I consulted with thought that was too
restrictive.  So, the language is soft here.

What is the preference of the group on this?
 
> 1) Section 6 says: "When a receiving SIP entity is unable to process
> SIP messages, it SHOULD respond with a 503 response code."  Clearly you
> can't mean that literally, since OPTIONS is a SIP message and
> responding to it would require processing it. :)  But you presumably
> also don't mean when the entity is too busy, because you recommend
> using 486 for that case.  So what is this intended to mean?  Unable to
> process new dialogs?

We chose 503 because that is what section 21.5.4 of RFC 3261 says to return.
So, yeah, we meant that ;-)  Perhaps "unable" is the word that needs
changing, but that was also the word used in 3261.  What would be better?

> 2) Section 6 says: "A SIP entity MUST respond to an OPTIONS method with
> a 200 response code when it is willing and able to process SIP
> messages."  Again, this can't be meant literally, because two
> paragraphs later a 486 is indicated when it is experiencing heavy load
> but still willing to accept new dialogs.  Maybe just a "...unless one
> of the following cases apply" needs to be added at the end of the
> sentence.  BTW, do you really mean "SIP messages", or do you mean out-
> of-dialog requests other than OPTIONS, or only dialog-forming requests?

Good point.  I'll adjust the sentence to add a condition as you suggest.  We
did mean "SIP messages" since the purpose is to determine, not whether the
peer device is able to process the OPTIONS, but whether it is willing and
able to process any SIP message.  How to put that in words?  Anyway, if the
peer device is out of service, we want OPTIONS to tell us that before we
waste time trying to send an INVITE.
 
> Do you mean it must honor the Retry-After such that it does not send
> the OPTIONS ping based on it?  Or do you only mean it has to honor the
> Retry-After for other request types?  Also, it's a nit, but the
> sentence should be "...honor the Retry-After header field value
> received in the previous response."

I added the nit clause to the draft :-)

As for the meaning, I'm confused with your question.  The intent is to obey
the Retry-After header.  If the reply to the OPTIONS has a Retry-After
header, then don't send another OPTIONS until that time expires.

> 4) Section 5.1 says: "The OPTIONS message MUST be transmitted directly
> to the peer's IP address and not to an intermediary SIP entity."  What
> do you mean by "intermediary SIP entity"?  Either it is the next-hop,
> or it's not.  If your next-hop is X, send it to X.  If to get to your
> "peer" you have to use a proxy, then that proxy *is* your next-hop, and
> *is* your "peer".  Bypassing it won't help you in the general case. (in
> some specific cases, sure, but not generally; and in some cases it
> makes things worse, so it can't be a MUST)

This sentence is only to reinforce what you're saying (I think).  One should
not use these procedures to do a "ping" between A and C by addressing the
message to C, but then transmitting it to a proxy B to forward to C.

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Apr 2010 06:59:33 +0200

Hi, 
 
>That document covers a different problem that's not related to an application "ping" between two devices.  One could view it as such for active sessions, I suppose, but it really has a different focus.

That is not true.

If you negotiate the keep-alive as part of the registration procedure, the "pings" will be sent during the duration of the registration - no matter whether you have active sessions or not.

Now, that of course only applies to nodes that are involved in registration, and the keep draft currently says that keep alives negotiated during session setup are only valid for that session. However, I think that at some point there was a comment that it should also be allowed to negotiate to longer keep-alive durations during the session setup, for proxy-to-proxy "pings" etc. I guess we'll get back to that discussion once we get the keep discussion up again (next week, according to my plans).

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Sun, 4 Apr 2010 07:22:45 -0700

> As for the meaning, I'm confused with your question.  
> The intent is to obey the Retry-After header.  If the 
> reply to the OPTIONS has a Retry-After header, then 
> don't send another OPTIONS until that time expires.

Your response is appropriate for responses like 486 and 500 with Retry-After; however a 503 with Retry-After applies to more than OPTIONS.  Per RFC 3261 section 21.5.4, it means you SHOULD NOT send any requests (INVITE, BYE, ACK, CANCEL, REGISTER, ...) during that interval.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Apr 2010 08:51:48 -0400

[as an individual]

> restrictive.  So, the language is soft here.

I believe I was one of the "others".

My personal concern was that making such a mandate starts to interfere 
with the layering of the sip stack. If you "know" your neighbors via DNS 
names, then the translation to ip addresses occurs in the code that 
implements 3263, which is way below where you construct, send, and 
receive responses to messages.

I didn't want to see a set of recommendations that require violation of 
such layering.

But I'd be interested in hearing other points of view on this.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Apr 2010 17:31:50 -0400

One problem I've seen is when something like a UA or IP-PBX is OPTIONS pinging "sip:sip.ssp.com" - that will resolve in DNS to an ingress proxy, which actually is the real target of the ping request - but the ingress proxy itself may think the OPTIONS needs to get routed to the authoritative server for sip.ssp.com, which may well be something _after_ the proxy.  

Setting max-forwards to 1 helps avoid that, but in some proxies that will get back a 483 too many hops, which is actually ok in my book - after all you know its alive and processing requests - but in some devices that increments error counters which people don't like.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, April 05, 2010 8:52 AM
> To: Paul E. Jones
> Cc: Hadriel Kaplan; [email-masked]; 'Vivek Bhargava (vbharga)'; 'Gonzalo
> Salgueiro'
> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt
> 
> [as an individual]
> 
> Paul E. Jones wrote:
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 10 Apr 2010 20:00:01 -0400

Christer,

> If you negotiate the keep-alive as part of the registration procedure,
> the "pings" will be sent during the duration of the registration - no
> matter whether you have active sessions or not.

True, but this draft is not focused on places where a REGISTER message is
sent between a UA and a Registrar.  Rather, the draft is focused on places
where a REGISTER is not likely used, such as between two peer SBCs.

> Now, that of course only applies to nodes that are involved in
> registration, and the keep draft currently says that keep alives
> negotiated during session setup are only valid for that session.
> However, I think that at some point there was a comment that it should
> also be allowed to negotiate to longer keep-alive durations during the
> session setup, for proxy-to-proxy "pings" etc. I guess we'll get back
> to that discussion once we get the keep discussion up again (next week,
> according to my plans).

We also need a solution for when there are no active sessions and haven't
been for hours, for example.  OPTIONS "pings" have been serving this role
for a while.  OPTIONS "pings" can also be used by diagnostic equipment to
alert admins that a device is down. 

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 10 Apr 2010 20:03:35 -0400

Brett,

I guess I'm still a bit confused.  What in this draft violates the rule?  I
think we're in agreement here, but apparently the text of the draft isn't
quite as clear as it ought to be, I guess.

Paul

> From: Brett Tate [mailto:[email-masked]]
> Sent: Sunday, April 04, 2010 10:23 AM
> To: Paul E. Jones; [email-masked]
> Cc: 'Hadriel Kaplan'
> Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-
> 00.txt
> 
> Your response is appropriate for responses like 486 and 500 with Retry-
> After; however a 503 with Retry-After applies to more than OPTIONS.
> Per RFC 3261 section 21.5.4, it means you SHOULD NOT send any requests
> (INVITE, BYE, ACK, CANCEL, REGISTER, ...) during that interval.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 10 Apr 2010 20:15:41 -0400

Hadriel,

Yeah, I think that's OK, too.  And, it's one reason for recommending setting
the Max-Forwards header.  These procedures really are intended for use
between two devices that have some kind of established relationship.  I
would not expect them to be used between any two devices on the Internet,
nor would I expect all devices to support an OPTIONS "ping".  We might see
service providers require this support at peer interconnection points or
perhaps between an enterprise or service provider.  We might also see this
kind of support required inside an enterprise or carrier network for
monitoring purposes.  But, such requirements would be explicit,
manufacturers would build accordingly, and things should work.  What we
need, I think, are the basic guidelines to help ensure (what I've
unfortunately seen) where all kinds of different response codes more-or-less
equate to a 503.

Paul

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Monday, April 05, 2010 5:32 PM
> To: Paul Kyzivat; Paul E. Jones
> Cc: [email-masked]; 'Vivek Bhargava (vbharga)'; 'Gonzalo Salgueiro'
> One problem I've seen is when something like a UA or IP-PBX is OPTIONS
> pinging "sip:sip.ssp.com" - that will resolve in DNS to an ingress
> proxy, which actually is the real target of the ping request - but the
> ingress proxy itself may think the OPTIONS needs to get routed to the
> authoritative server for sip.ssp.com, which may well be something
> _after_ the proxy.
> 
> Setting max-forwards to 1 helps avoid that, but in some proxies that
> will get back a 483 too many hops, which is actually ok in my book -
> after all you know its alive and processing requests - but in some
> devices that increments error counters which people don't like.
> 
> -hadriel
> 
> 
> > > acceptable, for example, but others I consulted with thought that
> was
> > too

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 22:52:00 -0400

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Saturday, April 10, 2010 8:00 PM
> 
> been for hours, for example.  

It was my impression draft-sip-core-keep was also supposed to support that.  I agree that its current wording is wrong, imo, but when it started out my impression was it could be used for permanent proxy-to-proxy (or b2bua-to-b2bua, etc.) connections/associations, regardless of there being an active dialog between the two.  Without that I agree with you that it's not as useful.

> OPTIONS "pings" have been serving this role

The draft-keep does that (detect device failure), but what it doesn't do is tell you when it's getting too busy.  I liked it over OPTIONS-pings because draft-keep's a lot lighter-weight/more-efficient, trivial to implement, explicit in its purpose, and unavoidably single-hop.  In other words it would *replace* OPTIONS pings.  But if we go fix OPTIONS-pings, would we need draft-keep anymore?  Would people implement it?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 23:13:30 -0400

Hi Paul,
Inline...

> Sent: Saturday, April 10, 2010 8:16 PM
> 
> nor would I expect all devices to support an OPTIONS "ping".  

I'm not sure what comment I made elicited the second sentence.  You mean my concern for error logs due to max-forwards=1?  I.e., you're saying that since these devices "know" they're doing it, they shouldn't log errors?  Sure.  But it's kinda hard to know the OPTIONS is for ping and not just some other OPTIONS that happens to have looped around enough to get down to a Max-Forwards of 1. 

That's one of the reasons it would be nice if the OPTIONS actually had some way to say "I'm a ping".  For example, my company's systems set the To/From username to "ping" (e.g., "sip:[email-masked]") by default.

> We might see
> perhaps between an enterprise or service provider.  

That's already the case.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Apr 2010 23:16:16 -0400

Hi Paul,

I suppose there's no real point in arguing over the nitty-gritty details right now.  Let's assume whatever this turns out to be isn't 100% backwards-compatible with your or some people's implementations of OPTIONS-pings, and thus requires code changes for some or even many folks.  The big question in my mind is: should we do this, or should we do draft-keep?

-hadriel

> These procedures really are intended for use

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Apr 2010 14:05:30 +0200

Hi,

Keep in mind that the keep-draft does not define a keep-alive/ping mechanism - it defines a mechanism to negotiate the mechanism already defined in Outbound.

Now, the keep-draft also supports negotiation of "keep-alives" between proxies, where the "keep-alive" is more likely to be used as a ping, so I guess your question is whether you want to replace THAT part with options-ping? 

Or, are you also saying that we should do NAT keep-alives using options-ping??? I really hope not... :)

Regards,

Christer
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
Sent: Sunday, April 11, 2010 6:16 AM
To: Paul E. Jones; 'Paul Kyzivat'
Cc: 'Vivek Bhargava (vbharga)'; [email-masked]; 'Gonzalo Salgueiro'
Subject: [sipcore] Options-ping vs. Draft-keep (was draft-jones-sip-options-ping-00.txt)

Hi Paul,

-hadriel

> unfortunately seen) where all kinds of different response codes more-or-
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brett Tate <[email-masked]>
Date: Sun, 11 Apr 2010 06:03:26 -0700

> What in this draft violates the rule?

The draft is currently upgrading rfc3261's honoring Retry-After requirements from MAY (MAY NOT) and SHOULD (SHOULD NOT) levels to MUST (MUST NOT) levels.  Thus it is preventing the UAC from making appropriate/configurable decisions concerning if/how it is willing to honor/apply the reception of 503 with Retry-After.

For instance, the draft doesn't allow UAC to reduce the honoring of 503 with Retry-After value of 1 year to only apply for 30 seconds.

For instance, the draft doesn't allow UAC to avoid applying the 503 with Retry-After value to sending requests associated with emergency calls.

For instance, the draft doesn't allow UAC to avoid applying the 503 with Retry-After to sending requests within dialog.

For instance, the draft doesn't allow UAC to avoid honoring a 503 with Retry-After when response source ip-address is not equivalent to where the request was sent.  Concerning their not matching, the draft currently does not mention it from a security risk or otherwise.

For instance, the draft doesn't allow UAC to only apply the 503 with Retry-After to specific interfaces.  More specifically if a UAC knows it should not trust/honor the 503 Retry-After value (because of a proxy rfc3261/draft non compliance or an insecure interface), the draft doesn't allow the device to instead not honor the 503 with Retry-After.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Apr 2010 11:02:41 -0400

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Sunday, April 11, 2010 8:06 AM
> To: Hadriel Kaplan; Paul E. Jones; 'Paul Kyzivat'
> 
> Keep in mind that the keep-draft does not define a keep-alive/ping
> mechanism - it defines a mechanism to negotiate the mechanism already
> defined in Outbound.
> 
> Now, the keep-draft also supports negotiation of "keep-alives" between
> proxies, where the "keep-alive" is more likely to be used as a ping, so I
> guess your question is whether you want to replace THAT part with options-
> ping?

Right, I'm questioning if we need to standardize a way to negotiate "keep-alives" between proxies, if we decide to go and fix OPTIONS-pings.  

Today OPTIONS-pings are already used as keep-alives between proxies, but they have interop and operational issues.  I had assumed that draft-keep would help us avoid those issues, and would be the "standard" way to do it.

It doesn't make much sense to run *both* between proxies, for example. I don't think having two ways to solve the same problems is a good idea.

I don't much care which one it is - I think the stun/crlf method is better from a technical perspective, but OPTIONS would probably get wider adoption faster.

> ping??? I really hope not... :)

Definitely not. :)

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 11 Apr 2010 17:31:28 -0400

> I'm not sure what comment I made elicited the second sentence.  You
> mean my concern for error logs due to max-forwards=1?  I.e., you're
> saying that since these devices "know" they're doing it, they shouldn't
> log errors?  

Oh, it was nothing you said.  I'm just adding more commentary :)

> Sure.  But it's kinda hard to know the OPTIONS is for ping
> and not just some other OPTIONS that happens to have looped around
> enough to get down to a Max-Forwards of 1.

I would expect it to know that it's an options ping based on the address to
which it is directed.  For example, sip:192.168.2.34 would suggest it's
destined for the particular device.  Perhaps one might also use
sip:[email-masked] for this purpose.  I think each box that supports an
options ping ought to have a defined ping "address", with the IP address of
the machine serving as a reasonable default.  (That might not make sense for
IP phones, but I think it makes sense for B2BUAs.)
 
> That's one of the reasons it would be nice if the OPTIONS actually had
> some way to say "I'm a ping".  For example, my company's systems set
> the To/From username to "ping" (e.g., "sip:[email-masked]") by default.

And I'd say that's reasonable to do.
 
> > perhaps between an enterprise or service provider.

Indeed :)  And, that's why I thought it would be reasonable to put this
draft out there.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 11 Apr 2010 17:44:54 -0400

Brett,

So, I think the only change we need in the draft is to change the word
"MUST" to "SHOULD" in the paragraph just before Section 8?

Paul

> Sent: Sunday, April 11, 2010 9:03 AM
> The draft is currently upgrading rfc3261's honoring Retry-After
> requirements from MAY (MAY NOT) and SHOULD (SHOULD NOT) levels to MUST
> (MUST NOT) levels.  Thus it is preventing the UAC from making
> appropriate/configurable decisions concerning if/how it is willing to
> honor/apply the reception of 503 with Retry-After.
> 
> For instance, the draft doesn't allow UAC to reduce the honoring of 503
> with Retry-After value of 1 year to only apply for 30 seconds.
> 
> For instance, the draft doesn't allow UAC to avoid applying the 503
> with Retry-After value to sending requests associated with emergency
> calls.
> 
> For instance, the draft doesn't allow UAC to avoid applying the 503
> with Retry-After to sending requests within dialog.
> 
> For instance, the draft doesn't allow UAC to avoid honoring a 503 with
> Retry-After when response source ip-address is not equivalent to where
> the request was sent.  Concerning their not matching, the draft
> currently does not mention it from a security risk or otherwise.
> 
> For instance, the draft doesn't allow UAC to only apply the 503 with
> Retry-After to specific interfaces.  More specifically if a UAC knows
> it should not trust/honor the 503 Retry-After value (because of a proxy
> rfc3261/draft non compliance or an insecure interface), the draft
> doesn't allow the device to instead not honor the 503 with Retry-After.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Apr 2010 18:21:45 -0400

Oh wait, I totally misunderstood what you were saying.  You're saying "draft-keep is just a negotiation mechanism, so it could negotiate to use options-pings".

Right, so what's the value in that?  We needed an indication of support for stun/crlf, because there was no way to indicate it between two proxies - except of course them sending an OPTIONS to each other. :)

I guess in my mind the main use-case for draft-keep was for inter-proxy (or inter-b2bua/etc.) on a permanent basis, and I was trying to avoid yet one more set of things to be configured/provisioned/get-wrong on systems.  

So I was thinking "Great, let's do this simple indication on the wire, and if the next-hop does it I'll use the stun/crlf which is better anyway, otherwise I'll use OPTIONS pings and hope for the best".

As an example, my system has half a dozen configurable settings for OPTIONS-pings, on a per next-hop basis, just to get it to work right with different vendors. :(  

I'd like the next setting to be the Staples "Easy" button. :)

-hadriel

> Of Hadriel Kaplan
> Sent: Sunday, April 11, 2010 11:03 AM
> 
> Right, I'm questioning if we need to standardize a way to negotiate "keep-
> alives" between proxies, if we decide to go and fix OPTIONS-pings.
> 
> Today OPTIONS-pings are already used as keep-alives between proxies, but
> they have interop and operational issues.  I had assumed that draft-keep
> would help us avoid those issues, and would be the "standard" way to do it.
> 
> It doesn't make much sense to run *both* between proxies, for example. I
> don't think having two ways to solve the same problems is a good idea.
> 
> I don't much care which one it is - I think the stun/crlf method is better
> from a technical perspective, but OPTIONS would probably get wider
> adoption faster.
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Apr 2010 09:24:32 +0200

Hi, 

>Oh wait, I totally misunderstood what you were saying.  
>You're saying "draft-keep is just a negotiation mechanism, so 
>it could negotiate to use options-pings".

That is not what I am saying :)

I am saying that the draft is used to negotiate the mechanism defined in Outbound.

>Right, so what's the value in that?  We needed an indication 
>of support for stun/crlf, because there was no way to 
>indicate it between two proxies - except of course them 
>sending an OPTIONS to each other. :)

That is what the keep-draft provides.

>I guess in my mind the main use-case for draft-keep was for 
>inter-proxy (or inter-b2bua/etc.) on a permanent basis, and I 
>was trying to avoid yet one more set of things to be 
>configured/provisioned/get-wrong on systems.  

Permanent proxy-to-proxy was not the main use-case of the keep-draft (at least not initially). The main use-cases were UA-to-proxy, to:

1. Allow negotiation of keep-alives during registration without having to support Outbound; and
2. Allow negotiation of keep-alives during session establishment

The inter-proxy was added later, since there were requests to do so.

The question is now whether we should REMOVE the inter-proxy case from the keep-draft all together, and ONLY use options-ping instead.

>So I was thinking "Great, let's do this simple indication on 
>the wire, and if the next-hop does it I'll use the stun/crlf 
>which is better anyway, otherwise I'll use OPTIONS pings and 
>hope for the best".

Yes.

Regards,

Christer

>As an example, my system has half a dozen configurable 
>settings for OPTIONS-pings, on a per next-hop basis, just to 
>get it to work right with different vendors. :(  
> 

> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Hadriel Kaplan
> > > mechanism - it defines a mechanism to negotiate the mechanism 
> > > already defined in Outbound.
> > >
> > > Now, the keep-draft also supports negotiation of "keep-alives" 
> > > between proxies, where the "keep-alive" is more likely to 
> be used as 
> > > a ping, so
> > I
> > Right, I'm questioning if we need to standardize a way to negotiate 
> > "keep- alives" between proxies, if we decide to go and fix 
> OPTIONS-pings.
> > 
> > Today OPTIONS-pings are already used as keep-alives between 
> proxies, 
> > but they have interop and operational issues.  I had assumed that 
> > draft-keep would help us avoid those issues, and would be 
> the "standard" way to do it.
> > 
> > It doesn't make much sense to run *both* between proxies, 
> for example. 
> > I don't think having two ways to solve the same problems is 
> a good idea.
> > 
> > I don't much care which one it is - I think the stun/crlf method is 
> > better from a technical perspective, but OPTIONS would probably get 
> > wider adoption faster.
> > 
> > 
> > > Or, are you also saying that we should do NAT keep-alives using 
> > > options- ping??? I really hope not... :)
> > 
> > Definitely not. :)
> > 
> > -hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 09:59:25 -0400

[as individual]

> "MUST" to "SHOULD" in the paragraph just before Section 8?

Let me just interject here that in the past we have frequently gotten 
into trouble by using SHOULD without qualification of what constitutes a 
valid reason for going against the SHOULD. Without actual text that 
clarifies that, SHOULD is often treated as if it said "you can claim 
conformance without implementing this."

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 12 Apr 2010 10:13:04 -0400

Paul,

> conformance without implementing this."

I think that's OK here, since what Brett was suggesting was that it is
already a SHOULD in effect in 3261.  In any case, the worst thing that
happens here is that a device ignores the Retry-After header and claims
compliance.  Apparently, some feel there are plenty of good reasons to do
so.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 10:17:02 -0400

Paul,

> unfortunately seen) where all kinds of different response codes more-or-less

I don't understand how you envision this working.
Would you expect that in those places where this mechanism is to be used 
that the policy to do so will be explicitly configured mutually on both 
of the peers, and that support for this draft would then be required of 
both?

(As opposed to a situation where a particular device just has a policy 
of using this mechanism with all peers that meet some generic criterion 
for their role, and that are discovered to support the mechanism.)

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 12 Apr 2010 10:35:00 -0400

Paul,
 
> of the peers, and that support for this draft would then be required of

That is my expectation.  It's not really different from today, except today
we have a variety of OPTIONS "ping" approaches and I'd like to narrow those
down to one, if possible.
 
Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 11:15:05 -0400

> compliance.  Apparently, some feel there are plenty of good reasons to do

I don't think that lets you off the hook.
We've learned from experience that we were too vague in the past.
So I would expect you to be less vague here - being more explicit about 
what conditions justify violating the SHOULD.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 12:22:04 -0400

> Of Paul Kyzivat

And really using "MUST..., unless..." instead.

-hadriel

---

From: Brett Tate <[email-masked]>
Date: Mon, 12 Apr 2010 10:10:31 -0700

> > We've learned from experience that we were too vague in 
> > the past.  So I would expect you to be less vague here - 
> > being more explicit about what conditions justify violating 
> > the SHOULD.
> 

Is making 503 with Retry-After usable (i.e. so it does more good than harm) something that should be done within this draft and in this working group?  Or is that something that should be addressed within the hopefully dispatched overload working group?

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 12 Apr 2010 19:47:47 +0200

> Is making 503 with Retry-After usable (i.e. so it does more good than harm) something that should be done within this draft and in this working group?  Or is that something that should be addressed…

Since, to some extent, the 503 + Retry-after mechanism represents an
on/off overload control approach (w/ some known problems [1]), IMHO it
deserves special attention within the so-expected overload control WG.

[1] http://tools.ietf.org/html/rfc5390#section-5

Cheers,
-- 
Victor Pascual Ávila

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 20:24:41 -0400

> Is making 503 with Retry-After usable (i.e. so it does more good than harm) something that should be done within this draft and in this working group?  Or is that something that should be addressed…

Well, now you ask the hard questions.

With my chair hat on, IMO any changes to the behavior of 503 will at 
least need to be blessed by sipcore. (But I'm new as a sipcore chair, so 
I'm willing to learn from the other chair or the AD that is isn't so.)

After that, I think it depends on what is to happen with this draft.

If it is intended to be informational, then it can't make any normative 
changes. It can make any recommendations it wants as long as they don't 
require violating normative behavior.

If its aspirations are higher, and maybe even if they aren't, then I 
think it makes sense to coordinate it with the work of the overload wg.
(AFAIK we don't yet *have* an overload WG, but there is a mailing list, 
and I gather its expected that we will have the WG before long.)

With my individual hat on I will recommend that it go there for some 
discussion of if/how it relates.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Apr 2010 07:49:48 +0200

Hi,

I agree with Paul.

I think that we should try to have a generic procedure, where we in the case of SHOULD describe when something does not apply. Otherwise it's useless when it comes to writing test specifications etc.

Regards,

Christer 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 12. huhtikuuta 2010 16:59
> To: Paul E. Jones
> Cc: [email-masked]
> Subject: Re: [sipcore] FW: I-D 
> Action:draft-jones-sip-options-ping-00.txt
> 
> [as individual]
> 
> Paul E. Jones wrote:
> > Brett,
> > 
> Let me just interject here that in the past we have 
> frequently gotten into trouble by using SHOULD without 
> qualification of what constitutes a valid reason for going 
> against the SHOULD. Without actual text that clarifies that, 
> SHOULD is often treated as if it said "you can claim 
> >> requirements from MAY (MAY NOT) and SHOULD (SHOULD NOT) levels to 
> >> MUST (MUST NOT) levels.  Thus it is preventing the UAC from making 
> >> For instance, the draft doesn't allow UAC to reduce the 
> honoring of 
> >> 503 with Retry-After value of 1 year to only apply for 30 seconds.
> >>
> >> For instance, the draft doesn't allow UAC to avoid honoring a 503 
> >> with Retry-After when response source ip-address is not 
> equivalent to 
> >> where the request was sent.  Concerning their not 
> matching, the draft 
> >> it should not trust/honor the 503 Retry-After value (because of a 
> >> proxy rfc3261/draft non compliance or an insecure interface), the 
> >> draft doesn't allow the device to instead not honor the 
> 503 with Retry-After.
> >>
> > 
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 15 Apr 2010 01:25:40 -0400

> what conditions justify violating the SHOULD.

Shall I put it back to MUST?  Keep in mind, we're not trying to re-define
RFC 3261.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 15 Apr 2010 02:25:17 -0400

Paul, Brett,

I looked at the OPTIONS ping draft and 3261 again.  Perhaps I'm missing it
and need to be reminded (and I note it's 2AM here), but what in the OPTIONS
draft changes anything stated in 3261.  The statement of concern is this,
right?

   To avoid unduly taxing a receiving SIP entity, transmitters of
   OPTIONS messages MUST honor the Retry-After header field if
   received.

When a 503 is used is in line with 3261: we're not suggesting new
opportunities to send one. We're just saying that code should be used vs.
other codes that don't have the same meaning.

And, Retry-After should be honored.  We say MUST, which I understand is a
stronger word than SHOULD (and why I'm willing to soften it).  Changing it
to SHOULD would be in stronger agreement with 21.5.4 of 3261.

A device would not send 503 with Retry-After lightly, nor are we proposing a
change as to when a 503 is sent.  So, is using "SHOULD" acceptable? Or is
this really a problem?  I understand the problems one can get into with the
current wording in 3261, but what I'm failing to see, I guess, is how the
OPTIONS ping draft makes this worse.

Paul

> Sent: Monday, April 12, 2010 8:25 PM
> To: Brett Tate
> Cc: Hadriel Kaplan; Paul E. Jones; [email-masked]
> > Is making 503 with Retry-After usable (i.e. so it does more good than
> harm) something that should be done within this draft and in this
> working group?  Or is that something that should be addressed within
> the hopefully dispatched overload working group?
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Apr 2010 08:51:34 -0400

I'm ok with the SHOULD since that is what is in 3261. What I would 
prefer to see is some enumeration of the cases when its appropriate to 
violate the SHOULD.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Apr 2010 09:41:51 -0400

> OPTIONS ping draft makes this worse.

Let me see if I fully understand your intent here.
If you said nothing about this, and the result of an OPTIONS ping was a 
503 with a Retry-After, then the recipient would be bound by 3261, which 
says:

    A client ... receiving a 503 ... SHOULD NOT
    forward any other requests to that server for the duration specified
    in the Retry-After header field, if present.

Is the intent of the MUST in your draft to strengthen that SHOULD NOT in 
3261 to MUST NOT for those devices that claim conformance to your draft?

If that is the case, then I think it is ok as long as this draft itself 
becomes normative, or a BCP. (I have to check the rules for BCPs - I'm 
not certain if they can have normative statements of their own.) I'm 
pretty sure this would be inappropriate in an informative draft, though 
some non-normative language with the same intent should be ok.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Apr 2010 18:03:49 +0200

Hi,

>prefer to see is some enumeration of the cases when its appropriate to

If it is a reference to 3261 it would be good to say:

"As specified in RFC 3261, blah blah blah..."

Regards,

Christer

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 15 Apr 2010 19:42:06 -0400

------- Original message -------
> From: Paul Kyzivat <[email-masked]>
>
> becomes normative, or a BCP. (I have to check the rules for BCPs - I'm not 
> certain if they can have normative statements of their own.) I'm pretty 
> sure this would be inappropriate in an informative draft, though some 
> non-normative language with the same intent should be ok.

BCP can use 2119 language, but is for documenting practices for which we 
have in-the-field experience, so it doesn't really apply here.

An informative or experimental draft can use such language, but has to lay 
out the conditions of "what happens if" and explain "why" in a very high 
level of detail. Remember: 2119 is about requirements, and naked 
requirements are weaker than naked emperors. They need to be well-dressed 
in explanation to be respected.

That said, if there is adequate justification to change the language of RFC 
3261, then we should probably just change it, and that means a 
standards-track draft.

--
Dean

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 15 Apr 2010 20:34:22 -0400

Capturing everyone's comments, I changed the paragraph as follows:

   If a requesting entity fails to receive a response to an
   OPTIONS message, it MAY retransmit that message following
   the procedures defined in RFC 3261.  If a requesting entity
   receives a 486 or 503 response code, it MAY send a subsequent
   OPTIONS messages in order to detect a change in operational
   status, but it SHOULD, as per RFC 3261, honor the Retry-After
   header field received in the previous response.

Pail
> Sent: Thursday, April 15, 2010 12:04 PM

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Apr 2010 13:37:24 +0200

Being pedantic, I would note that the second "MAY" (as in "it MAY send a subsequent OPTIONS messages") can apparently be replaced with "can" as all this sentence is doing is the possibility of repeating the option expressed by the "MAY" in the first sentence. It is not expressing a new requirement.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Paul E. Jones
> Sent: Friday, April 16, 2010 1:34 AM
> To: 'Christer Holmberg'; 'Paul Kyzivat'
> Cc: [email-masked]
> > >prefer to see is some enumeration of the cases when its 
> appropriate 
> > >to violate the SHOULD.
> > 
> > >> I think that's OK here, since what Brett was suggesting 
> was that it 
> > >> is
> > >>> already a SHOULD in effect in 3261.  In any case, the 
> worst thing
> > >> that
> > >>> compliance.  Apparently, some feel there are plenty of good 
> > >>> reasons
> > >> to do
> > >>> so.
> > > Shall I put it back to MUST?  Keep in mind, we're not 
> trying to re-
> > define
> > > RFC 3261.
> > >
> > > Paul
> > >
> > >
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Apr 2010 09:28:39 -0400

Dean Willis wrote:
>> Is the intent of the MUST in your draft to strengthen that SHOULD NOT 
>> in 3261 to MUST NOT for those devices that claim conformance to your 
>> draft?
>>
>> If that is the case, then I think it is ok as long as this draft 
>> itself becomes normative, or a BCP. (I have to check the rules for 
>> BCPs - I'm not certain if they can have normative statements of their 
>> own.) I'm pretty sure this would be inappropriate in an informative 
>> draft, though some non-normative language with the same intent should 
>> be ok.
> 

If I understand Paul Jones's intent, I think that does apply.
I think he is suggesting this behavior just for those following the 
practices he is proposing.

> An informative or experimental draft can use such language, but has to 
> lay out the conditions of "what happens if" and explain "why" in a very 
> high level of detail. Remember: 2119 is about requirements, and naked 
> requirements are weaker than naked emperors. They need to be 
> well-dressed in explanation to be respected.
> 
> That said, if there is adequate justification to change the language of 
> RFC 3261, then we should probably just change it, and that means a 
> standards-track draft.

I don't think we would change the SHOULD NOT to MUST NOT in 3261. But it 
would be helpful to change it to SHOULD NOT, with exception for the 
following cases: ...

But that is a different thing than what Paul J is trying to achieve.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Apr 2010 09:30:59 -0400

All of this (Paul's revision and Keith's tweak) all work for me.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Apr 2010 11:25:54 -0400

> Sent: Thursday, April 15, 2010 9:42 AM
> To: Paul E. Jones
> 

Afaik you can keep the language even in an Informational.  At least 2119 and 2026 don't say otherwise, and there are existing published Informational's which use the word MUST. 

The real question is if you SHOULD or SHOULD NOT have this Retry-After statement to begin with. ;)

If your goal is interoperability from the customer's perspective, then I think explicitly specifying what the Retry-After really does/means *is* important.  Unfortunately, if you specify that it means no subsequent requests (other than OPTIONS) are sent, some of us will have to submit another Informational which contradicts this one because for a lot of customers it's the wrong behavior. 

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 16 Apr 2010 18:08:07 -0400

Ok.. done.

Paul

> Behalf Of DRAGE, Keith (Keith)
> Sent: Friday, April 16, 2010 7:37 AM
> To: Paul E. Jones; 'Christer Holmberg'; 'Paul Kyzivat'
> Cc: [email-masked]
> Being pedantic, I would note that the second "MAY" (as in "it MAY send
> a subsequent OPTIONS messages") can apparently be replaced with "can"
> as all this sentence is doing is the possibility of repeating the
> option expressed by the "MAY" in the first sentence. It is not
> expressing a new requirement.
> 
> regards
> 
> Keith
> 
> > > >>> happens here is that a device ignores the Retry-After header
> and
> > > >> claims
> > > >> So I would expect you to be less vague here - being more
> explicit
> > > about

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 17 Apr 2010 17:12:21 -0400

Hadriel,
 
> statement to begin with. ;)

I think we should at least have SHOULD here, since that's consistent with
3261.
 
> If your goal is interoperability from the customer's perspective, then
> I think explicitly specifying what the Retry-After really does/means
> *is* important.  Unfortunately, if you specify that it means no
> subsequent requests (other than OPTIONS) are sent, some of us will have
> to submit another Informational which contradicts this one because for
> a lot of customers it's the wrong behavior.

I don't want this document to change the rules as defined in 3261, unless we
want to also change 3261 in the process.

All we were hoping to do with the draft is to take a practice that is
common, but not consistently implemented, legitimize it, and specify what
devices should do.

In the process, I don't want to create contradictory statements about that
client/server interactions should be.  I do want to encourage a client to
observe a Retry-After header if it gets it, but I do not want to mandate
that servers send that header nor do I want to change anything about the
processing rules as specified in 3261.

Given that these are widely implemented by a variety of devices, I'd
personally like to see this put forward as a Standards Track RFC.  We're not
trying to define procedures to keep firewall pinholes open nor define a way
to manage server overload with this: it has a very limit, but useful scope.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Apr 2010 21:50:15 -0400

> Sent: Saturday, April 17, 2010 5:12 PM
> 

It's not - 3261 says "SHOULD NOT", not "MUST NOT".  Per RFC 2119, it means:
4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.
 
So your draft can simply be an Informational document, describing such circumstances.  :)

> common, but not consistently implemented, legitimize it, and specify what

Right, and I think it's bad form to recommend something that is knowingly a bad idea in certain, common circumstances.

If in most circumstances people have to configure systems to NOT follow this draft's recommendations, then what good is the draft??  Isn't it in fact harmful?

> to manage server overload with this: it has a very limit, but useful scope.

My concern isn't about keeping firewall pinholes open.  My concern is that if a server becomes overloaded and sends a 503, that not only causes a complete swing to 0% utilization, but more importantly the BYE's don't get sent.  Likewise, some people use it for admin-down state, to take a server out of service gracefully - and thus still expect in-dialog requests.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 17 Apr 2010 22:12:52 -0400

Hadriel,

> > I don't want this document to change the rules as defined in 3261,
> unless
> > we

The sentence in question in my draft is does not have NOT in it.  It is
this:
"... it can send a subsequent OPTIONS messages in order to detect a change
in operational status, but it SHOULD, as per RFC 3261, honor the Retry-After
header field received in the previous response."
(The above was revised as per list discussion.)

> So your draft can simply be an Informational document, describing such

We could do that, though I think it would be better to make it standards
track in order to encourage consistent behavior and to legitimize a practice
that is in wide use.
 
> Right, and I think it's bad form to recommend something that is
> knowingly a bad idea in certain, common circumstances.

What recommendation is in the draft that's "bad"?  Anything can be bad in
some circumstances, but I don't think an OPTIONS "ping" is a bad idea.

> If in most circumstances people have to configure systems to NOT follow
> this draft's recommendations, then what good is the draft??  Isn't it
> in fact harmful?

Potentially, but that's why I want a set of procedures people can agree to.
 
> > personally like to see this put forward as a Standards Track RFC.
> We're
> > not
> > trying to define procedures to keep firewall pinholes open nor define
> a
> > way
> My concern isn't about keeping firewall pinholes open.  My concern is
> that if a server becomes overloaded and sends a 503, that not only
> causes a complete swing to 0% utilization, but more importantly the
> BYE's don't get sent.  Likewise, some people use it for admin-down
> state, to take a server out of service gracefully - and thus still
> expect in-dialog requests.

Understood, but we're not proposing that a server send that lightly.  It
should be done under the same circumstances as if it received an INVITE and
decided to send a 503.  Again, this draft is not trying to change the
behavior of 3261.  We're just trying to define a consistent usage of OPTIONS
as an application-level ping mechanism.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Apr 2010 22:27:37 -0400

> Sent: Saturday, April 17, 2010 10:13 PM
> 

Sorry, I should have been clearer - I meant the statement in section 21.5.4 of 3261 about not sending subsequent requests:
   A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   attempt to forward the request to an alternate server.  It SHOULD NOT
   forward any other requests to that server for the duration specified
   in the Retry-After header field, if present.

I thought that's what you and other were concerned about "changing" or "overriding".

> track in order to encourage consistent behavior and to legitimize a

Sure - I just thought you wanted to keep it Informational.

> some circumstances, but I don't think an OPTIONS "ping" is a bad idea.

I meant keeping with the 3261 language I noted above, if it's not qualified further.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 18 Apr 2010 16:54:14 -0400

Hadriel,

Ah, OK... I think we're on the same page, then.  The changes from the -00
draft to the current draft have been extremely minimal thus far.  You can
see the current change here:
http://hive.packetizer.com/users/paulej/internet-drafts/pre-draft-jones-sip-
options-ping-01.pdf

I believe I've reflected everyone's comments and, I hope, the text does not
suggest a different direction than what is specified in 3261.

Now the next question, what shall we do with this?  As I said, I think it
ought to be a WG document.  It is, after all, behavior that is widely
implemented, but not implemented consistently.  Further, 3261 does not
specify the usage of OPTIONS for a "ping", so it needs documenting.

Paul

> Sent: Saturday, April 17, 2010 10:28 PM
> Cc: 'Brett Tate'; [email-masked]
> > in operational status, but it SHOULD, as per RFC 3261, honor the
> Retry-
> > After
> Sorry, I should have been clearer - I meant the statement in section
> 21.5.4 of 3261 about not sending subsequent requests:
> > > So your draft can simply be an Informational document, describing
> such
> > > circumstances.  :)
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 18 Apr 2010 19:18:09 -0400

[as co-chair]

> specify the usage of OPTIONS for a "ping", so it needs documenting.

Well, we already had another proposal for work on OPTIONS, but have not 
yet decided whether the WG will take this up or not.

*This* work might be considered an aspect of that, or it might be 
considered and entirely separate thing. Either way we will need to see 
if there is enough interest from the WG to do this.

So far there has been considerable activity from two people, with a 
couple of others chiming in from time to time.

It would be easier to take this up if there were broader interest.
Or potentially we could pursue advancing it as an individual draft.

I'd like to hear from some other people on this. That would help us to 
understand the extent to which this is "best practice".

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 06:14:15 +0200

Hi, 

>>Now the next question, what shall we do with this?  As I said, I think 
>>it ought to be a WG document.  It is, after all, behavior that is 
>>widely implemented, but not implemented consistently.  Further, 3261 
>>does not specify the usage of OPTIONS for a "ping", so it needs documenting.
>
>Well, we already had another proposal for work on OPTIONS, but have not yet decided whether the WG will take this up or not.
>
>*This* work might be considered an aspect of that, or it might be considered and entirely separate thing. Either way we will need to see if there is enough interest from the WG to do this.
>
>So far there has been considerable activity from two people, with a couple of others chiming in from time to time.
>
>I'd like to hear from some other people on this. That would help us to understand the extent to which this is "best practice".

Note that we already have a previous decission to work on a proxy-to-proxy ping/heartbeat MECHANISM as such, using the keep-draft.

So, I think the question is whether we want to use the keep-draft, options-ping, or both to implement that mechanism.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2010 08:52:03 -0400

> So, I think the question is whether we want to use the keep-draft, options-ping, or both to implement that mechanism.

People can correct me if I'm wrong - my impression is that the *intent* 
of the keep stuff and the options ping stuff is different, at least in 
emphasis. I am thinking the focus of keep is on keeping nat pinholes 
open, while the focus of options ping is on determination of which 
neighbors are up/down.

But each may be suitable for the other purpose itself. So there is 
overlap, at least in the eyes of some.

And of course there is also some perceived overlap between detecting 
neighbors that are down and overload control.

So to an extent its a matter of whether to characterize this ping work 
as part of one of those other charters, or as something independent of 
them. What is your take on that?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 15:02:15 +0200

Hi, 

>>>>Now the next question, what shall we do with this?  As I said, I 
>>>>think it ought to be a WG document.  It is, after all, 
>>>>behavior that is widely implemented, but not implemented consistently.  
>>>>Further, 3261 does not specify the usage of OPTIONS for a "ping", 
>>>>so it needs documenting.
>>>Well, we already had another proposal for work on OPTIONS, 
>>>but have not yet decided whether the WG will take this up or not.
>>>
>>>*This* work might be considered an aspect of that, or it 
>>>might be considered and entirely separate thing. Either way 
>>>we will need to see if there is enough interest from the WG 
>>>to do this.
>>>
>>>So far there has been considerable activity from two 
>>>people, with a couple of others chiming in from time to time.
>>>
>>>I'd like to hear from some other people on this. That 
>>>would help us to understand the extent to which this is "best 
>>>practice".
>> 
>>Note that we already have a previous decission to work on a 
>>proxy-to-proxy ping/heartbeat MECHANISM as such, using the keep-draft.
>> 
>>So, I think the question is whether we want to use the 
>>keep-draft, options-ping, or both to implement that mechanism.
> 
>People can correct me if I'm wrong - my impression is that 
>the *intent* of the keep stuff and the options ping stuff is 
>different, at least in emphasis. I am thinking the focus of 
>keep is on keeping nat pinholes open, while the focus of 
>options ping is on determination of which neighbors are up/down.

It is correct that keeping nat pinholes open, between a UA and its edge proxy/registrar, is the main focus and scope of the document.

However, at some point I was asked to also cover proxy-to-proxy heartbeat in the document, and nobody objected.
 
>But each may be suitable for the other purpose itself. So 
>there is overlap, at least in the eyes of some.
> 
>And of course there is also some perceived overlap between 
>detecting neighbors that are down and overload control.
> 
>So to an extent its a matter of whether to characterize this 
>ping work as part of one of those other charters, or as 
>something independent of them. What is your take on that?

Personally I don't mind removing proxy-to-proxy hearbeat from the keep-draft - assuming we would adopt options-ping for that purpose. I do believe the functionality is needed.

And, as I said earlier, it seems like people want to have something persistant, not associated with a dialog, and if that is the case then options-ping would probably be better. 

So, it really depends on what people want between proxies. Something which is per dialog, or something which is more persistant - or both?

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 19 Apr 2010 12:47:35 -0400

Paul,
 
> open, while the focus of options ping is on determination of which

That's also my understanding.
 
> them. What is your take on that?

I fully agree that the OPTIONS "ping" can be viewed as overlapping with the
other two drafts.

As you know, it was not the intent of the "ping" mechanism to serve as an
overload mechanism, nor was it intended as a means of keeping pinholes open.

I think both the keep and overload work is needed, as they work to solve
specific problems.

Likewise, I think we need the "ping" mechanism in places where the other two
would not provide the desired device status information.  We would not need
keep or overload between some devices.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Apr 2010 13:32:24 -0400

> keep or overload between some devices.

I don't *in principle* have a problem with treating these as separate 
things. But then we must ensure that they don't have unintended 
(negative) interactions. That should be managed by careful scoping and 
by ensuring that they take account of one another.

Christer indicated that there was a previous decision to include 
proxy-proxy keep-alives in the -keep draft. Christer - do you know where 
that decision might be documented? The existing goal list is very vague 
on this.

If we were to piggyback options-ping onto that goal, it would make it 
even later than it already is. Otherwise it will need a new goal to 
become a WG draft. We will need some support from the ADs for that. But 
before asking them, I would like to see a broader level of interest on 
this mailing list.

	THanks
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Apr 2010 23:13:58 +0200

Hi, 

>>> People can correct me if I'm wrong - my impression is that the 
>>> *intent* of the keep stuff and the options ping stuff is different, 
>>> at least in emphasis. I am thinking the focus of keep is on keeping 
>>> nat pinholes open, while the focus of options ping is on 
>>> determination of which neighbors are up/down.
>> 
>>> So to an extent its a matter of whether to characterize this ping 
>>> work as part of one of those other charters, or as something 
>>> independent of them. What is your take on that?
>> 
>> I fully agree that the OPTIONS "ping" can be viewed as overlapping 
>> with the other two drafts.
>> 
>> As you know, it was not the intent of the "ping" mechanism to serve as 
>> an overload mechanism, nor was it intended as a means of keeping pinholes open.
>> 
>> I think both the keep and overload work is needed, as they work to 
>> solve specific problems.
>> 
>> Likewise, I think we need the "ping" mechanism in places where the 
>> other two would not provide the desired device status information.  We 
>> would not need keep or overload between some devices.
>
>I don't *in principle* have a problem with treating these as separate things. But then we must ensure that they don't have unintended
>(negative) interactions. That should be managed by careful scoping and by ensuring that they take account of one another.
>
>Christer indicated that there was a previous decision to include proxy-proxy keep-alives in the -keep draft. Christer - do you know where that decision might be documented? The existing goal list is very 
>vague on this.

I haven't checked the meeting minutes, but the use-case was in the slides I presented at the Dublin meeting.

Regards,

Christer