Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 3 Oct 2013 09:09:18 +0000

I believe SIPCore should adopt draft-johansson-sip-dual-stack and I am willing to contribute, review etc.

Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Olle E. Johansson
> Sent: 30 September 2013 14:59
> To: [email-masked] WG
> Cc: Olle E. Johansson; Gonzalo Salgueiro (gsalguei); Cullen Jennings
> Subject: [sipcore] Locating SIP servers in a dual stack IP network
> 
> Hi!
> We have written a draft that updates RFC 3263 to better handle dual
> stack issues and prepare for another draft that clarifies Happy
> Eyeballs-like procedures for setting up connections with SIP in dual
> stack networks.
> 
> The document in the current version can be found here:
> http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01
> 
> This draft is a result of the work in the SIP forum IPv6 working group.
> During SIPit events and discussions in the wg we've located a couple of
> issues with RFC 3263 and the way we handle SRV results. During the IETF
> meeting in Berlin I consulted with the IETF DNS directorate and they
> confirmed that RFC 3263 doesn't follow the DNS SRV RFC in the way it
> describes handling IPv6 and IPv4 - specially where it instructs
> implementers to look up either address family, but not both. The DNS
> SRV RFC clearly states that ALL addresses for a host name should be
> used and connections should be tried before the next host name in the
> list is used (higher priority).
> 
> We've discussed this with the chairs of dispatch (Cullen, Mary) and
> they feel this is a document for the SIPcore working group. The chairs
> of SIPcore agreed in meetings in Berlin. The charter clearly states
> that SIPcore handles updates to core documents.
> 
> I guess the question now is if the SIPcore wg is willing to adopt this
> work?
> 
> 
> Best regards,
> /Olle
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 3 Oct 2013 14:55:46 -0400 (EDT)

> From: "Olle E. Johansson" <[email-masked]>
> 

> I guess the question now is if the SIPcore wg is willing to adopt
> this work?

It is clear that we need to clean up any problems that SIP has in
dual-stack environments now that IPv6 usage is starting to increase.
So Sipcore should accept this work item.

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 3 Oct 2013 20:17:45 -0400

I too think that we need to clarify the dual-stack environment in SIP and
support this work item in the SIP Core.

Regards,
 Rifaat

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 7 Oct 2013 09:45:32 -0400

+1   

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rifaat Shekh-Yusef
Sent: Thursday, October 03, 2013 8:18 PM
To: Dale R. Worley
Cc: [email-masked]; Olle E. Johansson
Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network

Regards,

 Rifaat

On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley <[email-masked]
<mailto:[email-masked]> > wrote:

> From: "Olle E. Johansson" <[email-masked] <mailto:[email-masked]> >

Dale

_______________________________________________
sipcore mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 9 Oct 2013 14:57:03 +0000

+1 with a minor detail. I don't think this needs to be a normative change to 3263. Products that implement 3263 can work just fine in v4/v6. I think this should be a extension to 3263 that UAs can choose to implement and can result in better performance. 

I'm trying to say that I happy with an RFC that products can choose to implement that says the do A and AAAA in parallel. But given that 3263 does not forbid this, I do not think it is an update to 3263, I think it is an extension. 

Alternatively, if people make this an update, then you are not 3263 complaint unless you do this and thus not SIP compliant unless you do this. I am strongly apposed to that as this is a minor optimization that does not make much difference in most deployments (yah yah, your registration when the phone first boots takes 100ms more - so what). 

So to be clear, I support adopting this draft as a WG item but not if it is an update to 3263. 

On Oct 7, 2013, at 7:45 AM, Richard Shockey <[email-masked]> wrote:

> +1  
>  
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
> I too think that we need to clarify the dual-stack environment in SIP and support this work item in the SIP Core.
>  
> Regards,
>  Rifaat
>  
>  
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 9 Oct 2013 12:42:48 -0400

Yeah, that makes sense to me.
But I am not clear on what you mean when you say "I don't think this needs
to be a *normative* change to 3263.". Are you saying that the document
should be Informational instead of Standards Track?

