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

Hi Magnus,

So is the next step that I do the mentioned edits, and submit a version 
for the IESG?

cheers,
Jukka

Magnus Westerlund wrote:
> 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.
> 

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [email protected]
Finland                           WWW:    www.comnet.tkk.fi