Re: [sipcore] IPv6 in the sip core wg

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 16 December 2013 19:49 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00ED11AC4A3 for <sipcore@ietfa.amsl.com>; Mon, 16 Dec 2013 11:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek0NFTdL009b for <sipcore@ietfa.amsl.com>; Mon, 16 Dec 2013 11:49:02 -0800 (PST)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id DAB631A1F3F for <sipcore@ietf.org>; Mon, 16 Dec 2013 11:49:01 -0800 (PST)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id 2D6F1n0021vXlb85CKp1pT; Mon, 16 Dec 2013 19:49:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 2Kp01n00n3ZTu2S3dKp0LA; Mon, 16 Dec 2013 19:49:01 +0000
Message-ID: <52AF592C.3050000@alum.mit.edu>
Date: Mon, 16 Dec 2013 14:49:00 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: <C774C9EA-4E79-4846-A834-BF86D2DD8018@edvina.net> <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <CAHBDyN7AT0m7P5miYa+hCvh55Ov3f1Nc-U1zUK6H-0i4aHTW+g@mail.gmail.com> <52A7486E.2090005@alum.mit.edu> <FFB57ECD-8CDB-44E9-9A3F-5418AAC01C5B@iii.ca> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <BCD747C2-B0E9-492E-97E2-58B078AF5F74@iii.ca> <E9BFFB26-2E71-42D3-A126-0DA7535DD688@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> <FD51E29F-9CD3-42F7-B7F6-DB09A60701C9@edvina.net> <E5673C5D-E520-4EB1-8983-977398FB15F1@iii.ca>
In-Reply-To: <E5673C5D-E520-4EB1-8983-977398FB15F1@iii.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387223341; bh=SYaQjH+4MAUvHf/BNqa9zX8ePr5Go9Yq+5nrUVIKTag=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dlhQxo60ZJhOg9Dzn1eLMWbMleK3poK4WIp09Zv0JzU0zjCrye94xYMY99D4Aozax jN4qFTpbbcwCPnxPToIHR3HWcMMlMirexCAK5rvPJ7NwTzdo5i8J2RfRlSsaMN1Lxq ugGFA0MmKp6yshVnX+drRURG6cs25jOirKTboKySXf9prACQKVeFeTlJazsuyHxdw4 Zi5Xrbhv3f41F9OoS/Svo5CEYldLv5tEN11HKnvGl5IBqTrpgowNHvFeTY1MSsF72d t4kF3eRoj/6tDtZIWT2/sdpNEE6oEIOvYAArwyy6Fl9RdcH2I8pD5RC8WZu4zCqnR8 5igYByZFisdkw==
Subject: Re: [sipcore] IPv6 in the sip core wg
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 19:49:03 -0000

On 12/16/13 2:30 PM, Cullen Jennings wrote:
>
> On Dec 13, 2013, at 9:17 AM, Olle E. Johansson <oej@edvina.net> wrote:
>
>> The problem is really that RFC 3263 repeats "A or AAAA" - which means that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 addresses to connect to. I have not claimed that it talks about how we connect.
>
> A or B does not mean you are not allowed to do both

English is vague about this.
It can be read as either OR or XOR.
And that is just when considering use by native English speakers.
When you factor in people for whom English is not native, it is probably 
more dubious which it means.

If there is any concern then we should ensure that this is clarified.
Whether that requires an update may still be controversial. But ISTM if 
we are going to produce a standards track RFC anyway, that it would be 
better to be sure by declaring it to be an update.

If your implementation is already consistent with the clarification, 
then you can immediately claim conformance to it. But advertising it as 
an update may provoke some to discover that they aren't consistent with 
the clarified intent. That will cause them some work to conform, but 
will also fix problems.

	Thanks,
	Paul