Regards,
 Rifaat

On Wed, Oct 9, 2013 at 10:57 AM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

>
> +1 with a minor detail. I don't think this needs to be a normative change
> to 3263. Products that implement 3263 can work just fine in v4/v6. I think
> this should be a extension to 3263 that UAs can choose to implement and can
> result in better performance.
>
> I'm trying to say that I happy with an RFC that products can choose to
> implement that says the do A and AAAA in parallel. But given that 3263 does
> not forbid this, I do not think it is an update to 3263, I think it is an
> extension.
>
> Alternatively, if people make this an update, then you are not 3263
> complaint unless you do this and thus not SIP compliant unless you do this.
> I am strongly apposed to that as this is a minor optimization that does not
> make much difference in most deployments (yah yah, your registration when
> the phone first boots takes 100ms more - so what).
>
> Behalf Of Rifaat Shekh-Yusef
> > I too think that we need to clarify the dual-stack environment in SIP
> and support this work item in the SIP Core.
> >
> > Regards,
> >  Rifaat
> >
> >
> >

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 9 Oct 2013 16:52:48 +0000

On Oct 9, 2013, at 12:42 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:

> But I am not clear on what you mean when you say "I don't think this needs to be a *normative* change to 3263.". Are you saying that the document should be Informational instead of Standards Track?

[as co-author...]

This was not my understanding.  What is prescribed in the draft is normative and IMO should be Standards Track.  Interpreted Cullen's comments as he simply doesn't want the "Updates: 3263" designation.  

I'm asking because I'm unclear on the semantics: If this draft updated 3263, wouldn't an implementation not supporting it still be 3263 compliant, but simply not support the update (RFCXXXX) ?

If it truly renders an implementation non-3263 compliant, then the argument for not wanting this to update 3263  seems reasonable . Given that constraint, I suppose this can be addressed with (1) standalone RFC that has text explicitly stating this is an extension to 3263 or (2) a 3263bis  effort.  Since (2) is a much more involved undertaking, I'd say (1) moves the ball forward and gets the desired result (normative procedures to improve performance in  v4/v6 environments).

Cheers,

Gonzalo

> 
> Regards,
>  Rifaat
> 
> 
> 
> On Wed, Oct 9, 2013 at 10:57 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 9 Oct 2013 17:12:20 +0000

Sorry, I was not very clear. 

I think this should be a standards track RFC. 

However on the first page on top left, the current draft has the line 

"Updates: 3263 (if approved)         "

I strongly disagree with this. It should not update 3263. It is an extension to 3263. I imaging that this is here only because it is pretty confusing in IETF what update, replace, extends, experimental etc all mean because they do not mean what the common english usage might lead you to believe. 

3263 is does not say you can't do things in parallel thought it might lead implications to doing things sequentially. This draft has the advice to go do A and AAAA in parallel. I've got no objections to a standards track RFC that says to do A and AAAA in for SIP. We are not saying that every existing SIP device has to be modified to go do this in parallel but saying here is an RFC that many device may choose to implement and will make things better in some way. That why I don't want it to be annotated as a update. We want to say this is good idea and here's how to do it and it's comparable with how things are done today. That's why it's an extension. 

Overall I want to minimize the churn in the SIP protocol while still allowing good new idea like this to be implemented. It's a small nit - just one word at the top of a spec that most people won't care about. But I will probably go on and on about it, so just make that one word go away :-)

And I don't want to do a 3263bis - that's lots of work and just not needed at this point.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 9 Oct 2013 13:45:20 -0400 (EDT)

> From: "Cullen Jennings (fluffy)" <[email-masked]>

> complaint unless you do this and thus not SIP compliant unless you
> do this. I am strongly apposed to that as this is a minor
> optimization that does not make much difference in most deployments
> (yah yah, your registration when the phone first boots takes 100ms
> more - so what). 

