Signaling Transport (sigtran)

RFC Errata System | 14 Sep 2010 12:53

[Technical Errata Reported] RFC4666 (2518)


The following errata report has been submitted for RFC4666,
"Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=2518

--------------------------------------
Type: Technical
Reported by: Suyash Karmarkar <skarmarkar <at> sonusnet.com>

Section: 3.2.

Original Text
-------------
3.2. Variable-Length Parameter Format

M3UA-Specific parameters. These TLV parameters are specific to the
M3UA protocol:

Registration Result                               0x0208
Deregistration Result                             0x0209
Local Routing Key Identifier                      0x020a

Corrected Text
--------------
3.2. Variable-Length Parameter Format

Common Parameters. These TLV parameters are common across the

(Continue reading)

David Laight | 14 Sep 2010 12:54

Re: [Technical Errata Reported] RFC4666 (2518)

Is someone having us on ????
The suggested change will completely break interworking between systems.

	David 

> -----Original Message-----
> From: sigtran-bounces <at> ietf.org 
> [mailto:sigtran-bounces <at> ietf.org] On Behalf Of RFC Errata System
> Sent: 14 September 2010 11:54
> To: kmorneau <at> cisco.com; j.javier.pastor <at> ericsson.com; 
> gonzalo.camarillo <at> ericsson.com; rjsparks <at> nostrum.com; lyong <at> ciena.com
> Cc: sigtran <at> ietf.org; skarmarkar <at> sonusnet.com; 
> rfc-editor <at> rfc-editor.org
> Subject: [Sigtran] [Technical Errata Reported] RFC4666 (2518)
> 
> 
> The following errata report has been submitted for RFC4666,
> "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - 
> User Adaptation Layer (M3UA)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=2518
> 
> --------------------------------------
> Type: Technical
> Reported by: Suyash Karmarkar <skarmarkar <at> sonusnet.com>
> 
> Section: 3.2.
>

(Continue reading)

Brian F. G. Bidulock | 14 Sep 2010 13:22

Re: [Technical Errata Reported] RFC4666 (2518)

David,

David Laight wrote:                             (Tue, 14 Sep 2010 11:54:20)
> Is someone having us on ????
> The suggested change will completely break interworking between systems.
> 
> 	David 

It's probably a misplaced intention.

I attempted to rationalize these common parameter values many years ago for
the same reasons cited (reuse), but the WG would not have it: not even
between _draft_ versions.

As you point out, it is not an errata: it is a non-interoperable and drastic
change in code-points.  Don't worry, however, I don't think that IANA will
go changing parameter values without an full RFC demanding it, which will
never happen.

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Michael Tüxen | 14 Sep 2010 13:25

Picon

Re: [Technical Errata Reported] RFC4666 (2518)

Hi Lyndon,

can you work on getting this ERRATA removed? It is wrong.

Best regards
Michael

On Sep 14, 2010, at 12:53 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC4666,
> "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=2518
> 
> --------------------------------------
> Type: Technical
> Reported by: Suyash Karmarkar <skarmarkar <at> sonusnet.com>
> 
> Section: 3.2.
> 
> Original Text
> -------------
> 3.2. Variable-Length Parameter Format
> 
> M3UA-Specific parameters. These TLV parameters are specific to the
> M3UA protocol:
>

(Continue reading)

