Re: [Perc] Éric Vyncke's No Objection on draft-ietf-perc-dtls-tunnel-09: (with COMMENT)

["Paul E. Jones" <[e-mail]>]

Eric,

>== COMMENTS ==
>
>I was about to raise a DISCUSS on this but I am trusting the security AD on
>this topic. But, I really wonder why TLS 1.2 is used rather than TLS 1.3.
>
>There is no operational consideration around the resiliency of the Key
>Distributor (load balancing, fail-over, etc.). Should there be some operational
>considerations ?

DTLS 1.2 was referenced since it is the current RFC.  However, it 
doesn't really matter that it's 1.2 or 1.3, modulo the order of message 
issue that Benjamin noted about message order.  That said, there really 
is no need to have that strict language, so I'll change it.


>-- Abstract --
>While I agree that this document could be informational, why does the abstract
>use words like "defines" "the protocol is designed" as those words are more
>normative than descriptive. Strongly suggest to rephrase the abstract.

The document does define a protocol that is designed for a specific 
purpose.  If I change that wording, it doesn't change that fact.


>-- Section 1 --
>Knowledgeable people will understand the E2E and HBH concepts but a figure
>would be welcome for beginners (really just a suggestion).

While you're right, this protocol is intended to be implemented as a 
part of RFC 8871.  I do not want to redefine anything or introduce 
language that might appear to conflict that RFC.


>Later and in the same vein "simply forwarding packets" for me (INT AD) packets
>are layer-3 and it is really unclear in the introduction what is actually
>forwarded. I.e., 'packets' should be qualified, perhaps in "DTLS messages" or
>using the same vocabulary of section 5.3 ?

I agree with the "DTLS messages" suggestion and removed "simply".  I'll 
try to improve the wording here.


>-- Section 2 --
>As usual, I am not comfortable when an informational document relies on BCP 14,
>which should (IMHO) be reserved for BCP/standards track documents. Just a
>comment, feel free to ignore.

I try to not ignore anything, albeit I'm  very late getting around to 
responding, for which I can only apologize to you and the others; I've 
been rather busy.

This document was originally intended to be standards track and it 
defines one possible way of filling the void left by RFC 8871.  That RFC 
describes a tunnel between the MD and KD.  This document represents one 
way to do it, but other approaches could be implemented.  Maybe 
experimental is a better classification?  I'm still open to this being 
Standards Track as it was originally intended :)


>-- Section 5.2 --
>"which tunnel or tunnels to use to send messages for a given conference is
>outside the scope of this document." is really a lot of hand waving as I wonder
>how the document could be used without knowing which tunnels is to be used.

I wanted to make it clear that the MD may create a plurality of tunnels 
to different physical KDs in order to improve resiliency and 
performance.  The concern with going into any detail here is that I do 
not want to prescribe how traffic might be load balanced or what 
resiliency mechanisms might be employed.  Those things are 
implementation detail that is outside the scope the document.  I could 
just remove the entire paragraph, as I think that's the only place where 
it talks about the possibility of more than one tunnel, but then more 
questions would be raised about resiliency, I think.


>== NITS ==
>
>There are several occurrences of "an message"... probably a replace all, which
>went wrong ;-)

I do not see those.  Maybe I'm overlooking them?  Can you point them 
out?



>-- Section 1 --
>s/on behalf of the endpoint/on behalf of the endpointS/ ?

Endpoints is good, but I'll remove "the".  The rest of the paragraph is 
intended to describe the interaction between an endpoint and KD, so at 
least one other article should change.  I do that; hopefully it reads 
better.

Paul