Wes,
The following text extracted from your response provides a good basis
for what will be my
final reply in this exchange.
... I believe the fact that you/the WG included it in the discussion
means that you/the WG believe that it's a threat.
first, its an attack, not a threat. second, the topic was added to
acknowledge that we are aware of
such attacks, even though we have chosen to not address them now. period.
I could infer based on the fact that SIDR chose not to design
protections against that exploit that it's a real threat but very low
risk, or extremely difficult to exploit, or whatever, but the document
doesn't currently say anything about the relative level of risk for
the threat being identified.
and, as I noted, such inferences would be unfounded.
You're right in that the design/requirements decisions that SIDR WG
made about whether to address that threat are mostly irrelevant, but
the fact that you discuss it in terms of design scope makes that
confusing if one is to evaluate this text as purely a threats analysis.
I didn't say what you suggest immediately above. Route leaks and
protection for other path
attributes are included because they were discussed by the WG, and the
WG chairs felt it was
important to acknowledge that discussion, and note briefly why these
topics will not be addressed.
It goes back to a recurring issue that has happened with the order of
these documents, where we're writing a threats doc and a requirements
doc based on an existing design rather than the other around, and are
tailoring these documents based on the current design to the exclusion
of things deemed out of scope instead of documenting everything and
then deciding some of the specific scope items in the
requirements/design phase.
This seems to be the telling issue. You seem to be unhappy with the
scope of the WG charter, and
refuse to accept it as bounding for the work that is being performed.
Your earlier comment
refers to the charter as "arbitrary" suggesting an unwillingness to
accept a charter as a
a way to bound the scope of a WG.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
