Re: [sipcore] IPv6 in the sip core wg

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) <[e-mail]> wrote:

> Lets look at the specification.
> 
> Your mail seems to being its best to justify it as a BCP, which I assume is not what you intend.

You're right, t is not at all my intent.  What I intend is to provide a stand-alone RFC that provides some useful supplemental procedures for improved performance in SIP dual-stack environments.

Gonzalo


> 
> Keith 
> 
>> -----Original Message-----
>> From: Gonzalo Salgueiro (gsalguei) [mailto:[e-mail]] 
>> Sent: 13 December 2013 00:54
>> To: DRAGE, Keith (Keith)
>> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG; 
>> Olle E. Johansson; Cullen Jennings
>> Subject: Re: [sipcore] IPv6 in the sip core wg
>> Importance: High
>> 
>> (as co-author)
>> 
>> I'm happy to publish a new version of the document that makes 
>> use of 2119 language.  
>> 
>> I think we might be trying to over-complicate matters. As 
>> stated earlier, this work is merely an extension to the 
>> procedures in 3263 and should not make the myriad existing 
>> deployments non-compliant to a core SIP specification. The 
>> intent here is only to provide supplemental best practices 
>> that we have learned along the way through extensive interop 
>> testing. To emblazon this point into everyone's psyche, the 
>> next version will not have the "Updates: 3263 (if approved)" label.
>> 
>> With this in mind, I propose the following as the milestone text:
>> 
>> Supplemental procedures for dual-stack server handling of SIP 
>> URIs containing domain names
>> 
>> 
>> To your point regarding Vijay, the authors will stay in sync 
>> with him throughout.
>> 
>> 
>> Cheers,
>> 
>> Gonzalo
>> 
>> 
>> 
>> On Dec 12, 2013, at 4:45 PM, DRAGE, Keith (Keith) 
>> <[e-mail]> wrote:
>> 
>>> I was losing track of this discussion so I had to go back.
>>> 
>>> The only document we seem to have on the table at the moment is:
>>> 
>>> http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt
>>> 
>>> This currently contains no normative provisions (no MUST, 
>> SHOULD, MAY) so it is a bit difficult to judge what the scope 
>> of a normative document should be.
>>> 
>>> Could I suggest that before we scope the work and as a 
>> consequence write the milestone, we see another version of 
>> the author draft containing at least the minimum set of 
>> normative requirements the authors think we need.
>>> 
>>> That may be because it is written in the style of RFC 3263 
>> which also contains no normative provisions. It might be that 
>> in order to scope this work we actually need a bis version of 
>> RFC 3263, rather than something that adds some more 
>> requirements in this area.
>>> 
>>> In response to Cullen, I would say there is another reason 
>> why something should be an update rather than just being 
>> regarded as an extension. If it contains provisions that all 
>> RFC 3263 implementations (or most of) should also implement, 
>> and it is within the scope of the original RFC, then I 
>> believe that may also justify and update. But I agree that we 
>> need to write the requirements first and then do this analysis.
>>> 
>>> I'd also remind you that Vijay has some comments that the 
>> issue was wider than RFC 3263, so there may be a need to 
>> scope round that.
>>> 
>>> None of these comments should be taken as a suggestion that 
>> we should not do the work (I think the issue has been 
>> justified), only that I do not understand the scope and there 
>> is not enough on the table to judge that.
>>> 
>>> Keith
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: sipcore [mailto:[e-mail]] On Behalf 
>> Of Gonzalo 
>>>> Salgueiro (gsalguei)
>>>> Sent: 12 December 2013 19:19
>>>> To: Paul Kyzivat
>>>> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei); 
>>>> Cullen Jennings
>>>> Subject: Re: [sipcore] IPv6 in the sip core wg
>>>> Importance: High
>>>> 
>>>> 
>>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat <[e-mail]> 
>>>> wrote:
>>>> 
>>>>> On 12/12/13 11:59 AM, Mary Barnes wrote:
>>>>>> The question in my mind becomes how you can word it
>>>> properly.  There
>>>>>> are already procedures for dual stack, so you can't just say:
>>>>>> 
>>>>>> Procedures for dual-stack server handling of SIP URIs containing 
>>>>>> domain names
>>>>>> 
>>>>>> Any of the adjectives proposed so far "Amended" or "Updated" or 
>>>>>> others that might seem appropriate, e.g., "Enhanced" imply
>>>> that the
>>>>>> existing procedures are being changed or corrected.  
>>>> Although maybe "Enhanced" is
>>>>>> general enough to not necessarily imply an "Update" to RFC
>>>> 3263?   But,
>>>>>> then would you be talking about an Informational versus
>>>> standards track
>>>>>> document?   I think it's usual for milestones to indicate 
>>>> whether the
>>>>>> work is informational, standards track or BCP.  But, if
>>>> the AD will
>>>>>> approve the new milestone without that level of
>>>> specificity, that's
>>>>>> fine.
>>>>> 
>>>>> ISTM that we are in a situation where we need to consider
>>>> the details of the proposed mechanism(s) before deciding if the 
>>>> desired mechanism will be an update or not. So I think it 
>> makes sense 
>>>> to word the milestone to be non-specific about this.
>>>>> 
>>>>> Maybe its not the term itself that is the problem, but
>>>> rather what the term references. IOW, is it that we intend to 
>>>> ammend/update/enhance/improve the *procedures*, or the
>>>> *description* of the procedures?
>>>>> 
>>>>> IIUC the intent is to clarify the description, and if that
>>>> is insufficient to get a satisfactory result, then to update the 
>>>> procedures themselves.
>>>> 
>>>> So what is the proposed text for the milestone?
>>>> 
>>>> Gonzalo
>>>> 
>>>>> 
>>>>> 	Thanks,
>>>>> 	Paul
>>>>> 
>>>>>> But, I also don't think it's useful for the group to
>>>> rathole on that
>>>>>> later in the process and it will definitely cause
>>>> confusion if the WG
>>>>>> doesn't have a clear reason why the specific type of 
>> specification 
>>>>>> was selected.
>>>>>> 
>>>>>> Regards,
>>>>>> Mary.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat
>>>> <[e-mail]
>>>>>> <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>>  Cullen,
>>>>>> 
>>>>>>  Would you be satisfied if the milestone is sufficiently
>>>> vague that
>>>>>>  we can leave it to the deliverable to decide whether an
>>>> update is
>>>>>>  needed or not?
>>>>>> 
>>>>>>           Thanks,
>>>>>>           Paul
>>>>>> 
>>>>>> 
>>>>>>  On 12/10/13 6:13 PM, Cullen Jennings wrote:
>>>>>> 
>>>>>> 
>>>>>>      Well from a milestone point of view there is a big
>>>> difference
>>>>>>      between we need the change an existing RFC (i.e. 
>>>> update) or we
>>>>>>      need to define a new RFC that tells developers who want to
>>>>>>      implement the new RFC what they need to do.
>>>>>> 
>>>>>>      I think what is needed here is the later item and not the
>>>>>>      update. I have asked about this a bunch of times and and I
>>>>>>      always get answers that suggest that a new document
>>>> is needed
>>>>>>      but it does not need to replace or update 3263. It
>>>> needs to be a
>>>>>>      new document that provides more detailed advice. If
>>>> we are going
>>>>>>      to say this updates something, I want to be
>>>> convinced first that
>>>>>>      there is something that is wrong and needs to be
>>>> changed. I'm
>>>>>>      fine with the idea that ore detailed specifications
>>>> are needed
>>>>>>      to do something like happy eyeballs for SIP but I
>>>> don't think
>>>>>>      that requires an update of 3263.
>>>>>> 
>>>>>> 
>>>>>>      On Dec 10, 2013, at 12:21 PM, Olle E. Johansson
>>>> <[e-mail]
>>>>>>      <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> 
>>>>>>          On 10 Dec 2013, at 12:14, Cullen Jennings 
>> <[e-mail]
>>>>>>          <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> 
>>>>>>              On Dec 10, 2013, at 9:59 AM, Paul Kyzivat
>>>>>>              <[e-mail]
>>>> <mailto:[e-mail]>>
>>>>>>              wrote:
>>>>>> 
>>>>>>                  June 2014  Updated procedures for
>>>> dual-stack server
>>>>>>                  handling of SIP
>>>>>>                     URIs containing domain names
>>>>>> 
>>>>>> 
>>>>>>              Before we use update, can someone tell me
>>>> what normative
>>>>>>              text of the current RFCs need to be changed?
>>>>>> 
>>>>>> 
>>>>>>          That's part of the problem, RFC 3263 is not
>>>> very clear to me
>>>>>>          in indicating what exactly is normative. If 
>> you read our
>>>>>>          draft, you will see that we point to a few 
>> sections that
>>>>>>          clearly says that a UA needs to look up "A or
>>>> AAAA" records,
>>>>>>          which has been proven wrong and doesn't follow
>>>> the intention
>>>>>>          of the DNS SRV RFC. If this was unintentional
>>>> or normative,
>>>>>>          I don't know, but it's written enough times to
>>>> cause issues
>>>>>>          in implementations and have been copied to
>>>> other documents,
>>>>>>          like the MSRP RFC.
>>>>>> 
>>>>>>          We need to clarify that a SIP implementation
>>>> needs to follow
>>>>>>          the DNS SRV RFC and look up all addresses for a
>>>> host name
>>>>>>          (ipv4, IPv6 or future address families) and
>>>> test them all
>>>>>>          before moving to the next priority and host.
>>>>>> 
>>>>>>          I've checked this with members of the IETF DNS
>>>> directorate
>>>>>>          two times now, and they agree with this.
>>>>>> 
>>>>>>          When we clarified/updated/extended/__informed
>>>> the audience -
>>>>>>          developers - about this, we need to get down to how to
>>>>>>          connect - serially, in parallell, in reverse
>>>> random order
>>>>>>          controlled by the phases of the moon or other
>>>> planets - or
>>>>>>          simply Happy Eyeballs. But even with TCP, doing happy
>>>>>>          eyeballs like in HTTP would not work unless we
>>>> have both A
>>>>>>          and AAAA records. RFC 3263 doesn't really 
>> indicate that.
>>>>>> 
>>>>>>          Someone else needs to help out to clarify to me what is
>>>>>>          really normative in 3263 and what the
>>>> relationship between
>>>>>>          3263 and RFC 2782 really is - if RFC 2782 is
>>>> the normative
>>>>>>          one and RFC 3263 just can be seen as a happy story that
>>>>>>          points to 2782 without making any normative changes, we
>>>>>>          might have to clarify that in an informational
>>>> document and
>>>>>>          move on to connection setup in a dual stack
>>>> world. If RFC
>>>>>>          3263 changes the behaviour intended by 2782 and really
>>>>>>          forces a developer to select A or AAAA records,
>>>> then we need
>>>>>>          to change that behaviour.
>>>>>> 
>>>>>>          Either way, we have work to do in ths wg.
>>>>>>          /O
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>