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

Hi,

Sent from my iPhone

> On Mar 6, 2015, at 3:35 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
> 
> 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.

Excellent, thank you.  Does the shepherd report require updating?  If not, I'll request last call later today.

Best regards,
Kathleen

> 
> 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: +352 424409 1
> Fax: +352 422473
> 
> 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
> <0x8A39DC66.asc>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext