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.
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
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
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
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'").
Ietf mailing list