Subject: [karp] Fwd: Adrian Farrel's Yes on draft-ietf-karp-design-guide-03: (with COMMENT)

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Sep 2011 18:28:19 -0400

Authors, please respond to the comments promptly.

Thank you,
Joel

-------- Original Message --------
Subject: Adrian Farrel's Yes on draft-ietf-karp-design-guide-03: (with 
COMMENT)
Date: Wed, 21 Sep 2011 15:11:57 -0700
From: Adrian Farrel <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked],  [email-masked]

Adrian Farrel has entered the following ballot position for
draft-ietf-karp-design-guide-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for your work on this important document. I am balloting
"Yes", but I have a small raft of comments that you should look
through.

---

There is no need to include a reference to RFC 3036. That has been
obsoleted and is no more.

---

Section 1

       o  More secure mechanisms and practices for operating routers.
          This work is being addressed in the OPSEC Working Group.

Increased security or increased number? Please clarify.

---

Section 2

       and have design
       teams focus on the specification work within those groupings.

I think you can leave out this piece of IETF process that may or may
not be executed as it is not really relevant to the discussion of how
the protocols are split up on the road map or in this document.

Similarly

OLD
       so that the work can be easily leveraged by the
       various Routing Protocol teams.
NEW
       so that the work can be easily leveraged by for
       use in the various Routing Protocol groupings.

---

Section 2

       It is believed that the groupings will have like requirements
       for their authentication mechanisms, and that reuse of
       authentication mechanisms will be greatest within these
       grouping.

Yeah I know what you mean :-)

How about:

       The protocols will be grouped according to the requirements
       for authentication mechanisms that they are believed to have,
       and it is assumed that reuse of authentication mechanisms will
       be possible and deisrable within each group.

---

Section 2.1

s/some mechanism for some protocols/some mechanisms for some protocols/

---

Section 2.1

       The first categorization defines four types of messaging
       transactions used on the wire by the base Routing Protocol.

You go on to list only three mechanisms under sub-headings. It is
possible that you intend "Mixed" to be the fourth type.

---

Section 2.2

OLD
The second axis of categorization groups protocols by the
NEW
The second axis of categorization groups protocols is by the

---

Section 2.2

       Peer keying

       One router sends the keying messages directly and only to one
       other router, such that a one-to-one, unique keying security
       association (SA) is established between the two routers. This
       would be employed by protocols like BGP, BFD, LDP, etc.

How "direct" does the sending have to be? For example, can't it be
via a trusted proxy or key server? I am not sure that "directly" is
relevant to the distinction that needs to be drawn between "peer
keying" and "group keying".

(And, for what it is worth, "directly" means in time, and "direct"
means in space - except in some US usage where meaning has become
confusnicatified.)

---

Section 2.2 Peer keying

       This
       would be employed by protocols like BGP, BFD, LDP, etc.

The "etc." is very ambiguous in this case because the last time
protocols were mentioned in groupings they included other protocols
along with BGP, BFD, and LDP. One was RSVP-TE and we know that group
keys are potentially applicable to RSVP-TE.

Maybe just strike "etc." as it is bad style to say "such as" (which
you mean in place of "like") and "etc." in the same clause.

---

Section 3.1

       The form of the identity proof could be either raw keys, the
       more easily administrable self-signed certificate format, or a
       PKI issued certificate credential.

I think you intend there to be a choice of three options here, in
which case delete "either" to avoid confusion.

---

Section 3.2

This one is almost at the level of a Discuss...

       Additionally, key chains
       will not help if the routing transport subsystem does not
       support rolling over to the new keys without bouncing the
       adjacencies. So the first step is to fix all routing protocols
       so that they can change keys without breaking or bouncing the
       adjacencies.

It is not clear that the conclusion is correct. This is certainly
an option, but so are:

- changing usage such that the routing protocol uses a different
   routing transport subsystem that does not bounce the adjacency

- changing (fixing?) the preferred routing tansport subsystem
   such that it does not bounce the adjacensy

---

Section 5

Would it be OK to add PCEP [RFC5440] to the category "BGP, LDP and
MSDP" as it runs over TCP, is peer-based, and would simply pick up
TCP-AO in the same way as BGP?

---

Section 5

I find no fault with the discussion of "RSVP and RSVP-TE", but I
note that other categories in this section describe the categroy
in a brief(ish) paragraph while for RSVP we have a lecture.

This also seems to make use of RFC2119 language in earnest. Is
that right?

Does this text actually belong in one of the later, protocol-
specific documents?