Strictly speaking, even if we make a normative change to 3263,
products that do not implement the change are still compliant to
*3263*, they're just not compliant to [whatever the new RFC number
is].

Indeed, issuing a new RFC, whether or not we called it a "normative
change", would simply add another checkbox on the enormously long list
of "Does your SIP product implement RFC nnnn?"  The customers would
place whatever weight they desire on the new checkbox.  The only real
question seems to be the technical one of whether an implementation
can (should?) be fully compliant with the new RFC and also fully
compliant with 3263.  If not, we need to tag 3263 as having been
updated.

As to whether the difference is significant in "most deployments",
that is something that needs to be investigated.  What is the
difference in performance likely to be in environments that use IPv6?
And certainly, the fraction of environments that are dual stack will
be increasing rapidly over the next decade.

It does look like the draft has considered how DNS record sets should
be constructed to get the best SIP behavior.  I worried that that
might have been overlooked.  (The destination domain is responsible
for providing DNS records that obtain good behavior from the sender.)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 14:49:30 -0400

(as individual)

I agree with Cullen's intent here.
If others do too, then we just need to agree on the best way to achieve 
that intent.

If the behavior in this draft is already legal according to RFC3263, 
then why does it need to be normative? Couldn't it be an informative RFC 
that describes a more efficient way to use 3263?

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 9 Oct 2013 15:32:58 -0400

I too agree with Cullen's intent, but was confused by the "normative"
comment.
I agree that Informational draft might be sufficient in this case.

Regards,
 Rifaat

On Wed, Oct 9, 2013 at 2:49 PM, Paul Kyzivat <[email-masked]> wrote:

> If the behavior in this draft is already legal according to RFC3263, then
> why does it need to be normative? Couldn't it be an informative RFC that
> describes a more efficient way to use 3263?
>
>         Thanks,
>         Paul
>
>
>
>> ______________________________**_________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>>
>>
> ______________________________**_________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 9 Oct 2013 20:23:36 +0000

On Oct 9, 2013, at 2:49 PM, Paul Kyzivat <[email-masked]> wrote:

> If others do too, then we just need to agree on the best way to achieve that intent.
> 
> If the behavior in this draft is already legal according to RFC3263, then why does it need to be normative? Couldn't it be an informative RFC that describes a more efficient way to use 3263?

There is likely some level of subjectivity here, but isn't the more efficient way a normative procedure that is a protocol directive with implementation impacts?  That strikes me as Standards Track.

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Oct 2013 17:56:51 -0400

> There is likely some level of subjectivity here, but isn't the more efficient way a normative procedure that is a protocol directive with implementation impacts?  That strikes me as Standards Track.

I don't think "efficient" applies here. Did you mean "effective"?

I think the difference between Informational and Standards Track here is 
that with a standard it becomes possible for someone to claim 
conformance, and there would be something to test.

Also, if there is some question whether the behavior described in this 
draft is allowed by 3263, then it might be necessary to define this as a 
revision to 3263. We can talk further about that.

I think it comes down to whether the "or" in "A or AAAA" is an 
*inclusive or" or an *exclusive or*. This is a common ambiguity in 
English. Does anybody think it was intended as an exclusive or? If it 
was then you could only use the A records or else the AAAA records - it 
would be incorrect to use both A and AAAA records in *any* order.

If need be we could file an errata to 3263, replacing the "or" with 
"and/or".

There doesn't seem to be an interoperability issue here. This is 
behavior that is implemented by one party without any need for 
cooperation by another party.

Am I missing something?

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 10 Oct 2013 23:16:31 +0000

> I don't think "efficient" applies here. Did you mean "effective"?

I was simply trying to be contextual by repeating Cullen's exact word; but sure 'efficient' is likely better.
> 
> I think the difference between Informational and Standards Track here is that with a standard it becomes possible for someone to claim conformance, and there would be something to test.

