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
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
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.
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.
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
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.
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
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.
Joel and Brian
Ietf mailing list