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

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 2 Mar 2015 11:17:53 -0500

Hi,

I haven't seen any follow up yet and would like to progress this to IETF
last call soon if possible.  My comments are mainly nits or requests to
further clarify text, so hopefully these will be easy to resolve before we
get broader reviews on the drafts where these questions are likely to arise.

Thank you,
Kathleen

On Wed, Feb 25, 2015 at 7:11 PM, Kathleen Moriarty <
[email-masked]> wrote:

> Hello,
>
> 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)
>
> 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?
>
> 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?
>
> Section 3.4.5
> Second to last sentence, just a nit:
> s/control/controls/
>
> The algorithm therefore control execution time with
>    TIMER.
>
>
> Section 3.4.6
> There are some formatting issues at the start of this section, you are
> probably aware of already.
>
> Thank you.
> --
>
> Best regards,
> Kathleen
>

-- 

Best regards,
Kathleen

---

From: Stefan Winter <[email-masked]>
Date: Fri, 06 Mar 2015 09:35:30 +0100

Kathleen,

sorry for the late response.

> etc.).  They are obvious to most of us, but are not in the list of
> acronyms that don't have to be spelled out,

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).

> also a bit too long, can something be done to make these sentences
> easier to read?

I've split all those sentences for -13.

> The algorithm therefore control execution time with

Fixed, thanks.

> 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: +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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 6 Mar 2015 06:51:33 -0500

Hi,

Sent from my iPhone

> On Mar 6, 2015, at 3:35 AM, Stefan Winter <[email-masked]> wrote:
> 
> Kathleen,
> 

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

Best regards,
Kathleen

> <0x8A39DC66.asc>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 6 Mar 2015 12:50:42 -0500

Hello Journi,

Could you please update the shepherd report?  Benoit is listed as the AD
and that may be the only update needed, but a quick check would be good
before I pull the trigger for last call.  I'll look at this again later in
the day in case I can request it today.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Jouni.nosmap" <[email-masked]>
Date: Fri, 6 Mar 2015 09:53:29 -0800

Will do. 

- jouni

Sent from a smart phone.. Mind the typos..

> Kathleen Moriarty <[email-masked]> kirjoitti 6.3.2015 kello 9.50:
> 
> Hello Journi,
> 
> Could you please update the shepherd report?  Benoit is listed as the AD and that may be the only update needed, but a quick check would be good before I pull the trigger for last call.  I'll look at this again later in the day in case I can request it today.
> 
> Thanks,
> Kathleen
> 
>> On Fri, Mar 6, 2015 at 6:51 AM, Kathleen Moriarty <[email-masked]> wrote:
>> Hi,
>> 
>> Sent from my iPhone
>>