Re: [sipcore] IPv6 in the sip core wg

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

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
>> 
>> 
>> 
>> 
>> 
>