RE: [Sigtran] Conflict in IUA and DUA management messageformessagetype 5

["Ong, Lyndon" <[e-mail]>]

Hi Folks,

My thought at this point is that we would be unlikely to get further
comments on the RFC, so we should put together a short draft and
get it approved as an RFC to correct the error.  However, I'll open
the floor to see if people expect to have other fixes.

Cheers,

Lyndon 

-----Original Message-----
From: Michael Tuexen [mailto:[e-mail]] 
Sent: Monday, June 12, 2006 6:29 AM
To: Ken A Morneault (kmorneau)
Cc: [e-mail]
Subject: Re: [Sigtran] Conflict in IUA and DUA management
messageformessagetype 5

Hi Ken,

see my comment in-line.

Best regards
Michael

On Jun 12, 2006, at 3:02 PM, Ken A Morneault (kmorneau) wrote:

>
>
> This issue was raised some time ago.  We came to the same conclusion 
> then as Michael did:  the TEI Query request would need to change to a 
> value of 8.
>
> Lyndon - can we request to have the RFC updated with this fix?
A RFC can not be changed. The only way is to produce a new RFC...
We can have a small RFC just stating that, but it has to start as an ID.
We can, of course, wait for more issues to progress such an ID to the
RFC.

Lyndon, what do you suggest? Should we just write this very small ID and
progress it to RFC status?
>
> Regards,
>
> Ken
>
> -----Original Message-----
> From: Michael Mentz [mailto:[e-mail]]
> Sent: Monday, June 12, 2006 3:50 AM
> To: Michael Tuexen; ankur arora
> Cc: [e-mail]
> Subject: RE: [Sigtran] Conflict in IUA and DUA management message 
> formessagetype 5
>
> Hey Ankur, Michael, all
>
> Yes, something has to change, looking at the timeline of events in 
> this class :-
>
>
> Starting with RFC3057, the MGMT class was :-
>
>     Management (MGMT) Messages
>
>        0        Error (ERR)
>        1        Notify (NTFY)
>        2        TEI Status Request
>        3        TEI Status Confirm
>        4        TEI Status Indication
>      5 to 127   Reserved by the IETF
>    128 to 255   Reserved for IETF-Defined MGMT extensions
>
> DUA RFC4129, then extended this by adding :-
>
>         5        DLC Status Request
>         6        DLC Status Confirm
>         7        DLC Status Indication
>
> RFC4233 comes out with :-
>
>     Management (MGMT) Messages
>
>        0        Error (ERR)
>        1        Notify (NTFY)
>        2        TEI Status Request
>        3        TEI Status Confirm
>        4        TEI Status Indication
>        5        TEI Query Request
>      6 to 127   Reserved by the IETF
>    128 to 255   Reserved for IETF-Defined MGMT extensions
>
>
>
> Oops - RFC4233 should be :-
>
>     Management (MGMT) Messages
>
>        0        Error (ERR)
>        1        Notify (NTFY)
>        2        TEI Status Request
>        3        TEI Status Confirm
>        4        TEI Status Indication
>      5 to 7     Defined in RFC4129 (DUA Status)
>        8        TEI Query Request
>      9 to 127   Reserved by the IETF
>    128 to 255   Reserved for IETF-Defined MGMT extensions
>
> Not exactly pretty, but correct.
>
> In the meantime, there is a decision to resolve as to how to handle 
> implementations that use (or share) the MGMT Type 6.
> (ie, is it a DUA Status Request or a TEI Query Request)?
>
> The SCTP Payload ID could be used, but is not a 100% guarantee.
> (Consider ASP with some Q931 and some DPNSS interfaces, if the 
> implementation is good, then the SCTP PPID would reflect the type of 
> interface as the message relates to an InteraceID) IMO, I wouldn't 
> trust this too much, but would aid in decision making.
>
> I've looked DLCI encoding to see if there is a difference there, but 
> no avail.
>
> In DUA, the DLCI field has a different format, in accordance with the
>    ND1301:2001/03 (formerly BTNR 188) [2].
>
>          0                   1
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |0 0 0 0 0 0 0|V|0|Channel No.|1|
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> RFC4233 (S = SPR)
>
>          0                   1
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |    SAPI     |S|0|     TEI   |1|
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> No 100% way to resolve it in the spec from what I can see, your 
> decision in how to handle it would have to be based on the 
> provisioning of the interface.
>
> Cheers,
> Mike
>
>
>
> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]]
> Sent: 10 June 2006 10:40
> To: ankur arora
> Cc: [e-mail]
> Subject: Re: [Sigtran] Conflict in IUA and DUA management message for 
> messagetype 5
>
> This is a bug... I would suggest to change the number for DUA or IUA 
> in an Implementers guide. I also don't know how to handle it in 
> Wireshark...
>
> Best regards
> Michael
>
> On Jun 10, 2006, at 8:39 AM, ankur arora wrote:
>
>> Hi,
>>
>> The IUA latest RFC (RFC 4233) introduced a new management message 
>> "TEI
>
>> query request" with message type 5.
>> Also, DUA RFC have "DLC Status Reuest" message with same message type

>> 5.
>> So, Management messages for IUA (RFC 4233) and DUA have an overlap 
>> i.e. the same message type has been used twice.
>> Message Group 0 & Message Type 5
>> IUA - TEI query request, and
>> DUA - DLC status request.
>>
>> Also according to DUA rfc ,section 4
>> "As an option, the IUA value for SCTP Payload Protocol ID MAY also be

>> used for DUA, for instance, if one wanted to backhaul ISDN and DPNSS 
>> over the same SCTP association."
>> Then how it can be identified whether message received from SCTP with

>> message type 5 is an IUA "TEI query request" or a DUA "DLC Status 
>> Reuest".
>>
>> Regards
>> Ank Arora
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around 
>> http://mail.yahoo.com
>>
>> _______________________________________________
>> Sigtran mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
> _______________________________________________
> Sigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran
>


_______________________________________________
Sigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sigtran