Re: [STDS-802-21] LB 4b comment resolution
Hi David,
comments inline
On Wed, May 18, 2011 at 23:51, Cypher, David E. <david.cypher@xxxxxxxx> wrote:
> Comment 27. Line 32; Relating to MIIS.
>
> You are correct that the MN while on a DO network cannot query the MIIS.
>
> However if the MN is not on a DO network, and wants to query the MIIS about
> other available networks (e.g DO) which to hand off to should not it be able
> to at least know that it is a DO network?
>
Completely agree
>
>
> Here is what I can trace from the MIIS
>
> IE_NETWORK_TYPE => NETWORK_TYPE (Table 10, 6.5.4)
>
> Under NETWORK_TYPE (Table F.13) which is a sequences of three choices.
>
> The first choice is NULL or LINK_TYPE (your amendment added three types of
> networks: DVB, T-DMB, and ATSC-M/N)
>
> The second choice is NULL or SUBTYPE (your amendment does not include any
> changes/additions to table F.14 on Subtype)
>
> Should it? I think so, especially since in
> the description one is pointed to Table F.14 for details.
>
Please refer to contribution
https://mentor.ieee.org/802.21/dcn/11/21-11-0080-00-bcst-suggested-remedy-network-types.docx
In this contribution we have added DVB, T-DMB, and ATSC-M/N as
subtypes of the Wireless Other Network Type. The logic behind this
contribution, is that as you pointed out, there is no RADIUS NAS-Port
Type defined for these technologies. So in order to maintain the table
synched with current RADIUS table, we decided to add these techs as
subtypes of Wireless Other.
The other approach would be the one you are suggesting, the problem
that I see with it, is that if we want to maintain synchronization
with RADIUS, we will need to use the reserved bits (e.g. bit 4-14 of
table F.14) to carry the info on DO technologies. Hence, using the
reserved bits, this information will be completely hidden for a legacy
.21. With our approach, the terminal will at least know there is some
kind of network, of type Wireless Other..
> Minimally it should contain three new rows
> (one for each of the networks) with N/A in the network subtype column.
>
> The third choice is NULL or TYPE_EXT (basically at the SDOs discretion)
>
>
>
> Thank you for your reconsideration.
I really think the solution we propose is the easiest to adapt, of
course if you think it is not good enough and would be better to have
three new rows, we can change this in the next recirculation..
BR and thanks for the comments
Antonio
>
>
>
> David Cypher
>
>
>
> From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, May 17, 2011 5:36 PM
> To: STDS-802-21@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-21] LB 4b comment resolution
>
>
>
> Hello all,
>
>
>
> Please take a look at the resolved comments from the 4b Letter Ballot and
> let us know if you have any comments:
>
> https://mentor.ieee.org/802.21/dcn/11/21-11-0078-02-bcst-lb4b-comments.xls
>
>
>
> Tomorrow the Task Group will concentrate efforts on the Motions required to
> issue a new recirculation for the next plenary meeting.
>
>
>
> Regards,
>
>
>
> Juan Carlos Zuniga
>
> 802.21b TG Chair
--
Antonio de la Oliva
Visiting Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749