Re: [sipcore] IPv6 in the sip core wg

[Paul Kyzivat <[e-mail]>]

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.

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