Re: [radext] AD review of draft-ietf-radext-dynamic-discovery

[Stefan Winter <[e-mail]>]

Kathleen,

sorry for the late response.

> I reviewed draft-ietf-radext-dynamic-discovery and found it to be very
> well written, and covering security and privacy considerations nicely as
> well.  Thank you for that.
> 
> I just have a few nits and a question to see if some text can be further
> clarified before progressing this to last call.  I'd like to start IETF
> last call very soon if the WG is ok with that.  
> 
> Nits & comments:
> 
> Please expand out names of DNS labels on first use (NAPTR, SRV, RR,
> etc.).  They are obvious to most of us, but are not in the list of
> acronyms that don't have to be spelled out,
> https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
> (If there is a *, RFC editor is okay with not expanding)

Done for -13.

> Section 3.4.3
> In the algorithm, I am confused by step 12 that simply says "Proceed
> with step 18."  Are there conditions that would have you decide to skip
> steps 13-17 or is this meant to be interpreted as proceed with step 18,
> then go back to step 13?  The example later shows that you skip 13-17,
> but why this happens isn't clear to me.  Did I miss an explanation? 

The algorithm contains one big if-then-else, but the steps are listed in
sequence. Step 8 either continues at 9 or at 13. If it did continue at
9, it advances to 12 and then the code path beginning at step 13 is
skipped. Both variants converge at step 18 (that's why 12 sends you to 18).

> Section 3.4.4
> First paragraph: The second sentence is super long and the last one is
> also a bit too long, can something be done to make these sentences
> easier to read?

I've split all those sentences for -13.

> Section 3.4.5
> Second to last sentence, just a nit:
> s/control/controls/
>
> The algorithm therefore control execution time with
>    TIMER.

Fixed, thanks.

> Section 3.4.6
> There are some formatting issues at the start of this section, you are
> probably aware of already.

Yes... something I'd prefer the RFC editor to take on at some point. The
line breaks are ugly, but I don't know how to nicely fix them.

I've just issued rev -13 with all the above-mentioned changes. Please
consult the diff at

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-radext-dynamic-discovery-13.txt

and let me know if you are satisfied.

Since the draft has now completed your AD review and also an early
secdir review (Brian Weis), I believe the draft is now ready for IETF LC.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66