Re: [MULTIMOBSEC-API] feedback from shim-api-00.txt

El 16/05/2006, a las 14:14, Miika Komu escribió:

> On Tue, 16 May 2006, marcelo bagnulo braun wrote:
>
>> El 16/05/2006, a las 0:01, Miika Komu escribió:
>>
>>> On Mon, 15 May 2006, Shinta Sugimoto wrote:
>>>> Mm, I am not sure if I want to be so specific at the beginning of
>>>> the document.  Wouldn't it be fine just to say "Socket API" ?
>>> According to the literature, it is "sockets API" with an "s".
>>> Maybe you can say in intro that the draft is illustrated using C  
>>> language. It is not a bad choice because the API bindings for other  
>>> languages are based on C anyway.
>>>> Ok, I will use 'event based'.  Does following sound better ?
>>>> <t>Notification from application to shim layer about outage.
>>>> Application should be able to inform shim layer about outage
>>>> in its communication.  Note that the notification is made
>>>> in event based manner.  The cause of outage could be for instance
>>>> a problem of network interface, congestions on the path and so on.
>>>> ICMP error messages delievered to the upper layer protocol is
>>>> normally clue for application to detect outgae.  REAP module
>>>> may be triggered by this indication to invoke procedure of
>>>> path exploration.</t>
>>> s/outgae/outage/. Again, it is undefined what kind of outage is in  
>>> question. Otherwise it is fine.
>>
>> i guess that it is any kind of outage that makes that an address pair  
>> is no longer working. And an address pair is said to be working is  
>> packet containing the first address from the pair as source address  
>> and the second address from the pair as destiantion address can  
>> safely travel from the source to the destiantion.
>
> Something like this should be also in the text.
>

ok

> (Maybe I am getting too detailed already now in the beginning)
>
>>>>>> However, this approach does not help the case where ID is not in  
>>>>>> form of
>>>>>> IP address (e.g.  HIT in HIP case).
>>>>> In HIP, a HIP enabled resolver can be used for setting up context  
>>>>> prior to
>>>>> the actual connection to HIT. Alternatively, DHTs support look-up  
>>>>> of
>>>>> non-hierarchical identifiers, such as HITs.
>>>> Yes.  But I think those (HIP enabled resolver and the DHT support)  
>>>> are
>>>> still in some HIP implementation or HIP experts' mind, aren't they ?
>>>> (I may be wrong, correct me if so)
>>>> So I was not sure if we could give conclusive statements about
>>>> these problems.
>>> I don't understand. HIP enabled resolvers and DHT support are mostly  
>>> supported by all of the three public implementations
>>
>> interesting.... which implementations are those?
>
> http://infrahip.hiit.fi/
> http://www.hip4inter.net/
> http://www.openhip.org/
>
> (I am not sure about the DHT support for Ericsson, you can ask  
> Kristian for details)
>
>>>> As for me, I am not sure if DHT based name resolution service could  
>>>> be easily done.
>>> It has been already done, but not really deployed in a large scale.  
>>> And also it has not been standardized in the IETF, but neither has  
>>> been e.g. skype :)
>>
>> i am not really following what comments you think there should be  
>> included about DHT?... could you send text so we can understand more  
>> precisely what you mean?
>
> I believe I misunderstood the context term. In HIP and BTNS, the  
> context really is a pair of IPsec SPs and the associated SAs, not a  
> "mapping" like I described earlier. The mapping I was referring to  
> means a HIT-to-IP mapping for the host.
>
> So, in section "6.1.  Initial Contact", please remove the last  
> sentence about HIP to avoid confusing things. Let's add a separate,  
> new paragraph after that:
>
> ---text begins
>
> In HIP, resolving HITs to IP addresses using DNS is not feasible  
> because HITs do not contain any hierarchical information. To migitate  
> this problem, there are few alternatives. First, resolver library on  
> end-host can modified to communication HIT-to-IP mappings with HIP  
> software module. Second, a distibuted hash table (DHT) service can be  
> used for storing and looking up the the mappings because it supports  
> non-hierarchical identifiers, such as HITs [*]. Third, it is possible  
> to use IP addresses in legacy applications as described in [**].
>
> [*] http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt
> [**]  
> http://www.ietf.org/internet-drafts/draft-henderson-hip-applications 
> -02.txt
>
> ---text ends
>
> We should not really argue in the draft what approach is good and what  
> is bad, at least when it comes to HITs and DHT. Let's just list the  
> alternatives and give references, otherwise the discussion is just  
> getting into a sidetrack.
>

agree

regards, marcelo

> -- 
> Miika Komu              miika@iki.fi          http://www.iki.fi/miika/

_______________________________________________
MULTIMOBSEC-API mailing list
MULTIMOBSEC-API@ietf.org
https://www1.ietf.org/mailman/listinfo/multimobsec-api