Document:   draft-ietf-msec-newtype-keyid-04.txt
Reviewer: Elwyn Davies [elwynd@googlemail.com]
Review Date:  Wednesday 2/15/2006 5:57 PM CST
IESG Telechat Date:  Thursday, 16 February 2006

Summary: This document is in much better shape than when I reviewed v01 for 
IETF LC. There are a couple of points which I think still need clarification before it is quite ready for PS:

- In s1 the rationale talks about money costs: the IETF generally tries to 
avoid this as we are defining purely technical standards.  I have suggested 
some alternative words below which reflect the purely technical approach.
- There are some rather vague words in the start of the security 
considerations that lead one to wonder if the security considerations 
are incomplete.  It is entirely possible that this is merely 
inappropriate English but this needs editing.

There are also a couple of editorial nits which can be fixed during copy 
editingif more substantial changes are not to be made.

Detailed Review:

Issues:

s1, para 3: I misunderstood what this was trying to say in v01.  I can 
now discern the intent but it needs some tuning.  In line with normal 
IETF practice we should specify a technical proposal which will 
achieve a business aim rather than actually specifying the business behaviour:
>  The rationale behind this is
>    that it will be costly for subscribers to re-distribute the
>    decryption keys to non-subscribers. The cost for re-distributing the
>    keys using the unicast channel should be higher than the cost of
>    purchasing the keys for this scheme to have an effect.
How about:
  The rationale behind this is that it should be made substantially 
more inconvenient for subscribers to re-distribute the decryption 
keys to non-subscribers as compared with the non-subscribers becoming 
subscribers in order to acquire these keys. In order for this scheme to 
induce this behavior, the impact of the effort required to re-distribute 
the keys using separate unicast channels should therefore be sufficiently 
high that it will not be worthwhile for potential users of the service 
to access the content without subscribing.

Security Considerations:
s6, para 1: The phrase 'there are mainly two points...' sounds dangerous 
when it appears in Security Considerations.  Is this supposed to mean 
there are (exactly) two  points? If not, are there others which you don't
tell us about: we need to know so we can check they aren't significant 
or alternatively they might not be about security, in which you might 
write 'There are two main points which affect the security considerations.'

Editorial Nits:
s2, last para: s/to the "empty map"/for the "empty map"/

s3: The acronym GMARCH is not defined and is only used in the section title.  I 
take it is something about Group key Management ARCHitecture but it doesn't seem 
to be in general usage.

s3, title: s/Relations/Relationship/

s6, para 1: s/designed./designed to be used./

s6: Acronyms not expanded: MAC, TESLA.

s6, para 2: s/is not compatible with/is not appropriate for use with/