It is my understanding that the draft offered something to conform to that can be tested.
> 
> Also, if there is some question whether the behavior described in this draft is allowed by 3263, then it might be necessary to define this as a revision to 3263. We can talk further about that.
> 
> I think it comes down to whether the "or" in "A or AAAA" is an *inclusive or" or an *exclusive or*. This is a common ambiguity in English. Does anybody think it was intended as an exclusive or? If it was then you could only use the A records or else the AAAA records - it would be incorrect to use both A and AAAA records in *any* order.
> 
> If need be we could file an errata to 3263, replacing the "or" with "and/or".
> 
> There doesn't seem to be an interoperability issue here. This is behavior that is implemented by one party without any need for cooperation by another party.
> 
> Am I missing something?

Well obviously I thought 3263 didn't address the issue or we wouldn't have authored the draft.  I'm clearly far too biased, so I leave it to others to comment on their interpretation of 3263.

Cheers,

Gonzalo

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 10 Oct 2013 23:18:04 +0000

> I was simply trying to be contextual by repeating Cullen's exact word; but sure 'efficient' is likely better.

Oops:  s/efficient/effective/

Cheers,

Gonzalo

---

From: Brett Tate <[email-masked]>
Date: Tue, 15 Oct 2013 11:19:03 +0000

> I think it comes down to whether the "or" in "A or AAAA" 
> is an *inclusive or" or an *exclusive or*. This is a 
> common ambiguity in English. Does anybody think it was 
> intended as an exclusive or? 

Yes.

> If it was then you could only use the A records or else 
> the AAAA records - it would be incorrect to use both A 
> and AAAA records in *any* order.

RFC 3261 allows "local policy specifying otherwise".  However I agree that RFC 3261 indicates "A or AAAA record lookup of the domain name" instead of "A and/or AAAA record lookup of the domain name".  Thus if an operator prefers both A and AAAA to be tried to specific device, they can configure SRV records accordingly.

> There doesn't seem to be an interoperability issue here. 
> This is behavior that is implemented by one party without 
> any need for cooperation by another party.

It is less about interoperability and more about deployment.  The administrators need to know how the devices should behave.  More specifically, they need to know if configuring both A and AAAA records corresponding to a specific SRV record's target/device would potentially delay advancement to the next SRV location/device because of a particular interpretation of RFC 3263.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Oct 2013 14:46:52 -0400

>> intended as an exclusive or?

Really! I was thinking it is obviously intended as inclusive OR.

> It is less about interoperability and more about deployment.  The administrators need to know how the devices should behave.  More specifically, they need to know if configuring both A and AAAA rec…

Good point. But that makes things difficult.

If administrators believe "if I configure some AAAA records it might 
cause my clients to slow down", then it will require widespread adoption 
of this new proposal before that is fixed and those admins are willing 
to configure AAAA.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Oct 2013 13:58:56 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

IMO, the trouble is that if one meant to look up the A records as well
as the AAAA records (to do queries for two types), one would normally
phrase it as "A and AAAA" records.  Combining the fact that "A or
AAAA" is not the standard way of expressing the "inclusive or" with
the fact that "or" is ambiguous in English leads the reader to the
possibility that the writer meant "look up the A records exclusive-or
look up the AAAA records".

> > It is less about interoperability and more about deployment.  The
> > administrators need to know how the devices should behave.  More
> > specifically, they need to know if configuring both A and AAAA
> > records corresponding to a specific SRV record's target/device
> > would potentially delay advancement to the next SRV
> > location/device because of a particular interpretation of RFC
> > 3263.
> 

Isn't that ultimately the driver behind the Happy Eyeballs work?  The
discovery that -- in practice -- adding AAAA records for your web site
can slow down some of the clients?

It seems to me that we need to determine (1) if there is any risk that
current or (under current guidance) future implementations will have
undesirable behavior when AAAA records are added, and if so (2)
publish new guidance to minimize this undesirable behavior.  Both of
these depend on how people *interpret* RFCs, and so we have to get to
the bottom of current interpretations of 3263, and we have to label
any new guidance in a way that maximizes its uptake.

Dale