Subject: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

From: RFC Errata System <[email-masked]>
Date: Tue, 14 Sep 2010 03:53:46 -0700 (PDT)

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 <[email-masked]>

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
different adaptation layers:

Registration Result                 0x0014,
Deregistration Result               0x0015,
Local Routing Key Identifier        0x0018,

Notes
-----
As the above three parameters mentioned are used for the same purpose in RFC 3868 and in RFC 4666. So the above parameters in RFC 4666 Section 3.2, the M3UA-Specific parameters can be considered to move them into the common parameters section 3.2 of RFC 4666 with the above sepecified values.

The advantage could be, for one who implements both SUA & M3UA can use the same encoding and decoding mechanisms/code for both the implementations.

Instructions:
-------------
This errata 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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4666 (draft-ietf-sigtran-rfc3332bis-06)
--------------------------------------
Title               : Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
Publication Date    : September 2006
Author(s)           : K. Morneault, Ed., J. Pastor-Balbas, Ed.
Category            : PROPOSED STANDARD
Source              : Signaling Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: "David Laight" <[email-masked]>
Date: Tue, 14 Sep 2010 11:54:20 +0100

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

	David 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of RFC Errata System
> Sent: 14 September 2010 11:54
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: [Sigtran] [Technical Errata Reported] RFC4666 (2518)
> 
> 
> As the above three parameters mentioned are used for the same 
> purpose in RFC 3868 and in RFC 4666. So the above parameters 
> in RFC 4666 Section 3.2, the M3UA-Specific parameters can be 
> considered to move them into the common parameters section 
> 3.2 of RFC 4666 with the above sepecified values.
> 
> The advantage could be, for one who implements both SUA & 
> M3UA can use the same encoding and decoding mechanisms/code 
> for both the implementations.
> 
> Instructions:
> -------------
> Title               : Signaling System 7 (SS7) Message 
> Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sigtran
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Sep 2010 05:22:22 -0600

David,

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

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
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 14 Sep 2010 13:25:13 +0200

Hi Lyndon,

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

Best regards
Michael

---

From: "Ken Morneault (kmorneau)" <[email-masked]>
Date: Tue, 14 Sep 2010 06:50:44 -0500

I agree with David.  We cannot make this change.

Regards,

Ken 

-----Original Message-----
From: David Laight [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 6:54 AM
To: RFC Errata System; Ken Morneault (kmorneau);
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

	David 

> The following errata report has been submitted for RFC4666, "Signaling

> System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer 
> (M3UA)".
> 
> As the above three parameters mentioned are used for the same purpose 
> in RFC 3868 and in RFC 4666. So the above parameters in RFC 4666 
> Section 3.2, the M3UA-Specific parameters can be considered to move 
> them into the common parameters section
> The advantage could be, for one who implements both SUA & M3UA can use

> the same encoding and decoding mechanisms/code for both the 
> implementations.
> 
> Instructions:
> -------------
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
>

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 14 Sep 2010 10:41:42 -0400

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

Lyndon

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 4:25 AM
To: Ong, Lyndon
Cc: [email-masked]; [email-masked]; Gonzalo Camarillo; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Subject: Re: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

Hi Lyndon,

Best regards
Michael

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 14 Sep 2010 12:06:55 -0400

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:[email-masked]] 
Sent: Tuesday, September 14, 2010 4:01 AM
To: David Laight; RFC Errata System; [email-masked];
[email-masked]; [email-masked];
[email-masked]; Ong, Lyndon
Cc: [email-masked]
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.

Can you please elaborate your comment?

Thanks in advance.

Regards,
Suyash Karmarkar

-----Original Message-----
From: David Laight [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 4:24 PM
To: RFC Errata System; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Karmarkar Suyash
Subject: RE: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

	David

---

From: "Karmarkar Suyash" <[email-masked]>
Date: Tue, 14 Sep 2010 16:30:48 +0530

Hi,

Thanks in advance.

Regards,
Suyash Karmarkar

-----Original Message-----
From: David Laight [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 4:24 PM
To: RFC Errata System; [email-masked]; [email-masked];

	David

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Sep 2010 11:21:08 -0500

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

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 14 Sep 2010 20:24:06 +0200

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Sep 2010 15:05:37 -0600

Karmarkar,

Their purpose might appear the same, but their internals and
functionality is rather different.  M3UA registration and keys are
routing keys, whereas SUA's are entries in an address mapping
function.  Even if one made the parameter tags the same, the value
portion and the operations that need to be performed on them are
quite different.

We did manage to rationalize and make common parameter tags that
made more sense (like routing context).

If you look back in the sigtran mail archives you will see that this
very issue was discussed last in Jul19 2006.

Take a look at my response to that note under the subject:
"Are RKM parameters common between adaptation layers?" from
19 Jul 2006 00:13:31 -0600 and you will see reference to the
discussion ladders on common parameters back to 2001.

The short story: the current parameter tag values represent
concensus of the WG after lengthly deliberations, discussion and
input from many quarters.

I think that the proper thing to do is to withdraw the errata.

--brian

Karmarkar Suyash wrote:                  (Tue, 14 Sep 2010 16:30:48)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 15 Sep 2010 10:59:42 -0400

Hi Suyash,

No problem, as Robert said the list is a good way of circulating your
ideas and getting feedback (although comments are not always gentle).

Best regards,

Lyndon

-----Original Message-----
From: Karmarkar Suyash [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 10:35 PM
To: Robert Sparks; Ong, Lyndon
Cc: David Laight; RFC Errata System; [email-masked];
[email-masked]

Hi Lyndon,

Thanks for the response.
Actually, the RFC-editor page does not have a suggestions option, I
wanted to post the query as suggestion If you look at the errata details
I mentioned " can be considered" . but there is no option to do so.

I realized later that many vendors would have already implemented the
sigtran stack and the changes would be huge. ( My mistake - :-( I should
have realized this earlier even before posting the suggestion).

RjS,
Agreed. In future In case of doubts/suggestions would mail to
[email-masked]

Regards
Suyash Karmarkar

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 9:51 PM
To: Ong, Lyndon
Cc: Karmarkar Suyash; David Laight; RFC Errata System;
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

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

---

From: "Karmarkar Suyash" <[email-masked]>
Date: Wed, 15 Sep 2010 11:05:00 +0530

Hi Lyndon,

Thanks for the response.

RjS,

Regards
Suyash Karmarkar

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 9:51 PM
To: Ong, Lyndon
Cc: Karmarkar Suyash; David Laight; RFC Errata System;

RjS

---

From: "Karmarkar Suyash" <[email-masked]>
Date: Wed, 15 Sep 2010 11:17:26 +0530

Hi Brain,

I agree with your comments entirely. Thanks a lot for the explanation.

Regards
Suyash Karmarkar

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:36 AM
To: Karmarkar Suyash
Cc: David Laight; RFC Errata System; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

Karmarkar,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/