Re: [sipcore] [Technical Errata Reported] RFC3261 (5619)

Ben Campbell <ben@nostrum.com> Thu, 31 January 2019 19:14 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684C6130E88 for <sipcore@ietfa.amsl.com>; Thu, 31 Jan 2019 11:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 MbZXtDY2fTBg for <sipcore@ietfa.amsl.com>; Thu, 31 Jan 2019 11:14:03 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF66130E6A for <sipcore@ietf.org>; Thu, 31 Jan 2019 11:14:03 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0VJCHFR040149 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Jan 2019 13:12:21 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548961946; bh=t6ELSZ8GjOFuC9fnyuPkBj3THon8g2WIk77F9KaeQhs=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Fp8LqfskiUqyTcmQfZzflvjzQpMEuoCm/ESaBy57OMHdEvdMEN2A3UrlI75nJOo+y 9UJjUZB6BvG1T969SwdVzbp0MLdYSmsC2Bq9Y90zrscWKO7e6/j+qRpRoQFTBfTX+f Yx06Cn+PD0A0E8bgihzJLTT6QIPuyA05rZo+tIWs=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <DE825893-0C6C-4111-9A79-E9584CF136EA@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_2D4D41AC-DCD2-4166-ACEB-AFF59212BE24"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 31 Jan 2019 13:12:16 -0600
In-Reply-To: <20190131181522.008FCB82E2D@rfc-editor.org>
Cc: jdrosen@dynamicsoft.com, Henning Schulzrinne <schulzrinne@cs.columbia.edu>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, alan.johnston@wcom.com, jon.peterson@neustar.com, rsparks@dynamicsoft.com, mjh@icir.org, schooler@research.att.com, Alexey Melnikov <aamelnikov@fastmail.fm>, Adam Roach <adam@nostrum.com>, Dean Willis <dean.willis@softarmor.com>, "Keith (Keith) DRAGE" <drage@alcatel-lucent.com>, bella@rabenkind.at
To: SIPCORE <sipcore@ietf.org>
References: <20190131181522.008FCB82E2D@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/poS3paIfkRbGqlo9OPjJSkWbIIY>
X-Mailman-Approved-At: Thu, 31 Jan 2019 14:31:19 -0800
Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (5619)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 31 Jan 2019 19:14:05 -0000

Hi,

I think the point of the example was that Alice’s phone could have learned its home proxy via configuration or DHCP. Whether it learns an address, or a name that it then resolves with DNS is not material to the example. Perhaps it would have been more clear if some other word had been chosen than “address”.

I lean towards rejecting this as a technical erratum. If people want to address the use of “address” as an editorial erratum, we could address that with a new errata report (which would likely be marked as “hold for update”.

What do other people think?

Thanks!

Ben.


> On Jan 31, 2019, at 12:15 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC3261,
> "SIP: Session Initiation Protocol".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5619
> 
> --------------------------------------
> Type: Technical
> Reported by: Isabella Damböck <bella@rabenkind.at>
> 
> Section: 4
> 
> Original Text
> -------------
> The address
> of the atlanta.com SIP server could have been configured in Alice's
> softphone, or it could have been discovered by DHCP, for example.
> 
> Corrected Text
> --------------
> The address
> of the atlanta.com SIP server could have been configured in Alice's
> softphone, or it could have been discovered by DNS, for example.
> 
> Notes
> -----
> DHCP Server gives away the DNS-Server to use (or sets it with DHCP option) but usually does no address translation itself. It would also be possible to omit the whole sentence.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC3261 (draft-ietf-sip-rfc2543bis-09)
> --------------------------------------
> Title               : SIP: Session Initiation Protocol
> Publication Date    : June 2002
> Author(s)           : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG