Re: [sipcore] IPv6 in the sip core wg

["Olle E. Johansson" <[e-mail]>]

On 13 Dec 2013, at 12:22, Gonzalo Salgueiro (gsalguei) <[e-mail]> wrote:

> On Dec 13, 2013, at 11:28 AM, Paul Kyzivat <[e-mail]> wrote:
> 
>> On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote:
>>> 
>>> 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.
>> 
>> If these procedures are supplemental, will there be anything that should be normative?
>> 
>> Contrary to what Keith said, I do find normative language in the draft now. (A SHOULD in the last paragraph of 3.1.) And this is a change to language in 3263 - changing "A or AAAA" to "A and AAAA".
>> 
>> It is arguable whether this has normative impact on existing implementations of 3263. 3263 has no normative language regarding "A or AAAA", but it does have normative language ("SHOULD") about how to use the results of the lookup. I think it can be viewed as a normative change to 3263 for dual stack devices.
>> 
>> And 3263 suffers from the common problem of using "SHOULD" widely without any explanation of when it makes sense to violate the "SHOULD". This gives people the opportunity to say that implementations that do otherwise are still compliant. I would be uncomfortable publishing a new normative RFC that doesn't say it updates 3263 while mandating behavior that is different from the SHOULDs of 3263.
>> 
>> Having said that, I suggest the following as the milestone:
>> 
>>   May 2014  WGLC of procedures to supplement RFC3263 for dual-stack
>>   client and server handling of SIP URIs containing domain names (PS)
>> 
>> This assumes that the work will be standards track, but doesn't say whether or not it will update 3263. I've made the milestone to be for WGLC, so we take the time for IESG processing out of the schedule. The date is after the London meeting but before the Toronto meeting. It is assuming that we will get much of the work done on the mailing list before London, thrash out any controversial issues in London, then do cleanup and WGLC. It is optimistic, but possible if there isn't a lot if dissent.
>> 
>> Richard - does this work for you?
>> 
>> Olle & Gonzalo - does it work for you?
> 
> I'm ok with it.  
+1

/O
> 
> The authors will make some changes to the current version of the document and submit a new version that hopefully makes clearer the original intent: a stand-alone RFC offering improved procedures for dual-stack environments (i.e., does not invalidate or render non-compliant the myriad of 3263 implementations out there that work fine with v6).
> 
> Gonzalo
>> 
>> 	Thanks,
>> 	Paul
>> 
>> 
>>> 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
>>>>> 
>>> 
>>> 
>> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore