Re: [sipcore] IPv6 in the sip core wg

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

Yes, I've found the SHOULD now in the draft. Mozilla did one of its tricks on me and as a result I was searching for the wrong things.

I agree with your comment on 3263 in regard to the use of SHOULD. It does contain normative provisions, but they are substantially SHOULD requirements with no additional guidance.

I could not find anything in RFC 3263 than mandated in any form the use of A versus AAAA, eithewr together or separately.

On that basis it adds rather than updates. But there may be other requirements that come out of the discussion.

But Vijay keeps mentioning RFC 6157 so I had a look and there it states:

   "IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses
   using the ICE procedures to generate all their offers.  This way,
   both IPv4-only and IPv6-only answerers will be able to generate a
   mutually acceptable answer that establishes a session (having used
   ICE to gather both IPv4 and IPv6 addresses in the offer reduces the
   session establishment time because all answerers will find the offer
   valid.)

      Implementations are encouraged to use ICE; however, the normative
      strength of the text above is left at a SHOULD since in some
      managed networks (such as a closed enterprise network) it is
      possible for the administrator to have control over the IP version
      utilized in all nodes and thus deploy an IPv6-only network, for
      example.  The use of ICE can be avoided for signaling messages
      that stay within such managed networks."

So is that not pretty much saying the same thing as:

  "A dual-stack client SHOULD perform an A and AAAA record lookup of the
   domain name and add the respective IPv4/IPv6 addresses to the list of
   IP addresses to be contacted."

Certainly, if something is missing, we may well be talking about something that updates RFC 6157 rather than RFC 3263.

In regards to your milestone proposal, I do not understand:

"so we take the time for IESG processing out of the schedule"

"to WGLC" is to the start of WGLC
"to IESG" is the publication request

Neither milestone would include IESG processing.

A possible different milestone wording would be "Use of RFC 3263 in dual-stack devices". I would like to get rid of the word "supplement". We'd need to see if that requires changing based on Vijay's input.

Keith

 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: 13 December 2013 16:28
> To: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith)
> Cc: SIPCORE WG; Olle E. Johansson; Cullen Jennings
> Subject: Re: [sipcore] IPv6 in the sip core wg
> 
> On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote:
> >
> > On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith) 
> <[e-mail]> wrote:
> >
> >> 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.
> >
> > You're right, t is not at all my intent.  What I intend is 
> to provide a stand-alone RFC that provides some useful 
> supplemental procedures for improved performance in SIP 
> dual-stack environments.
> 
> If these procedures are supplemental, will there be anything 
> that should be normative?
> 
> Contrary to what Keith said, I do find normative language in 
> the draft now. (A SHOULD in the last paragraph of 3.1.) And 
> this is a change to language in 3263 - changing "A or AAAA" 
> to "A and AAAA".
> 
> It is arguable whether this has normative impact on existing 
> implementations of 3263. 3263 has no normative language 
> regarding "A or AAAA", but it does have normative language 
> ("SHOULD") about how to use the results of the lookup. I 
> think it can be viewed as a normative change to 3263 for dual 
> stack devices.
> 
> And 3263 suffers from the common problem of using "SHOULD" 
> widely without any explanation of when it makes sense to 
> violate the "SHOULD". 
> This gives people the opportunity to say that implementations 
> that do otherwise are still compliant. I would be 
> uncomfortable publishing a new normative RFC that doesn't say 
> it updates 3263 while mandating behavior that is different 
> from the SHOULDs of 3263.
> 
> Having said that, I suggest the following as the milestone:
> 
>      May 2014  WGLC of procedures to supplement RFC3263 for dual-stack
>      client and server handling of SIP URIs containing domain 
> names (PS)
> 
> This assumes that the work will be standards track, but 
> doesn't say whether or not it will update 3263. I've made the 
> milestone to be for WGLC, so we take the time for IESG 
> processing out of the schedule. The date is after the London 
> meeting but before the Toronto meeting. It is assuming that 
> we will get much of the work done on the mailing list before 
> London, thrash out any controversial issues in London, then 
> do cleanup and WGLC. It is optimistic, but possible if there 
> isn't a lot if dissent.
> 
> Richard - does this work for you?
> 
> Olle & Gonzalo - does it work for you?
> 
> 	Thanks,
> 	Paul
> 
> 
> > Gonzalo
> >
> >
> >>
> >> 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
> >>>
> >
> >
> 
>