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

Roland Bless skrev:
> Hi Magnus,
> 
> I'll try to answer C. and D.
> 
> Magnus Westerlund wrote:
>> B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth.
>> This is an informational reference. But I do wonder about the security
>> solution and its need to carry authentication information. No, I don't
>> want to make this a normative reference. But I do wonder how the WG
>> plans to present the lack of even one fully specified security solution,
>> even if this is going for experimental.
> 
> This is indeed a good point. Without the session authorization object,
> there is only TLS transport security in a hop-by-hop manner, which is
> also not related to individual sessions or users. So the above draft
> is indeed very useful.

I think there might be a point to admit openly that the security
solution for this behavior is currently not specified and do require work.

> 
>> C. Section 3.2.12.1: How long does it take to detect that a new down
>> stream peer exist, or that truncation has happened?
> 
> Route change detections depends on the GIST route change detection
> mechanisms, at latest the next GIST probing Query message
> sent. Details are described in section 4.4.4. of the GIST draft, so
> in the default case of 30s routing state validity probing Querys are
> sent in the interval [15s...22.5s]. In some cases GIST may detect
> route changes faster and thus send a new Query earlier. Route change
> detection requires the three-way GIST handshake to be completed first
> though (i.e., at least RTT for GIST Query/Response pair).
> In case of path truncation, one must distinguish whether the new
> next hop is GIST aware or not. The draft describes the former case,
> so GIST will respond with "Unknown NSLPID" error in the GIST Response
> to the Query and the same duration as above can be expected. In the
> latter case of a non GIST-aware hop it takes longer, because the
> querying node may perform retransmissions and exponentially backup,
> so in this case we get a default 127*500ms=63.5s (T1=500ms, T2=64s)
> as worst case. But as indicated in 5.3.3 of the GIST draft, NSLPs may
> bound this response time by limiting T2 in the sendmessage() primitive
> explicitly.
> 
Thanks for the answer. I don't think there is any need to do changes
here in the text.


>> D. Section 4.6, page 35, second paragraph. It is not clear to me how (1)
>> can be guaranteed to arrive prior to (2), or if both message are sent
>> width bound to the other one?
> 
> That's exactly the motivation for the message binding. You cannot
> guarantee it, so both messages have to wait on each other. This case
> is described on p. 36: "Triggering message" (3) arrives before waiting
> (bound) message (1). Usually the waiting condition is then already
> satisfied, so (1) can be processed immediately. I'm not sure that I
> understand the last part of your question correctly, but (1) will
> contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding
> MSG_ID.
> 

Hmm, clearly my thought process wasn't working. I don't see any issues
with the text when revisiting it. It seem to have the relevant
references to the mechanism used. So forget this comment.

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------