Re: AD review comments of draft-ietf-nsis-qos-nslp-16

Hi, Roland thanks for these, I'll take them into account when finalizing 
the next rev.

Jukka

On Tue, 13 Oct 2009, Roland Bless wrote:

> Hi Jukka,
>
> Jukka Manner wrote:
>> Hi Roland, thanks for the note, we'll fix this one, too.
>
> I have additional comments you might consider, mainly
> for consistency and clarification:
>
> A) Multiple Upstream RSNs
> Sec 5.2.1 State Manipulation:
> RSN from the upstream peer
> => One must allow for keeping multiple RSNs from different upstream
>   peers
>
>   Reasoning: this is along the same line as the reasoning for keeping
>   multiple Flow IDs in case of mobility. Usually if R=1 (Replace Flag)
>   is set, you only need to consider one RSN for an upstream peer, but
>   if R=0, you will usually simply dismiss the RESERVE from the new
>   upstream peer in most cases. The new peer however, cannot know which
>   is the latest valid RSN that was used with the previous peer.
>
> It's not clear to me whether this will also affect the interface in
> A.1. I cannot find any SII-Handle which could be used as qualifier
> for the RSN.
>
> B) Receiver-initiated reservations:
> Sec. 3.2.12, p.20:
> "If routing changes in the middle of the path, the QNE that notices
> that its downstream path changed, the divergence point, ..."
> change to:
> "If routing changes in the middle of the path, the QNE that notices
> that its downstream path changed (indicated by a NetworkNotification
> from GIST), the divergence point, ..."
>
> I didn't find any text that states anything about repeating the
> QUERY message. State refreshes are performed by sending RESERVE
> messages upstream. So basically it is not necessary to repeat
> the QUERY from the sender in order to detect route changes,
> since GIST probing will discover the route change even without
> the QoS NLSP QUERY sent by the sender. This is a difference to
> RSVP for example, where the PATH message was periodically
> repeated, too.
>
> Thus I'd like to propose adding clarifying text at the
> end of sec. 4.3:
> As GIST will indicate re-routing events by NetworkNotification,
> it is not necessary to periodically repeat the QUERY message
> for route change detection (cf. Sec 3.2.12).
>
> more NITS:
> ----------
> There is a typo on p.91:
> "   o  authorization_info: the AUTHO_SESSION object"
> =>
> "   o  authorization_info: the AUTH_SESSION object"
>
> and p. 77: spacing:
>   stateful QoS NSLP QNE receives a QUERY message with the RESERVE- INIT
> =>
>   stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT
>
> Regards,
> Roland
>
>
>