Hi, Joel,
On 7/13/2011 10:31 AM, Joel M. Halpern wrote:
Replacing a widely used term ("on the wire") with term that folks will
not understand does not seem to me personally to be a benefit.
The problem is that "on the wire" is ambiguous. Many people think they
know what it means definitively, but their views vary widely.
In terms of this document, I do not see a problem with the usage as it
is. This is not a protocol document. The use of the current term in this
context seems helpful rather than harmful.
Since the whole point of this doc centers around protecting the way
messages are exchanged, not the messages themselves (e.g., as would be
the case with signed BGP routes), this is a crucial issue to make clear
and precise in this doc.
Joe
On 7/12/2011 8:26 PM, Joe Touch wrote:
On 7/12/2011 3:36 PM, Stewart Bryant wrote:
On 12/07/2011 23:23, Joe Touch wrote:
Hi, Joel (et al.),
On 7/10/2011 7:10 AM, Joel Halpern wrote:
Joe,
THE KARP WG Chairs have reviewed your comments, in order to figure out
what the best way to address them. We would appreciate it if you could
engage in discussion of this proposal on the KARP working group email
list. If you feel we are still not understanding your point, we
would be
happy to make some time avaialble for discussion at the WG session in
Quebec City. (Comments from anyone else, particularly WG members, on
the
proposals being made by the WG chairs are appreciated as well.)
Rather than a line by line response, we have tried to find the common
themes and respond to them. If we have missed major issues, please let
us know.
You raised concern about the use of the term "on-the-wire." Rather
than
replace the term, we would prefer to add descriptive text early in the
document. 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.
That's a great example of why this term should be removed. The message
sent from one BGP to another is sent *inside* a TCP connection, and
nobody would ever call the TCP bytestream payload the message "on the
wire".
This term is simply sloppy, and just as the security community rightly
raises issues with similarly poor use of its terms (e.g., "random"
where pseudorandom or arbitrary are intended, or "authenticated" where
integrity protection is intended), I consider this a *significant*
transport issue.
Joe
Please can you suggest a suitable generic term that covers the
set of cases that we need to deal with in routing - i.e.
over the MAC, over IP, over UDP and over TCP, so that we can
discuss inter routing entity message passing as an abstract
operation.
As Joel says when we get to the detailed design of each routing
protocol we will discuss the details, but we want a high level
discussion in this document.
Note BTW that 186 RFCs use the term "on the wire" in this
sort of situation.
I counted nearly 210, when including "over the wire" too. There are
similar misuses of, e.g., security terms, though, so let's not let past
errors suggest continued use.
That said, let's proceed:
First, when you say "on the wire" do you mean:
(A)- the routing protocol data units (RPDUs)
(B)- way in which RPDUs are exchanged
this includes message payloads, meta-info
(header information), and any other info
at other layers beyond RPDUs that the routing
protocol uses or relies upon
I'm presuming the term "on the wire" is intended to differentiate
between (A) and (B).
There's no good way to describe (B) as a single entity because it's not
one. You basically are differentiating between the message and the means
of its communication. The latter is often called a 'channel' in other
contexts, so maybe that's the term you want - a way to protect the
'channel'.
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf