Re: D103 design draft issue: terminology alignment

Tero Kivinen wrote:

>>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)".
>  
>
Ok.

>  
>
>>>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?
>  
>
I think it is useful to point out the differences between
the abstract discussion you have in the design document
and the specific capabilities of the protocol as it turned
out to be. But I'll leave it you as the editor to worry
about the details...

>>>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":
>  
>
Ah, now I see what your problem was. I still stand
by the earlier decisions about not using the word
path. But... the protocol document is done (approved
by IESG) and we're not editing it anymore unless
there's a major reason to do so.

My original issue was that the protocol spec calls
the testing function "path testing". So if we are
specifically referring that functionality then perhaps
we should use the same term. Otherwise lets use
a more appropriate term.

Oh well, I'm not sure this is easily fixable given no
edits to the protocol draft. I'll let you decide what
to do.

--Jari