On Oct 15, 2015, at 5:01 AM, Ben Campbell <[email protected]> wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Stephen's and Kathleen's discuss positions concerning the lack > of MTI security. I'm balloting no-objection (for now) so that those > conversations can happen on their respective threads. > > 3.2: > The says no message is ever sent by the monitoring station, but the last > paragraph in the section mentions a monitoring station sending a > termination message.
Fixed now, thanks. > Also, does the strategy for retrying failed > connection attempts apply to reconnects after the fail or an existing > connection? Sorry, I don't understand this question. > The 3rd paragraph from the end talks about redundant connections > happening when both parties are configured as active. But previous > paragraphs suggested that only passive endpoints will listen for a > connection. How could this result in redundant connections? To quote the draft, as might occur if both parties are configured to be active I'm a little bit embarrassed to admit to having (pretty much) recapitulated the BGP-3 and BGP-4 connection collision strategies, except... > Is there > logic to make sure the endpoints do not terminate both redundant > connections? ... the document punts on providing a specific algorithm. I'm comfortable with this given the likely use cases and lack of grave consequences for redundant connections. > IANA Considerations: > > Several of the tables reserve an experimental range of 65531 through > 65534. Is it really the intent to have experimental ranges with only 4 > code-points each? Yes. I tend to think of experimental ranges as a necessary evil whose only non-evil use is to allow implementers to compile something while they're waiting to get their proper, registered code point. Accordingly, I didn't specify big ranges. I'm open to changing the ranges to something larger, but still small, like 16 or something like that. Otherwise, we may have to have a longer discussion. --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
