Subject: AW: [NSIS] RE: qos-nslp-00

From: Kappler Cornelia <[email-masked]>
Date: Thu, 25 Sep 2003 10:35:58 +0200

One comment inline. Cornelia
 
> |We deliberately refer to the state to be refreshed by the RSN 
> |(minimally) rather than by the session ID. 
> |
> |Summary refreshes should be handled with caution, we should be 
> |sure it is the correct state that is being refreshed. If we 
> |just use session ID, we dont know what possibly obsolete state 
> |might be refreshed. By matching the RSN in the summary refresh 
> |with the locally stored RSN, a nodes knows whether it is 
> |refreshing the correct state. 
> |
> |Vice versa, when the RSN in the summary refresh does not match 
> |the local RSN, the refresh will be disregared - which makes 
> |sense, because a problem must have occurred (i.e. a node does 
> |not have the most up-to-date state information).
> 
> Yes, and this node could be the one ignoring the refresh with 
> the sequence number not matching the on in his local database.

Exactly. Do I take it correctly you consider this a drawback rather than a virtue? Why that?

> 
> |Originally the idea was to make RSNs monotonically increasing 
> |(remember they have only local significance), so the newest 
> |RESERVE can always be identified. For some reason this idea 
> |didnt make it into the current version of the ID (I just 
> |noticed) I am not sure this was on purpose.
> |
> |Of course all this should become clear from reading the ID. We 
> |should check where it can be clarified. 
> |
> |Does this address your concerns?
> 
> Not quite. But I'll wait for the authors to produce some 
> more text.
> 
> |Cornelia
> |
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis