Re: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt

... and another reason why we may want two different error codes for "not
allowed" or "not implemented" use cases is that we now have an "origin"
TURN draft, and the TURN server may reject or allow Mobility using the
"origin" field (according to a server policy). Then probably "not
implemented" error would be an incorrect error code if the "mobile
allocate" request was rejected because of the origin attribute.

But at the same time I am not sure that the "origin" field was really
designed as an input for "hard" security decisions (like allowing or
disallowing a piece of functionality). This is a grey area between
different drafts, and may be the authors or both "origin" draft and
"mobility" draft would like to clarify that, for future implementations.

Thanks
Oleg

On Thu, Feb 6, 2014 at 9:13 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:

> I have comments regarding the new Error Code "Mobility Forbidden".
>
> 1) Section 5.1.4:
>
> Comment: remove two TBDs, if the error code has been already determined.
>
> 2) Section 7:
>
> and to add a new STUN error code "Mobility Forbidden" with the value
> 501 to the STUN Error Codes registry [iana-stun].
>
>
> Comment: I am not sure that 501 is the right code to be used. In SIP and
> HTTP, 5xx errors are usually about a server code problem of some sort; 501
> means "not implemented". That may be not exactly accurate. A mobility-aware
> TURN server may reject the request simply because the administrator does
> not allow it., and the server did not encounter an error. The reason why
> the server reject the request is rather "not allowed" (which is the error
> code 405).
>
> May be be, the right approach would be to introduce two separate error
> codes here: 405 "not allowed" (the server implements mobility but the
> administrator forbade it) or 501 "not implemented" (the server knows about
> mobility but it has no implementation for that). If the server truly is not
> aware about mobility at all, the server will send no MOBILITY-TICKET in the
> server response. Those are three distinct use cases: 405, 501 and an
> "ignorant" server.
>
> Thanks
> Oleg
>
>
>
> On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (tireddy) <
> tireddy@cisco.com> wrote:
>
>> Revised draft-wing-mmusic-ice-mobility-06 has been published. It
>> addresses the comments received for Mobility using TURN and a new section
>> with implementation details. Further comments and suggestions are welcome.
>>
>> Thanks and Regards,
>> -Authors.
>>
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Wednesday, February 05, 2014 7:44 PM
>> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth
>> Patil (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal
>> Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
>> Subject: New Version Notification for
>> draft-wing-mmusic-ice-mobility-06.txt
>>
>>
>> A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt
>> has been successfully submitted by Tirumaleswar Reddy and posted to the
>> IETF repository.
>>
>> Name:           draft-wing-mmusic-ice-mobility
>> Revision:       06
>> Title:          Mobility with ICE (MICE)
>> Document date:  2014-02-05
>> Group:          Individual Submission
>> Pages:          21
>> URL:
>> http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility/
>> Htmlized:
>> http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-06
>>
>> Abstract:
>>    This specification describes how endpoint mobility can be achieved
>>    using ICE.  Two mechanisms are shown, one where both endpoints
>>    support MICE and another where only one endpoint supports MICE.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>>
>
>