Re: [sipcore] IPv6 in the sip core wg

["DRAGE, Keith (Keith)" <[e-mail]>]

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.

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