• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: karp

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

2013-03-01 16:02 (System)

RFC published

2013-02-27 18:07 (System)

RFC Editor state changed to AUTH48-DONE from AUTH48

2012-12-21 09:23 Amy Vezza

State changed to RFC Ed Queue from Approved-announcement sent

2012-12-20 08:58 (System)

IANA Action state changed to No IC

2012-12-20 07:03 Amy Vezza

State changed to Approved-announcement sent from IESG Evaluation::AD Followup

2012-12-20 07:03 Amy Vezza

IESG has approved the document

2012-12-20 07:03 Amy Vezza

Closed "Approve" ballot

2012-12-20 07:03 Amy Vezza

Ballot approval text was generated

2012-12-20 05:18 Stewart Bryant

Ballot writeup was changed

2012-12-20 04:52 Sean Turner

[Ballot comment]
Thank you for addressing my concerns.

2012-12-20 04:52 Sean Turner

[Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss

2012-12-19 22:22 Gregory Lebovitz

New revision available

2012-11-05 08:03 Sean Turner

[Ballot discuss]
Based on -06

1) s4 #5: Needs more detail about inter- and intra-session replay protection.

2) s4 #8: I don't entirely understand this:

8. Re-keying SHOULD be supported in such a way that it can occur
during a session without the peer needing to use multiple keys
to validate a given packet. The rare exception will occur if a
routing protocol's design team can find no other way to re-key
and still adhere to the other requirements in this section. The
specification SHOULD include a key identifier, which allows
receivers to choose the correct key (or determine that they are
not in possession of the correct key).

I don't understand how the 1st and 2nd relate. The first sentence says use one key, and then it says implement a key identifier so I can pick from the two keys? Aren't we really just asking for re-keying in session - not necessarily under the same key. That is:

8. Re-keying SHOULD be supported in such a way that it can occur
during a session. ....

2012-11-05 08:03 Sean Turner

[Ballot comment]
Updated based on -06:

1) s2.3: Step 4: Still having issues with the following but I think you're getting closer:

Measurably, we
would like to see an increase in the number of surveyed
respondents who report deploying the updated authentication and
integrity mechanisms in their networks, as well as a sharp rise
in usage for the total percentage of their network's routers.

I think you're trying to say this:

We would like to see a measurable increase in the number of surveyed
respondents who report [ISR2008] deploying ....

2) s4 #7: I think it's true that any good policy would require a key changed ... r/Keys may need to/Keys need to

3) s4 #14: Maybe: r/immediately verifiable by/immediately and independently verifiable by

4) s4 #19: I think the 1st and 3rd sentences are duplicated. And "some benefit" is a little squishy:

19. Every new KARP-developed security mechanisms MUST support
incremental deployment.

Proposed solutions MUST
support an incremental deployment method that provides some
benefit for those who participate.

2012-11-05 08:03 Sean Turner

Ballot comment and discuss text updated for Sean Turner

2012-11-05 06:04 Sean Turner

Ballot comment text updated for Sean Turner

2012-09-26 17:14 (System)

Sub state has been changed to AD Followup from Revised ID Needed

2012-09-26 17:14 Manav Bhatia

New revision available

2012-09-13 09:12 Brian Weis

Changed protocol writeup

2012-09-13 09:00 Brian Weis

Changed shepherd to Brian Weis

Viewing the last 20 entries. Show full log.