The Session Initiation Protocol (SIP) Referred-By Mechanism
draft-ietf-sip-referredby-05

[Note]: 'Steve and Ted have cleared their Discusses, but Ted's is based on text that went into the 05 version, so the announcement needs to wait for that.' has been cleared by Allison Mankin

[Note]: 'Steve and Ted have cleared their Discusses, but Ted''s is based on text that went into the 05 version, so the announcement needs to wait for that.' added by Allison Mankin

Steve Bellovin and Russ Housley talked with Robert in Seoul and gave Robert direction on how to revise for Steve's issues.  Robert sent a text rev and then did an update (04) and we are waiting for SMB to re-review.  An RFC Editor note should handle Ted's point.

[Ballot discuss]
2.1
        paragraphss 3 and 4 appear to be redundant

2.2   
        SHOULD the referee validate the token?  If not,
        why does it matter whether or not it's validatable?

4.1    What binds the referee's AIB to this request?  I think that the AIB
        needs to contain something -- a SHA1 hash, for example -- of
        crucial parts of this token.  (This may be a flaw in the AIB
        spec instead.)  As I read this, the referee's AIB is a separate
        MIME part from the referrer's token.  Did I miss something?

[Ballot discuss]
Section 2.2 says:

  A referee MAY reject a REFER request that does not contain a
  Referred-By token with a 429 "Provide Referrer Identity" response.  A
  referee SHOULD NOT reject a request that contains a Referred-By token
  encrypted to a key it does not possess.  Note that per [2] the
  referee should still be able to verify the signature of such an
  encrypted token.

I'm guessing this means this SHOULD NOT means "SHOULD NOT reject a request
just because it cannot decrypt the Referred-By token".  Some modification
to prevent the misreading "Encrypting the Referred-By token is a free pass
against rejection" seems like a good idea, especially given this text on anonymity
from 6.1:

  Including the To header field in the Referred-By token has privacy
  implications, however.  Carol, above, might wish to contact us
  anonymously.  That wish would be defeated if Carol's identity
  appeared in the token Alice created.  If Alice encrypted the token to
  us, Carol will not even be aware of the information leak.  To protect
  herself when she wishes anonymity, Carol will have to reject any
  REFER requests containing a Referred-By token she can not inspect.

A forward pointer from 2.2 to 6.1 might even be a useful.

[Ballot discuss]
Section 2.2 says:

  A referee MAY reject a REFER request that does not contain a
  Referred-By token with a 429 "Provide Referrer Identity" response.  A
  referee SHOULD NOT reject a request that contains a Referred-By token
  encrypted to a key it does not possess.  Note that per [2] the
  referee should still be able to verify the signature of such an
  encrypted token.

I'm guessing this means this SHOULD NOT means "SHOULD NOT reject a request
just because it cannot decrypt the Referred-By token".  Some modification
to prevent the misreading "Encrypting the Referred-By token is a free pass
against rejection" seems like a good idea, especially given this text on anonymity
from 6.1:

  Including the To header field in the Referred-By token has privacy
  implications, however.  Carol, above, might wish to contact us
  anonymously.  That wish would be defeated if Carol's identity
  appeared in the token Alice created.  If Alice encrypted the token to
  us, Carol will not even be aware of the information leak.  To protect
  herself when she wishes anonymity, Carol will have to reject any
  REFER requests containing a Referred-By token she can not inspect.

A forward pointer from 2.2 to 6.1 might even be a useful.