[shim6] SHIM_LOC_*_PREF and SHIM_LOC_*_SEND (was: Re: review draft version 12)

[Shinta Sugimoto <[e-mail]>]

Sébastien,

Let me address my view on SHIM_LOC_*_PREF and SHIM_LOC_*_SEND.

The two have different meaning.  SHIM_LOC_*_SEND allows application to 
specify source or destination locator, whereas SHIM_LOC_*_PREF allows 
application to specify preference of a given locator.  Yes, they are 
similar in the sense that both allow application to make selection of 
source or destination locator in some form.  However, I prefer to keep 
SHIM_LOC_*_PREF because  I think the concept of handling preference of 
locators is useful, especially in the cases where are multiple choices. 
  But I admit that the current definition of SHIM_LOC_*_PREF in the 
document is not aligned with what is defined in RFC 5533, which is 
confusing.  We should fix this.

as stated in RFC 5533, preference of locator shall be handled in the 
same way as RFC 2782 (DNS SRV).  That is, a preference is represented by 
a pair of priority and weight values.  So, I would suggest to keep 
SHIM_LOC_*_PREF by applying the following changes to the document:

- update definition of locator information structure (shim_locator{}) in 
section 7.1 (define a 16-bit unsigned integer parameter named lc_weight 
to store weight value ranging from 0-65535)
- update texts in section 5.5 and 5.6 to make the definition of 
preference aligned with RFC 5533.
- provide explanations on how ths shim sub-layer would react in the case 
of conflicting situations.  There are at least two situations that we 
should think of.  I think Section 10 (Operational Considerations) would 
be the right place to have these texts.

1) when the application specifies SHIM_LOC_*_SEND specifying a different 
source or destination locator which does not have the highest 
priority/weight specified by the SHIM_LOC_*_PREF, the request made by 
SHIM_LOC_*_SEND must overwrite the prefenrece specified by SHIM_LOC_*_PREF.

2) when the peer provides preference of the locators, that must 
overwrite the preference specified by SHIM_LOC_PEER_SEND or 
SHIM_LOC_PEER_PREF.

does this sound reasonable?

Regards,
Shinta

Sébastien Barré wrote:

> *Section 5.5 and 5.6 : SHIM_LOC_LOCAL_PREF and SHIM_LOC_PEER_PREF: As 
> defined, these options are duplicate of SHIM_LOC_LOCAL_SEND and 
> SHIM_LOC_PEER_SEND. Thus I would remove two of them, and keep preferably 
> the SHIM_LOC_*_SEND version, since the SHIM_LOC_*_PREF version is 
> confusing due to section 5.15.3 of rfc 5533 that defines differently the 
> locator preferences.


> *Section 9, §2, again, confusion between SHIM_LOC_*_SEND and 
> SHIM_LOC_*_PREF