Re: [sipcore] IPv6 in the sip core wg

[Mary Barnes <[e-mail]>]

On Fri, Dec 13, 2013 at 10:28 AM, Paul Kyzivat <[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) <
>> [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]


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

>
>
>
>>