Re: D103 design draft issue: terminology alignment

[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html]

Jari Arkko writes:
> >>(Also, I'm not sure the protocol we have actually communicates
> >>the address preferences. The initiator makes a decision, but
> >>does the ordering in an address update indicate preference?)
> >
> >In current protocolwe do not communicate that, but we did consider
> >options where we did communicate those, and we do describe those in
> >the document, and then we say we ended up using initiator decides. 
> >  
> >
> Right. Can we make this clearer in the design document?
...
> I understand. But you said "MOBIKE *protocol* should be
> able to perform ...".

I added text there "(not all of those are done explictly by the
current protocol)".

> >No, and it does not try to be aligned. We are describing generic
> >scenario, the actual protocol work differs from this generic scenario,
> >and we do not fully support this in the protocol we selected. As in
> >our case the initiator decides the preferences then the responders
> >preferences are ignored in our protocol. 
> >  
> Has that been made clear later in the document?

I do not think we explictly mention that we ignore responder
preferences, or that we assume that the initiator uses its own
preferences when selecting which address to use next. Do you think we
would really need that?

> >Nope. IPsec engine is not defined in the RFC 2401 or in the RFC 4301.
> >  
> >
> Right, that was my complaint, but my e-mail missed the
> word "not" :-)
> 
> >I have normally used IPsec engine to refer to the "kernel" side of the
> >IPsec implementation, i.e. things related to the actual packets, SAD,
> >and partly SPD too (i.e. those parts of SPD which are not related to
> >the IKE or policy management).
> >
> >IPsec implementation is bit wrong, as MOBIKE can be considered as part
> >of IPsec implementation too... as it is IKEv2 extension and IKEv2 is
> >part of IPsec implementation (i.e. part of the IPsec architecture
> >defined in RFC 4301).
> >
> >If you have better term to use than IPsec engine, I can switch to
> >that, but I myself cannot think one now. 
> >  
> >
> I see your problem. How about "the packet processing
> module of the IPsec implementation"?

Done. 

> >>>   In order to address certain failure
> >>>   cases, MOBIKE should perform connectivity tests between the peers
> >>>   (potentially over a number of different paths).
> >>>      
> >>>
> >>I think they are called "path tests" in the protocol draft.
> >>    
> >>
> >
> >I think path tests is bad name, as we are not testing paths, we are
> >testing connectivity between two addresses. 
> >  
> >
> Perhaps, but we are not debating the name -- what I'm
> saying is that you should align the terminology with the
> protocol draft (even if you might think that the term in
> the protocol draft was wrong). Otherwise it'll be confusing.

I tought we decided that the protocol draft should be following the
design draft terminology, not the other way around. Actully in the
issue 29 of the protocol draft you said:

"Jari Arkko (2005-07-14):

My feeling is that, for practical reasons, we should try to
get rid of the term path, unless we use it in the route-included
sense. There are too many people that will complain when
they will see their favorite term misused :-)"

And then Pasi commented:

"Pasi Eronen (2005-07-14):

Well, it certainly seems so...  

I've now changed those instances of "path" that don't really 
consider the route to something else (but I've kept expressions
like "paths that contain NATs", "off-path", or "currently used 
path has stopped working", which are more about the route
than just a pair of addresses). CHANGE_PATH notification was
renamed to UPDATE_SA_ADDRESSES."

I remember that we changed away from path in the desing draft around
same time, and then we started using terms like "IP address pairs" and
so on.

As the "connectivity tests" do not really care about the actual
routers on the path, so I do not think it should be called "path
tests":

"Pasi Eronen (2005-07-18):

Clarified some things, now avoids using the word "path" in senses that
don't really consider the route taken by the packets."
-- 
[email protected]