Ken Morneault (kmorneau | 14 Sep 2010 13:50

Picon

Re: [Technical Errata Reported] RFC4666 (2518)


I agree with David.  We cannot make this change.

Regards,

Ken 

-----Original Message-----
From: David Laight [mailto:David.Laight <at> ACULAB.COM] 
Sent: Tuesday, September 14, 2010 6:54 AM
To: RFC Errata System; Ken Morneault (kmorneau);
j.javier.pastor <at> ericsson.com; gonzalo.camarillo <at> ericsson.com;
rjsparks <at> nostrum.com; lyong <at> ciena.com
Cc: sigtran <at> ietf.org; skarmarkar <at> sonusnet.com
Subject: RE: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

Is someone having us on ????
The suggested change will completely break interworking between systems.

	David 

> -----Original Message-----
> From: sigtran-bounces <at> ietf.org
> [mailto:sigtran-bounces <at> ietf.org] On Behalf Of RFC Errata System
> Sent: 14 September 2010 11:54
> To: kmorneau <at> cisco.com; j.javier.pastor <at> ericsson.com; 
> gonzalo.camarillo <at> ericsson.com; rjsparks <at> nostrum.com; lyong <at> ciena.com
> Cc: sigtran <at> ietf.org; skarmarkar <at> sonusnet.com; 
> rfc-editor <at> rfc-editor.org
> Subject: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

(Continue reading)

Ong, Lyndon | 14 Sep 2010 16:41

Re: [Technical Errata Reported] RFC4666 (2518)

I'll check into this with the A-Ds.

Lyndon

-----Original Message-----
From: Michael Tüxen [mailto:Michael.Tuexen <at> lurchi.franken.de] 
Sent: Tuesday, September 14, 2010 4:25 AM
To: Ong, Lyndon
Cc: kmorneau <at> cisco.com; j.javier.pastor <at> ericsson.com; Gonzalo Camarillo; rjsparks <at> nostrum.com;
sigtran <at> ietf.org; skarmarkar <at> sonusnet.com; RFC Errata System
Subject: Re: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

Hi Lyndon,

can you work on getting this ERRATA removed? It is wrong.

Best regards
Michael

On Sep 14, 2010, at 12:53 PM, RFC Errata System wrote:

> 
> The following errata report has been submitted for RFC4666,
> "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=2518
> 
> --------------------------------------

(Continue reading)

Ong, Lyndon | 14 Sep 2010 18:06

Re: [Technical Errata Reported] RFC4666 (2518)

Hi Suyash,

I think your errata would have been a good comment when the RFCs were
initially being developed, however at this point many people have
already implemented the specifications and would have a problem with
changing the values, their implementations would no longer be compatible
with the specification.  It is not an errata in the sense of an error or
mistake in the specification, that's the way the protocols were
originally designed and currently work.  

Hope this helps.

Cheers,

Lyndon

-----Original Message-----
From: Karmarkar Suyash [mailto:skarmarkar <at> sonusnet.com] 
Sent: Tuesday, September 14, 2010 4:01 AM
To: David Laight; RFC Errata System; kmorneau <at> cisco.com;
j.javier.pastor <at> ericsson.com; gonzalo.camarillo <at> ericsson.com;
rjsparks <at> nostrum.com; Ong, Lyndon
Cc: sigtran <at> ietf.org
Subject: RE: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

Hi,

We plan to implement both the RFCs and we were in thought, why the
parameter values were different for SUA and M3UA as the parameters
functionality happens to be same.

(Continue reading)

Karmarkar Suyash | 14 Sep 2010 13:00

Re: [Technical Errata Reported] RFC4666 (2518)

Hi,

We plan to implement both the RFCs and we were in thought, why the
parameter values were different for SUA and M3UA as the parameters
functionality happens to be same.

Can you please elaborate your comment?

Thanks in advance.

Regards,
Suyash Karmarkar

-----Original Message-----
From: David Laight [mailto:David.Laight <at> ACULAB.COM] 
Sent: Tuesday, September 14, 2010 4:24 PM
To: RFC Errata System; kmorneau <at> cisco.com; j.javier.pastor <at> ericsson.com;
gonzalo.camarillo <at> ericsson.com; rjsparks <at> nostrum.com; lyong <at> ciena.com
Cc: sigtran <at> ietf.org; Karmarkar Suyash
Subject: RE: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

Is someone having us on ????
The suggested change will completely break interworking between systems.

	David 

> -----Original Message-----
> From: sigtran-bounces <at> ietf.org 
> [mailto:sigtran-bounces <at> ietf.org] On Behalf Of RFC Errata System
> Sent: 14 September 2010 11:54

(Continue reading)

Robert Sparks | 14 Sep 2010 18:21

Re: [Technical Errata Reported] RFC4666 (2518)

I will mark this Errata as rejected. 

Suyash - as you can see there are still plenty of folks monitoring this list that can provide feedback on
any other questions/observations you may have on the SIGTRAN specifications. In general, vetting
ideas with a list like is better than starting with an errata entry (Errata should be very rare beasts).

RjS

On Sep 14, 2010, at 11:06 AM, Ong, Lyndon wrote:

> Hi Suyash,
> 
> I think your errata would have been a good comment when the RFCs were
> initially being developed, however at this point many people have
> already implemented the specifications and would have a problem with
> changing the values, their implementations would no longer be compatible
> with the specification.  It is not an errata in the sense of an error or
> mistake in the specification, that's the way the protocols were
> originally designed and currently work.  
> 
> Hope this helps.
> 
> Cheers,
> 
> Lyndon
> 
> 
> 
> -----Original Message-----
> From: Karmarkar Suyash [mailto:skarmarkar <at> sonusnet.com]

(Continue reading)

Michael Tüxen | 14 Sep 2010 20:24

Picon

Re: [Technical Errata Reported] RFC4666 (2518)

On Sep 14, 2010, at 1:00 PM, Karmarkar Suyash wrote:

> Hi,
> 
> 
> We plan to implement both the RFCs and we were in thought, why the
> parameter values were different for SUA and M3UA as the parameters
> functionality happens to be same.
> 
> Can you please elaborate your comment?
Hi Suyash,

I think the reason was to decouple the several protocol specs
to let them evolve at different speed. Now there a several
products out and in production networks. Therefore these
numbers can't be changed anymore without breaking interoperability
with all these implementations out there.

I hope this clarifies things.

Best regards
Michael
> 
> Thanks in advance.
> 
> Regards,
> Suyash Karmarkar
> 
> -----Original Message-----
> From: David Laight [mailto:David.Laight <at> ACULAB.COM]

(Continue reading)

Group

gmane.ietf.sigtran.

Search Archive

Page

1 | 2 | 3 | 4

Articles in period: 35

September 2010

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

回复: Sigtran Digest, Vol 101, Issue 1yu (21 May 2013)
Abort chunk in SCTP (4 May 2013)
Biggest Fake Conference in Computer Science (27 Apr 2013)
Clarification regarding the IPSP behavior for ASPTM messages without R (12 Mar 2013)
bnpptxUT7vTg:-akZ3RR7LlF1Ipc3glBlkmCz3bASr7U6lJrNGA (12 Mar 2013)
(no subject) (10 Feb 2013)
Encoding scheme, Number of Digits parameters, GTI in SUA message (14 Jan 2013)
M3UA: SCON: congestion condition never abates (23 Oct 2012)
Hi (23 Jul 2012)
Need suggestion on the behavior of M3UA on override mode in IPSP (23 Jul 2012)
SIGTRAN: Client-Server model (5 Apr 2012)
SIGTRAN: Client-Server model (5 Apr 2012)
M3UA: IPSP Signalling Point code? (8 Dec 2011)
Routing Context: M3UA (8 Dec 2011)
[SCTP] Multi-Homing Path Failure detection (28 Nov 2011)
Question regarding RFC 4960 Out of the Blue packets (12 Oct 2011)
NTFY message in IPSP single exchange mode (4 Oct 2011)
SCTP Multihoming (26 Sep 2011)
[SIGTRAN:M3UA] Query regarding the behavior of network appearance in t (9 Sep 2011)
Needs clarification on handling of SCON message (4 Sep 2011)
SCON received at ASP from one of SGs (2 Sep 2011)

Archives

3	May 2013
1	April 2013
5	March 2013
1	February 2013
3	January 2013
2	December 2012
8	October 2012
6	July 2012
9	April 2012
6	December 2011
2	November 2011
8	October 2011
21	September 2011
16	August 2011
19	July 2011
6	June 2011
2	May 2011
38	April 2011
25	March 2011
20	February 2011
29	January 2011
25	November 2010
28	October 2010
29	September 2010
2	August 2010
2	July 2010
11	June 2010
11	May 2010
16	April 2010
63	March 2010
7	February 2010
6	January 2010
27	December 2009
20	November 2009
27	October 2009
4	September 2009
3	August 2009
55	July 2009
18	June 2009
5	May 2009
9	April 2009
39	March 2009
31	February 2009
8	January 2009
24	December 2008
7	November 2008
21	October 2008
24	September 2008
5	August 2008
30	July 2008
18	June 2008
19	May 2008
16	April 2008
30	March 2008
33	February 2008
16	January 2008
38	December 2007
48	November 2007
26	October 2007
22	September 2007
37	August 2007
81	July 2007
76	June 2007
76	May 2007
85	April 2007
43	March 2007
51	February 2007
72	January 2007
70	December 2006
173	November 2006
168	October 2006
107	September 2006
43	August 2006
64	July 2006
120	June 2006
99	May 2006
6	April 2006
38	March 2006
266	February 2006
201	January 2006
205	December 2005
169	November 2005
303	October 2005
69	September 2005
13	August 2005
53	July 2005
42	June 2005
10	May 2005
48	April 2005
54	March 2005
38	February 2005
18	January 2005
46	December 2004
12	November 2004
38	October 2004
65	September 2004
95	August 2004
60	July 2004
83	June 2004
118	May 2004
43	April 2004
44	March 2004
105	February 2004
77	January 2004
54	December 2003
15	November 2003
76	October 2003
207	September 2003
112	August 2003
336	July 2003
192	June 2003
182	May 2003
168	April 2003
330	March 2003
453	February 2003
551	January 2003
355	December 2002
186	November 2002
218	October 2002
245	September 2002
127	August 2002
223	July 2002
371	June 2002
453	May 2002
373	April 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template