Subject: [Gen-art] Gen-ART Review of draft-ietf-sip-target-dialog-03

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 27 Dec 2005 15:13:14 -0600

I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary - this specification is almost ready for publication as a Proposed 
Standard.

Nit++ ("a little more than a Nit"): I found one sentence that didn't make 
sense, in the Security Considerations section:

  The second condition is that the dialog
   identifiers be cryptographically random that they cannot be guessed.

If this was supposed to be "sufficiently cryptographically random", the 
sentence would make sense, and I would agree with it...

>From http://www3.ietf.org/proceedings/05nov/sip.html (discussion at the 
second IETF 64 SIP session): "Noted by Cullen Jennings & Robert Sparks that 
3261 already recommends the use of crypto-random tag values, but that 
existing implementations do not use enough bits to have sufficient 
randomness. This shows a need for more than rough guidance on this sort of 
thing."

I'm reading the minutes as saying that it might be good to define 
"sufficiently"...

Thanks,

Spencer

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Dec 2005 00:57:48 -0600

Thanks, Spencer. I agree with your suggestion. I think that we could add 
the "sufficiently" word and maybe a note defining sufficiently, like 
"(16 bits)" as instructions to the RFC editor, if no other feedback from 
the IETF LC causes the draft to be revised.

--
Dean

Spencer Dawkins wrote:
> Summary - this specification is almost ready for publication as a 
> Proposed Standard.
> 
> Nit++ ("a little more than a Nit"): I found one sentence that didn't 
> make sense, in the Security Considerations section:
> 
> second IETF 64 SIP session): "Noted by Cullen Jennings & Robert Sparks 
> that 3261 already recommends the use of crypto-random tag values, but 
> that existing implementations do not use enough bits to have sufficient 
> randomness. This shows a need for more than rough guidance on this sort 
> of thing."
>