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.
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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf