Worley, Dale R (Dale | 3 Jan 19:22 2011

(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)

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
(Continue reading)

Andrew Allen | 5 Jan 18:07 2011

Re: draft-ietf-sipping-media-policy-dataset issues: mediatypes

Dale

I am OK with your proposed changes. 

I also would like to see this draft progress.

Andrew

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of Worley, Dale R (Dale)
Sent: Friday, December 03, 2010 2:15 PM
To: rai <at> ietf.org; sipping <at> ietf.org
Subject: [Sipping] draft-ietf-sipping-media-policy-dataset issues:
mediatypes

I am working on draft-ietf-sipping-media-policy-dataset to clean up some
issues.  These issues are minor technical changes to make the standard
more technically coherent and easier to implement.  As such, I don't
think they will be controversial in their essence, but I would like
people to look them over to ensure that I am not introducing new
problems.

The first issues revolve around media types:

1. In -10, all media type names that are mentioned in a MPDF are
explicitly required to be IANA-registered.  Technically, this means that
experimental or private-use types can not be used, even in situations
where all participants are aware of non-registered media types.  In
practice, people will go ahead and use them anyway.  I am proposing to
(Continue reading)

Worley, Dale R (Dale | 8 Jan 04:59 2011

draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations

I am starting work on a messy part of the media policy dataset
definition:  Specifying the logic when a policy is applied to a
session-info, and also specifying how two policies are combined to
apply jointly to session-infos.  The goal is to implement one's
intuitive expectations while introducing as few special cases as
possible.

My current analysis is:

- The primary operation is applying a session-policy to a session-info
  to produce a possibly more restricted session-info.  This is done by
  applying the session-policy to each stream in turn, which may
  "restrict" the stream (in regard to bandwidth, codecs, etc.).

- A stream may be restricted to the point that it permits no media
  whatsoever.  Such "null" streams are all logically equivalent,
  although a null stream can be represented in many different ways.
  When translated back into SDP, a null stream becomes a rejected
  m= line.

- The different <stream> elements in a session-policy are effectively
  ORed together, in that the policy intends to permit any stream that
  conforms to *any one* of the <stream> elements.  This is necessary
  because e.g. a session-policy can contain one <stream> that specifies
  audio media and restricts the codecs permitted for audio, and
  another <stream> that specifies video media and restricts the codecs
  permitted for video.

- Thus, applying a session-policy to a stream involves applying each
  session-policy <stream> to the stream, and then choosing the "best"
(Continue reading)

Gonzalo Camarillo | 18 Jan 09:51 2011
Picon

Re: [Technical Errata Reported] RFC3398 (2580)

Hi,

Stephen seems to be correct here. The gateway should not send the CANCEL
because it has not received any provisional response. I suggest we
accept the erratum. Comments?

Cheers,

Gonzalo

On 19/10/2010 8:31 PM, RFC Errata System wrote:
> 
> The following errata report has been submitted for RFC3398,
> "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3398&eid=2580
> 
> --------------------------------------
> Type: Technical
> Reported by: Stephen James <sjames_1958 <at> yahoo.com>
> 
> Section: 8.1.3
> 
> Original Text
> -------------
> Item 6.
> 
> The gateway also sends a CANCEL message to the SIP node to
(Continue reading)

Adam Roach | 18 Jan 15:14 2011

Re: [Technical Errata Reported] RFC3398 (2580)

Yes, it seems correct. I would tag it as accurate, and set the action to 
"hold for document update".

/a

On 1/18/11 02:51, Jan 18, Gonzalo Camarillo wrote:
> Hi,
>
> Stephen seems to be correct here. The gateway should not send the CANCEL
> because it has not received any provisional response. I suggest we
> accept the erratum. Comments?
>
> Cheers,
>
> Gonzalo
>
> On 19/10/2010 8:31 PM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC3398,
>> "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3398&eid=2580
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Stephen James<sjames_1958 <at> yahoo.com>
>>
>> Section: 8.1.3
>>
(Continue reading)

Robert Sparks | 18 Jan 16:16 2011

Re: [Technical Errata Reported] RFC3398 (2580)

Also,

The report is not complete - there are other examples in the document with the same bug.
If you're going to fix one of them by errata, you probably need to fix all of them.

I agree with "hold for document update". At the worst case, if something sends the CANCEL,
it's introducing traffic into a network that is too congested to handle the CANCEL. In the best case,
it introduces a message (and its retransmissions) that get ignored, or a single message that gets
an error response. (And for completeness, there is one situation that we traded-off to get
congestion protection that sending the cancel will actually improve - when you have lost the path
for responses to get back, but the requests (like the INVITE) was actually processed.)

So, the question that tips the balance on choosing between verify (for an amended report) and
"hold for document update" is, I believe, "Does this cause a deployment problem".

RjS

On Jan 18, 2011, at 8:14 AM, Adam Roach wrote:

> Yes, it seems correct. I would tag it as accurate, and set the action to "hold for document update".
> 
> /a
> 
> On 1/18/11 02:51, Jan 18, Gonzalo Camarillo wrote:
>> Hi,
>> 
>> Stephen seems to be correct here. The gateway should not send the CANCEL
>> because it has not received any provisional response. I suggest we
>> accept the erratum. Comments?
>> 
(Continue reading)

Gonzalo Camarillo | 18 Jan 16:29 2011
Picon

Re: [Technical Errata Reported] RFC3398 (2580)

Hi,

for the record, I am also OK with "hold for document update".

Cheers,

Gonzalo

On 18/01/2011 5:16 PM, Robert Sparks wrote:
> Also,
> 
> The report is not complete - there are other examples in the document with the same bug.
> If you're going to fix one of them by errata, you probably need to fix all of them.
> 
> I agree with "hold for document update". At the worst case, if something sends the CANCEL,
> it's introducing traffic into a network that is too congested to handle the CANCEL. In the best case,
> it introduces a message (and its retransmissions) that get ignored, or a single message that gets
> an error response. (And for completeness, there is one situation that we traded-off to get
> congestion protection that sending the cancel will actually improve - when you have lost the path
> for responses to get back, but the requests (like the INVITE) was actually processed.)
> 
> So, the question that tips the balance on choosing between verify (for an amended report) and
> "hold for document update" is, I believe, "Does this cause a deployment problem".
> 
> RjS
> 
> On Jan 18, 2011, at 8:14 AM, Adam Roach wrote:
> 
>> Yes, it seems correct. I would tag it as accurate, and set the action to "hold for document update".
>>
(Continue reading)

Internet-Drafts | 19 Jan 16:15 2011
Picon

I-D Action:draft-ietf-sipping-nat-scenarios-14.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : Best Current Practices for NAT Traversal for Client-Server SIP
	Author(s)       : C. Boulton, et al.
	Filename        : draft-ietf-sipping-nat-scenarios-14.txt
	Pages           : 67
	Date            : 2011-01-19

Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NATs) is a
complex problem.  Currently there are many deployment scenarios and
traversal mechanisms for media traffic.  This document provides
concrete recommendations and a unified method for NAT traversal as
well as documenting corresponding flows.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.
(Continue reading)

Ong, Lyndon | 18 Jan 16:35 2011

Re: [Technical Errata Reported] RFC3398 (2580)

That would be fine with me also.

Cheers,

Lyndon

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo <at> ericsson.com] 
Sent: Tuesday, January 18, 2011 7:30 AM
To: Robert Sparks
Cc: Adam Roach; Jon Peterson; Ong, Lyndon; Mary Barnes; sjames_1958 <at> yahoo.com; sipping LIST
Subject: Re: [Technical Errata Reported] RFC3398 (2580)

Hi,

for the record, I am also OK with "hold for document update".

Cheers,

Gonzalo

On 18/01/2011 5:16 PM, Robert Sparks wrote:
> Also,
> 
> The report is not complete - there are other examples in the document with the same bug.
> If you're going to fix one of them by errata, you probably need to fix all of them.
> 
> I agree with "hold for document update". At the worst case, if something sends the CANCEL,
> it's introducing traffic into a network that is too congested to handle the CANCEL. In the best case,
> it introduces a message (and its retransmissions) that get ignored, or a single message that gets
(Continue reading)

Worley, Dale R (Dale | 19 Jan 18:04 2011

Re: [Technical Errata Reported] RFC3398 (2580)

________________________________________
From: sipping-bounces <at> ietf.org [sipping-bounces <at> ietf.org] On Behalf Of Robert Sparks [rjsparks <at> nostrum.com]

The report is not complete - there are other examples in the document with the same bug.
If you're going to fix one of them by errata, you probably need to fix all of them.
_______________________________________________

Yeah -- that's covered in my errata report of 21 Dec (resent 3 Jan):

http://www.ietf.org/mail-archive/web/sipping/current/msg17732.html

======================================================================
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:
(Continue reading)


Gmane