RE: [802.21] IETF draft on IS
Hi Yoshi,
Thanks for the good comments. Responses inline.
Regards,
Srini
>General comment: I think the requirements described in
>21-06-0348-05-0000-Higher-Layer_IS-Requirements are more
>concise and mature than this version.
Srini> The issue is not to be concise, as much as we want to be as
clearly understood. More below.
>> o Distinguish between the packet source and query source (allow
>> proxies).
>
>This depends on the proxy model used by MIIS. What proxy
>model is assumed here?
There are no general assumptions but if you think that a certain proxy
model will not work with this requirement then we should address it.
Clearly, the packet source uses the transport header while the query
source is transport independent.
>>
>> o Optionally allow for multiple queries per transport session.
>
>This functionality is provided by MIIS (i.e., multiple outstanding
>queries can be distinguished by Transaction ID). We don't need to
>have this as a IS transport requirement.
Srini> I agree with you on this based on a certain transport assumption
e.g. TCP or UDP is fine. If "some" transport is chosen, then we want to
ensure that a source can send multiple queries over the same transport
setup and not have to reestablish the transport session again. If you
think this is a stretch, I could remove it.
>>
>> o Optionally ensure compatability between the
>information services
>> transport, and those required for Event and Command Services.
>
>What does exactly "compatibility" mean?
Srini> An insinuation to design a common transport protocol for all MIH
services.
>Why compatibility needs to be ensured between IS transport and ES/CS
>transport?
Srini> So we can have one transport model, reduces standardization time
and scales implementation.
>> o Optionally ensure compatability between the
>information services
>> discovery mechansisms, and those required for Event and Command
>> Services over IP.
>
>What does exactly "compatibility" mean?
Srini> same as above
>>
>> o Allow for distinct classes Information Servers to be
>discovered.
>
>I don't understand this. Why this is needed?
Srini> If we allow for different levels of information servers e.g.
basic vs extended set, then this information can be provided at the
discovery stage. But, if we have this capability in 802.21 (we did not
have this until the Denver meeting), we should reconsider this
requirement.
>>
>> o Allow for context sensitive IS server discovery (per AP, per
>> visited Subnet, per Mobile).
>
>I don't understand this. Why this is needed?
>
Srini> the examples are probably not good. But this is to be able to
discover IS servers in specific networks.
>> o Optionally allow discovery messages being transported
>through NAT.
>> In this case, support for requester specific knowledge needs to
>> use both the NAT source address and the query original address.
>
>The second sentence looks like a solution not a requirement. I'd
>suggest removing the sentence.
Srini> okay, no problem. Will remove.
>> o Protect against IS-Server and wireless device
>impersonation (with
>> authentication).
>
>This looks like a requirement on peer entity authentication, right?
Srini> yes
>>
>> o Provide confidentiality of query and response contents.
>
>Is this a mandatory requirement or an optional requirement? I
>think this can be an optional requirement.
Srini> the transport MUST provide all security requirements. It is
applicable to all payload, not just req/resp. We should correct it.
>>
>> o Protect the identity of a querier against eavesdroppers.
>
>Do you mean the identity of a querier is carried in IS messages?
>If so, why it is needed?
Srini> This is a transport requirement, this is say that no MIHF level
identifiers are carried in the transport headers without
confidentiality. A little paranoid? I agree.
>>
>> o Protect IS-Server and discovery resources against denial of
>> service.
>
>This requirement is too blur. More specific requirement on
>denial of service would be required.
Srini> We can elaborate. Please suggest something.
>>
>> o Minimize computational and transmission resources for mobile
>> clients.
>
>Do you mean IS transport may involve computation on IS queries?
>Please clarify.
Srini> the requirement is to design a transport with fewer computational
requirements (e.g. not heavy encryption mechanisms) and not consume a
lot of memory for keeping transport state information. This is a general
requirement for any protocol that will be used by small handheld
mobiles.
>>
>> o Provide compatability with Address or Security Association
>> Mobility management, to allow use of an IS server after host
>> movements without renegotiating an SA.
>
>What do you mean by "compatability with Address or Security
>Association Mobility management"? Please clarify.
Srini> We need to clarify this, it seems to be missing something. The
general idea is to reutilize SA due to mobility. Actually, IETF memebers
commented that this may not be posisble but a fast SA can be requested.
>>
>> o Allow for security services to be diabled.
>
>This is a strange requirement. Clarificaiton is required.
Srini> This is to make transport security optional. Please check with
subir for more details (since it came from him).
>>
>> o Changes to the IS payload should not affect the security
>> mechanisms defined in the underlying transport
>mechanism to ensure
>> protocol modifications and evolutions defined in payload.
>>
>>
>
>Regards,
>Yoshihiro Ohba
>