Hi Elwyn,

Thanks for your review.

I interpret the word "cost" as cost of an attack, which is a 
perfectly acceptable term in analyzing security properties of a 
protocol or a mechanism.  Your wording is also fine.  I don't have 
strong feelings either way.

GMARCH is a typo and should be GKMARCH for Group key management 
architecture (RFC 4046).

Sam has a DISCUSS on this.  The discussion so far indicates that 
we'll need an -05-.  I will ask Karl et. al. to wait until after the 
IESG telecon is over (Thursday morning ET?) before starting revisions on this.

thanks and regards,
Lakshminath

At 03:56 PM 2/15/2006, Elwyn Davies wrote:
>Background for those on the CC list, who may be unaware of GenART:
>GenART is the Area Review Team for the General Area of the IETF.  We
>advise the General Area Director (i.e. the IETF/IESG chair) by providing
>more in depth reviews than he could do himself of documents that come up
>for final decision in IESG telechat.  I was selected as the GenART
>member to review this document.  Below is my review, which was written
>specifically with an eye to the GenART process, but since I believe that
>it will be useful to have these comments more widely distributed, others
>outside the GenART group are being copied.
>
>Document: draft-ietf-msec-newtype-keyid-04.txt
>Intended Status: Proposed Standard
>Shepherding AD: Russ Housely
>Review Trigger: IESG Telechat 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 editing  if 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/
>
>


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art