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.
- Stewart
With regard to your comment about identifiers, we can add in the
description of protocol reviews indications that such reviews should be
clear about what IDs the review considers need protecting, as that is
important context for the protocol review.
OK.
As noted in other exchanges, the document abstract needs a complete
rewrite. It should be just an abstract, with the rest of the context
either removed or moved to the introduction. In doing so, we will add
text describing briefly the general concept of the routing protocol
transport.
OK.
In general however, protocol specific behaviors are to be left to the
protocol analysis documents. Equally, descriptions of detailed threats
will be left either to the threat document or to the individual protocol
analysis document as appropriate.
My goal is to make some transport properties as notable and discussed
in as much (or as little) detail as, e.g., multicast and unicast
already are in the current document.
There are several items in your comments indicating that you would like
to see more discussion in the design guidelines of the protocol
layering. That does not seem to be a useful addition to this document.
Again, individual protocol analysis documents will deal with that where
it is appropriate, and avoid it where it is a distraction. We do not see
useful general statements of guidance that can be put into this
document.
As noted above, this is already in the document w.r.t.
multicast/unicast; I'm suggesting that it's equally appropriate to
include similar discussion of the issues of other layers on routing
protocol security.
Adding some general text in the discussion of communication modes
elaborating on the difference between the communication as seen by the
routing and security components, and the actual communication (e.g. that
what is seen as multicast may be delivered as broadcast or multiple
uni-cast) does seem a helpful addition to the document, and we will do
that.
I'm not sure if this is basically all I'm asking for; see above. The
intent was to add discussion of some known transport issues that are
as relevant as the multicast/unicast difference already discussed, in
similar detail.
Joe
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf