Subject: [MBONED] Mirja Kühlewind's No Objection on draft-ietf-mboned-driad-amt-discovery-09: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 12 Dec 2019 10:21:09 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mboned-driad-amt-discovery-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

UPDATE: Actually I saw the replies to the TSV-ART review but the discussed
changes where not yet implemented in the current draft version. So I assume
that will happen in the nest version! Thanks!

Thanks for addressing the TSV-ART review (and thanks Bernard for the review!)!
Based and in addition to that review, I have a few more small comments:

1) Minor wording comment on this point in 2.5.2:
"   8.  When congestion or substantial loss is detected in the stream of
       AMT packets from a relay."
I think is should be "substantial congestion or substantial loss" or just
"substantial congestion". But actually I would even maybe say "substantial and
persistent congestion" or maybe even use "(network) overload" instead of
"congestion" because I think that what you are actually looking for.

2) And on this sentence in section 2.7 again:
"with a RECOMMENDED initial_timeout
   of 1 second and a RECOMMENDED maximum_timeout of 120 seconds."
Why do you even specify a max value at all? I think it's more common to define
an initial value and a max number of retries.

3) I have an additional question on this part in 2.4.2:
"Otherwise, a gateway MUST provide a rate limit
   for the DNS queries, and its default settings MUST NOT permit more
   than 10 queries for any 100-millisecond period (though this MAY be
   overridable by administrative configuration)."
Where do these numbers come from?

4) Editorial: I would recommend to have the examples (section 3) before section
2. And I saw that there is one normative requirement in the examples section
(3.2.2.); that's easy to overlook. I would recommend to move it somewhere as or
make it not normative.

5) Sec 6.3:
"Application implementors and network operators that use DRIAD-capable
   AMT gateways..."
Thanks for noting this down. However, I'm wondering if DRIAD-capable AMT
gateways are in this respective any different that non-DRIAD-capable AMT
gateways? However, I think would be good or actually is needed to point to and
discuss section 4.1.4.2.  on Congestion Considerations in RFC7450! Further
regarding the security consideration in general I would also recommend to point
to the security considerations section of RFC7450 and double-check if there is
no change based on the potential different location of the reply (than assumed
in RFC7450).

6) (Important) nit:
In section 2.4.2:
"When present, IP addresses in the initial response provide resolved
   destination address candidates for the "Sorting of resolved
   destination addresses" phase described in Section 4 of [RFC8085]),"
and
"and attempts connections with the corresponding relays
   under the algorithm restrictions and guidelines given in [RFC8085]
   for the "Establishment of one connection, which cancels all other
   attempts" phase."
These should be references to RFC8305 (and not RFC8085).

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 18 Dec 2019 23:27:15 +0000

Hi everyone, and thanks for all the reviews and comments.

I just posted -11:
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-11

I believe it contains all the proposed edits I've accepted in the recent
threads, with one outstanding exception remaining, regarding the comment
from Mirja and my response (below).

This change seems to me like a fairly major editorial restructuring, and
it wasn't exactly the suggested change, so I wanted to ask for confirmation
on whether it seems like an improvement?  (And also whether anyone agrees
or disagrees with me that it seems better than swapping the 3. Examples
section wholesale with the current section 2?)

Aside from this pending change, I believe the -11 version incorporates all
the changes I've made in response to the many excellent reviews and comments
over the last several days.  Thanks everyone, and please let me know if
you notice anything that might be missing, or of course if there are further
comments (I think not everyone has had a chance to confirm yet whether the
changes addressed all their concerns.)

Best regards,
Jake

<outstanding-proposed-edit>
> 2.

I think moving the section is a little tricky.  I'm not sure the examples
make much sense without the context established in sections 2.1 and
2.2, but I can see why it might make sense to break up section 2 between
2.2 and 2.3, and to put the examples section in-between, and now that you
mention it, might improve the document.

What do you think of this structure?

Section 2 title "Relay Discovery Operation" -> "Relay Discovery Overview"
Section 2.1 title "Overview" -> "Basic Mechanics"
Section 3 "Examples" moved to section 2.3
Section 2 end after new section 2.3 (previously Section 3 examples)

New section 3 titled "Relay Discovery Overview"
Section 2.3 onward becomes new section 3.1

Do you think that would be a worthwhile reordering?  Do you think it would
need any other changes?

I can see that having the examples before the more detailed sections about
relay discovery operation might improve the doc for those reading it in
order, I think that's a good point.  Thanks.
</outstanding-proposed-edit>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 20 Dec 2019 09:59:34 +0100

Hi Jake,

Thanks for your updates. I think your proposed structure below looks good and I believe it would be an improvement, however, you really need to take the decision here and double-check if the information flow still works well!

Mirja

> On 19. Dec 2019, at 00:27, Holland, Jake <[email-masked]> wrote:
>

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 20 Dec 2019 19:40:06 +0000

Hello again,

I've just posted -13.  I think -12 yesterday addressed all the new
comments from Ben and from Adam on Wednesday, and -13 adds the final
few edits from further discussion with Ben, the reordering of sections
suggested by Mirja, and a couple of minor editorial tweaks I noticed
on a final read-through, plus one reviewer I had left out.

https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-13

I think this has everything anyone has asked for, so I think it's
ready to move on.  Thanks everyone for all the help with polishing.

Cheers,
Jake