Re: [sipcore] IPv6 in the sip core wg

Normative procedure are being prescribed, so it is undoubtedly Standards Track IMO. Enhanced/Improved/Refined all seem fine to me and don't imply that this work formally updates 3263.  That is a discussion detail we can have once we actually have some concrete text adopted and the WG can weigh in with their preference. 

Gonzalo

On Dec 12, 2013, at 11:59 AM, Mary Barnes <mary.ietf.barnes@gmail.com> 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. 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 <pkyzivat@alum.mit.edu> 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 <oej@edvina.net> wrote:
> 
> 
> On 10 Dec 2013, at 12:14, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> 
> On Dec 10, 2013, at 9:59 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore