[Sipping] (resend) Errata reports on erratum 2580 on RFC 3398 (ISDN User Part (ISUP) to SIP Mapping) and errata 2121 and 2122 on RFC 5479 (Requirements and Analysis of Media Security Management Protocols)

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 03 January 2011 18:20 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB1C3A6A55 for <sipping@core3.amsl.com>; Mon, 3 Jan 2011 10:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.51
X-Spam-Level:
X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1tdSpRMmuqh for <sipping@core3.amsl.com>; Mon, 3 Jan 2011 10:20:09 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 639E03A6A53 for <sipping@ietf.org>; Mon, 3 Jan 2011 10:20:09 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEABqjIU3GmAcF/2dsb2JhbACkNHOlKQKWWoVKBIRliVY
X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="257793669"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jan 2011 13:22:16 -0500
X-IronPort-AV: E=Sophos;i="4.60,267,1291611600"; d="scan'208";a="565688899"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jan 2011 13:22:15 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 3 Jan 2011 13:22:15 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipping@ietf.org" <sipping@ietf.org>
Date: Mon, 03 Jan 2011 13:22:14 -0500
Thread-Topic: (resend) Errata reports on erratum 2580 on RFC 3398 (ISDN User Part (ISUP) to SIP Mapping) and errata 2121 and 2122 on RFC 5479 (Requirements and Analysis of Media Security Management Protocols)
Thread-Index: AQHLq3Ml165MNmLa3EmdQmcH4sLrNQ==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B2202288B3A@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Sipping] (resend) Errata reports on erratum 2580 on RFC 3398 (ISDN User Part (ISUP) to SIP Mapping) and errata 2121 and 2122 on RFC 5479 (Requirements and Analysis of Media Security Management Protocols)
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jan 2011 18:20:11 -0000

There may have been a mailer problem with the first sending of this
report to the Sipping mailing list.

======================================================================
RFC3398, "ISDN User Part (ISUP) to SIP Mapping"
Source of RFC: sipping (rai)

Errata ID: 2580

Status: Reported
Type: Technical

Reported By: Stephen James
Date Reported: 2010-10-19

Section 8.1.3 says:

Item 6.
The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.

It should say:

Drop this statement.

Notes:

No CANCEL is sent on INVITE transaction timeout. This is per 3261 "If
no provisional response has been received, the CANCEL request MUST NOT
be sent; rather, the client MUST wait for the arrival of a provisional
response before sending the request."
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update

Section 8.1.3 item 6 should be updated to "The gateway also sends a
CANCEL message to the SIP node to terminate the initiation attempt if
a provisional response has been received."  The situation illustrated
in section 8.1.3 does not distinguish the "provisional response
received" case from the "provisional response not received" case, so
the commentary should cover both cases.  (The specific example
diagrammed shows the "no provisional response received" case.)

A similar change should be made to section 8.1.4 item 7, "The REL will
trigger a CANCEL request to the SIP node if a provisional response has
been received."

A similar change should be made to section 8.1.7 item 7, "Upon receipt
of a REL message before an INVITE final response, the gateway will
send a CANCEL towards the SIP node if a provisional response has been
received.

Since a reader familiar with SIP will know the rules for sending
CANCEL, this correction is not crucial for proper implementation of
the RFC, so I am recommending that it be held for document update.
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2121

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

Section 5.1 - 5.3 says:

Notes:

Sections 5.1 through 5.3 use unexpected irregular, non-uniform
indentation in hanging lists; this is accompanied by dangling
hyphens in 5.2 ( s/third- party/third-party/ and
s/crypto- agility/crypto-agility/ !).

(Keep for update!)
third- party
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2122

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

Section App. A says:

[[ second-to-last paragraph, on mid-page 24: ]]

   Related to SRTP's characteristics is a goal that any SRTP keying
|  mechanism to also be efficient and not cause additional call setup
   delay.

It should say:

   Related to SRTP's characteristics is a goal that any SRTP keying
|  mechanism also be efficient and not cause additional call setup
   delay.

Notes:

Rationale: language/grammar improvement -- keep for update!
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================

Dale