Subject: [karp] Planned disposition of comments: draft-ietf-karp-design-guide-02

From: Joel Halpern <[email-masked]>
Date: Wed, 20 Jul 2011 14:02:46 -0400

Joe Touch provided extensive comments on draft-ietf-karp-design-guide-02.
There was significant discussion of those comments.  Based on the 
discussion, the chairs propose to direct the authors to make the changes 
below.
These changes are responsive to the ADs request for a new version of the 
document.

1) Replacement Abstract, basically, remove the majority of the front, 
and begin, with light editing, at "This document":

       This document is one of a series of documents concerned with
       defining a roadmap of protocol specification work for the use
       of modern cryptographic mechanisms and algorithms for message
       authentication in routing protocols.  In particular, it defines
       the framework for a key management protocol that may be used to
       create and manage session keys for message authentication and
       integrity.

2) Modify the short paragraph after the bulleted list to echo the 
abstract, and clarify the point of the exclusion.  Something like:

       This document addresses the last bullet, securing the packets on 
the wire of the routing protocol exchanges.  Thus, it is concerned with 
guidelines for describing issues and techniques for protecting the 
messages and their contents between directly communicating peers.  This 
may overlap with, but is strongly distinct from, protection designed to 
ensure that routing information is properly authorized relative to 
sources of information.  Such assurances are provided by other 
mechanisms and are outside the scope of this document and work that 
relies on it.

2') After that, add a short paragraph on the term on the wire.  Along 
the lines of:

    This document uses the terminology "on the wire" to talk about the 
information used by routing systems.  This term is widely used in IETF 
RFCs, but is used in several different ways.  In this document, it is 
used to refer both to information exchanged between routing protocol 
instances, and to underlying protocols that may also need to be 
protected in specific circumstances.  Individual protocol analysis 
documents will need to be more specific in their usage.

3) Add a paragraph on routing protocol transport in the introduction. 
Something along the lines of:

     This document refers to routing transport in order to provide a 
common referent for the varied ways that routing protocols exchange 
messages.  This can be TCP, UDP, or even direct link level messaging in 
the case of some routing protocols.  The term is used here to allow a 
referent for discussing both common and disparate issues that affect or 
interact with this dimension of the routing systems.  The term is used 
here to refer generally to the set of mechanisms and exchanges 
underneath the routing protocol, whatever that is in specific cases.

4) In section 2.1 on  Message Transaction Type, please add some 
additional text noting that there is actually ambiguity in this 
categorization.  Something along the lines of:

     These categories affect both the routing protocol view of the 
communication, and the actual message transfer.  As a result, some 
mechanism for some protocols, may be mixtures, for example using 
broadcast where multicast might be expected, or using serial unicast to 
deliver what looks to the routing protocol like broadcast or multicast. 
  Protocol analysis documents need to pay attention both to the 
semantics of the communication, and the actual techniques taht are used 
for the message exchanges.

Thank you,
Joel Halpern and Brian Weis

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jul 2011 11:16:30 -0700

Hi, Joel (et al.),

Thanks for the following. These changes would address most of my 
concerns, with a small addition below.

Note that some would apply to the karp-threats doc as well.

Joe

On 7/20/2011 11:02 AM, Joel Halpern wrote:
> This document addresses the last bullet, securing the packets on the
> wire of the routing protocol exchanges. Thus, it is concerned with
> sources of information. Such assurances are provided by other mechanisms
> and are outside the scope of this document and work that relies on it.
>
> 2') After that, add a short paragraph on the term on the wire. Along the
> lines of:
>
> This document refers to routing transport in order to provide a common
> referent for the varied ways that routing protocols exchange messages.
> This can be TCP, UDP, or even direct link level messaging in the case of
> some routing protocols. The term is used here to allow a referent for
> discussing both common and disparate issues that affect or interact with
> this dimension of the routing systems. The term is used here to refer
> generally to the set of mechanisms and exchanges underneath the routing
> protocol, whatever that is in specific cases.
>
>
> Protocol analysis documents need to pay attention both to the semantics
> of the communication, and the actual techniques taht are used for the
> message exchanges.

This may include any semantics of the communication that impact the 
routing protocol, such as when source identity or path properties of the 
communication path are used by the routing algorithm, e.g., as when BGP 
infers routing table entry quality from the persistence of the TCP 
connection over which they are received.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Jul 2011 14:52:53 -0400

Authors, the suggested amendment seems to improve the text.  Please use it.

Thanks Joe.
Yours,
Joel

> Note that some would apply to the karp-threats doc as well.
...

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 21 Jul 2011 05:10:14 +0530

It certainly does - will update the draft with these comments and post a revised ID soon.

Cheers, Manav 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joel M. Halpern
> Sent: Thursday, July 21, 2011 12.23 AM
> To: Joe Touch
> Cc: George, Wes E [NTK]; [email-masked]
> Subject: Re: [karp] Planned disposition of comments: 
> draft-ietf-karp-design-guide-02
> 
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>