Hi Adam, Thank you for the comments.
>Thanks for a clearly written document. ..... Thank you. Nice of you. >The one term I had to go searching for was "stub AS". .... I have defined stub AS in my author's draft for the next version. Done. >.... Please use the boilerplate from RFC 8174. Yes, done. > §3.3: >I believe I understand how the described Algorithm B, is applied by AS4, ...... I think Jeff has addressed this quite well. Please let us know if you've further questions. > .... Nit: "the draft" won't age gracefully. I suggest changing to "this > document" or somesuch. Yes. Now the sentence has "this document". >§3.6.1: > +---------------------------------+---------------------------------+ > | Very Large Global ISP | 32392 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP | 29528 | > | ------------------------------- | ------------------------------- | >.... > ... I did find that adding the numbers in the first column on slide 6 >yielded 32393, which is tantalizingly close to the first number, but that >might just be a coincidence. ... You guessed it right where 32392 came from. And your math is better than ours :) 32393 is the correct number. Like Jeff has observed already, each line in the table corresponds to a unique ISP; so those first two lines in the table now read: > +---------------------------------+---------------------------------+ > | Very Large Global ISP X | 32393 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP Y | 29528 | > | ------------------------------- | ------------------------------- | Thanks for the catch. I've updated the draft accordingly. (I have not made any comments inline below.) Sriram ---------------------------- ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a clearly written document. My understanding of routing is pretty simplistic, and I still found the technique well-explained and easy to follow. This is no small feat. The one term I had to go searching for was "stub AS".. If this is a generally known term, that's fine -- but if not, it may warrant a short definition or citation. --------------------------------------------------------------------------- §1.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. Please use the boilerplate from RFC 8174. --------------------------------------------------------------------------- §3.3: I believe I understand how the described Algorithm B, is applied by AS4, will result in acceptance of AS1's packets from AS2. I'm a bit lost, however, about the means by which AS2 will accept them such that they could be delivered to AS4. Is there an assumption that AS2 is employing an ACL-based approach? If so, this should probably be stated explicitly. (This might be implied by text elsewhere, in which case I apologize for my confusion; although it may still be worth explicitly explaining.) --------------------------------------------------------------------------- §3.5: > It is worth emphasizing that an indirect part of the proposal in the > draft is that RPF filters may be augmented from secondary sources. Nit: "the draft" won't age gracefully. I suggest changing to "this document" or somesuch. --------------------------------------------------------------------------- §3.6.1: > +---------------------------------+---------------------------------+ > | Very Large Global ISP | 32392 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP | 29528 | > | ------------------------------- | ------------------------------- | I suspect there was a transcription error copying these lines from the source material, as the appearance of two rows with identical labels seems unlikely to be intended. I skimmed the cited source material to see if I could figure out what happened here, but found neither of these numbers (nor any mention of "Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion for a fix. I did find that adding the numbers in the first column on slide 6 yielded 32393, which is tantalizingly close to the first number, but that might just be a coincidence. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
