On Wed, Aug 15, 2012 at 4:28 PM, Brian Dickson
<[email protected]> wrote:
> On Wed, Aug 15, 2012 at 4:25 PM, Brian Dickson
> <[email protected]> wrote:
>>
>> I'll try to be more clear:
>>
>> I do not believe comments regarding _any_ version of the draft in
>> question, have been adequately addressed (on the mailing list, or in person,
>> or in the document).
>>
<snip>
>> I would respectfully point out the dates of the discussion, and a few of
>> the subject lines, as follows:
<snip>
>> "Route Leaks message to IDR" (3/21/2012 onward)
I think there is text in the draft now about residual threats and route-leaks.
I believe the status on the 'do something in grow so something happens
in idr so something can happen in sidr' is 'waiting on author to get
unstuck and proceed'. which is fine, but shouldn't hold up this doc
which can be fixed/altered/etc once/if there is output from grow/idr
that sidr can do something about.
>> Also, given that draft-dickson-sidr-route-leak-solns exists and has not
>> expired, and that IDR has been asked to review the route-leaks issue, and
>> have themselves asked GROW to take a look at it, it would be more
>> appropriate to have the -threats- doc refer to this draft, and to the
>> ongoing IETF process of codifying route-leaks, rather than disingenuously
>> continuing to state that nothing codifies route-leaks in the IETF.
I don't think it's disingenuous... the threats doc says:
""Route leaks" are viewed as a routing security problem by many
network operators, even though there is no IETF-codified
definition of a route leak. BGP itself does not include semantics
that preclude what many perceive as route leaks. Moreover, route
leaks are outside the scope of BGPSEC, at this time, based on the
SIDR charter. Thus route leaks are not addressed in this threat
model."
currently there isn't a completed definition, that's not to say that
eventually there may be, and the doc can be updated then. Hopefully
when there is a definition we can also have some 'method to fix them'
from idr.
<snip>
>> The importance of this is that in considering the body of work of the WG,
>> and in particular potentially deploying BGPSEC (in whatever form it
>> emerges), operators _must_ be given all the necessary information, including
>> whether BGPSEC protects against threats that actually exist. Pretending the
>> threats do not exist, by not detailing them in the "Residual Threats"
>> section, is really not what I would consider IETF-worthy.
no one is pretending anything (I think), we are awaiting some results
from the aforementioned groups/authors. I believe the other folk who
were interested in this topic are satisfied with the direction.
I think it's time to move the document along.
-chris
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
