Subject: [Insipid] FW: APPSDIR review of draft-ietf-insipid-session-id-reqts-08

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Sep 2013 13:34:20 +0000

And this is the applications directorate review.

Some discussion has been going on with respect to this between Vijay and Paul Jonees. At some point Paul should summarise that discussion when we get nearer the meeting of minds as to the issue.

Keith

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: 17 September 2013 16:54
To: [email-masked]
Cc: IESG IESG; [email-masked]
Subject: APPSDIR review of draft-ietf-insipid-session-id-reqts-08

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-insipid-session-id-reqts-08
Title: Diameter Overload Control Requirements
Reviewer: Vijay K. Gurbani
Review Date: Sep-17-2013
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is almost ready for publication as an Informational
RFC; two minor issues follow.

Major: 0
Minor: 2
Nits:  2

Minor:

- S3.2, the list of what are not considered communication sessions
  appears rather arbitrary.  What criteria makes you consider these
  are not communication sessions?  Is it the fact that some sort of
  conferencing (ad-hoc or organized) is being used?  If so, best to
  state this up front.  Otherwise I am left wondering why these cases
  are not considered to be a communication session.  I can certainly
  see the benefit of knowing which endpoints participated in a
  conference call that is indexed by a unique Session-ID.  So, why
  preclude this?  Any reason for doing so will help understand the
  decision for considering conferencing out of scope.

- S7, third paragraph: In cleartext traffic that is not subject to an
  rfc4474-type mechanism, I am not sure how you can prevent an attacker
  from spoofing (i.e., changing) the identifier to render is useless?

  Likewise, under similar conditions I am not sure how an application
  can verify that the session identifier was not changed.

  Unless, of course, you are stating that the identifier must be
  transmitted over a confidential and privacy preserving channel (which
  seems to be the gist of the last sentence of the section).  If that
  is the case, then you may want to highlight in a more prominent form
  than currently stated.

Nits:

- S3.1, first paragraph: s/that,/which,/

- S3.1, seventh paragraph: s/speaks of/considers/
   (less colloquial that way).

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq