Re: [Technical Errata Reported] RFC4666 (2518)

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 protected]] 
Sent: Tuesday, September 14, 2010 10:35 PM
To: Robert Sparks; Ong, Lyndon
Cc: David Laight; RFC Errata System; [email protected];
[email protected]; [email protected];
[email protected]
Subject: RE: [Sigtran] [Technical Errata Reported] RFC4666 (2518)

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 protected]


Regards
Suyash Karmarkar

-----Original Message-----
From: Robert Sparks [mailto:[email protected]] 
Sent: Tuesday, September 14, 2010 9:51 PM
To: Ong, Lyndon
Cc: Karmarkar Suyash; David Laight; RFC Errata System;
[email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: [Sigtran] [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:[email protected]] 
> Sent: Tuesday, September 14, 2010 4:01 AM
> To: David Laight; RFC Errata System; [email protected];
> [email protected]; [email protected];
> [email protected]; Ong, Lyndon
> Cc: [email protected]
> 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 protected]] 
> Sent: Tuesday, September 14, 2010 4:24 PM
> To: RFC Errata System; [email protected];
[email protected];
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]; 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: [email protected] 
>> [mailto:[email protected]] On Behalf Of RFC Errata System
>> Sent: 14 September 2010 11:54
>> To: [email protected]; [email protected]; 
>> [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected]; 
>> [email protected]
>> 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 <[email protected]>
>> 
>> 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
>> _______________________________________________
>> Sigtran mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/sigtran
>> 
> 
> 
>