ietf
[Top] [All Lists]

Re: notes from discussion of KARP design guidelines

2011-07-10 09:11:28
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.

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 transport.

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 document.

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.

Yours,
Joel and Brian

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf