Hi, Joel,
On 7/13/2011 1:58 PM, Joel M. Halpern wrote:
I don't understand your description of the problem.
As you quote, the document clearly states its scope.
So, when we then define the term "on-the-wire", I don't think we need to
restate the scope definition. It woudl seem coutner-productive.
The current scope is clear from the bullet list only by the assumption
that (a) the bullets are mutually exclusive, and (b) since the "routing
message content" is clear, it cannot be part of "on the wire".
I.e., it requires the reader interpret scope by a matter of deduction
and exclusion, rather than stating it clearly and explicitly.
Joe
Yours,
Joel
On 7/13/2011 2:58 PM, Joe Touch wrote:
On 7/13/2011 11:34 AM, Joel M. Halpern wrote:
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:
This text would note that it is a widely used term in IETF documents,
including many RFCs. It would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.
Here's why this is a problem:
1- does this refer to signing a BGP path?
2- does this refer to protecting the channel over which BGP paths are
exchanged?
From the intro:
Four main steps were identified for that tightening:
o More secure mechanisms and practices for operating routers.
...
o Cleaning up the Internet Routing Registry repository [IRR],
...
o Specifications for cryptographic validation of routing message
content.
...
o Securing the routing protocols' packets on the wire
This document addresses the last bullet, securing the packets on the
wire of the routing protocol exchanges.
So this document is clearly NOT about "the message from one routing
process to another (that would be 'routing message content', IMO). I.e.,
this doc focuses on securing the transfer mechanism NOT the message.
Thus this is the key to the entirety of the doc. This doc needs to be
very clear about what this is, at which point it can certainly also then
refer back to the original RFC (e.g., "this is referred to in RFC 4948
as 'on the wire'").
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf