Re: [sipcore] IPv6 in the sip core wg

[Mary Barnes <[e-mail]>]

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. 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]> 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]> wrote:
>>
>>
>>> On 10 Dec 2013, at 12:14, Cullen Jennings <[e-mail]> wrote:
>>>
>>>
>>>> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat <[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
>>>
>>
>>
>>
>