Re: [sipcore] IPv6 in the sip core wg

[Paul Kyzivat <[e-mail]>]

On 12/13/13 12:43 PM, Mary Barnes wrote:
>
>
>
> On Fri, Dec 13, 2013 at 10:28 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 12/12/13 8:07 PM, Gonzalo Salgueiro (gsalguei) wrote:
>
>
>         On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith)
>         <keith.drage@alcatel-lucent.__com
>         <mailto:[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.
>
> [MB] What is the point of taking the time for IESG processing out of the
> schedule?   I don't see a problem with stating two milestones, but
> milestones in a charter always reflect the target completion of work
> within the WG (and that's NOT WGLC).  There was a period of time where
> the ADs wanted to see the two milestones, so that's certainly not an
> unacceptable thing to do, but not listing the IESG milestone isn't
> normal procedure.  RFC 2418 explains some of this.   As I said in a
> previous note, in my experience, two months is an optimistic average for
> the time between completing a 1st WGLC and a doc going to the IESG.   [/MB]

I will defer to your deeper knowledge of this.

>     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
>
>
> Note, I've delated the remainder of this thread as it's gotten insanely
> long.
> [MB]
>
>
>
>