Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08

#1) Add "updates: 3547 (once approved)" to the header.  This will make 
it match the intro/abstract.  I can almost guarantee a discuss from 
somebody on this.

#2) ISAKMP Phase 1 is described in Section 2.1 as "one such mechanism". 
  This isn't a MUST support.  As far as I can tell there isn't a MUST 
implement Phase 1 protocol (the protocols in Appendix A are also just 
examples).  But, to implement this document you've got to do things as 
described in RFC 2407-2409.  It seems like this doc and IKEv1 are pretty 
well intertwined.  And, the g-ikev2 draft doesn't use these formats it 
uses something else...Let's be clear about what it's being used with. 
It seems like this section ought to be changed as follows:

OLD:

   The following sections describe one such "phase 1" protocol.  Other
   protocols which may be potential "phase 1" protocols are described in
   Appendix A.  However, the use of the protocols listed there are not
   considered part of this document.

  2.1.  ISAKMP Phase 1 protocol

   This document defines how the ISAKMP phase 1 exchanges as defined in
   [RFC2409] can be used a "phase 1" protocol for GDOI.  The following
   sections define characteristics of the ISAKMP phase 1 protocols that
   are unique for these exchanges when used for GDOI.

   Section 7.1 describes how the ISAKMP Phase 1 protocols meet the
   requirements of a GDOI "phase 1" protocol.

NEW:

   This document defines how the ISAKMP phase 1 exchanges as defined in
   [RFC2409] can be used a "phase 1" protocol for GDOI.  The following
   sections define characteristics of the ISAKMP phase 1 protocols that
   are unique for these exchanges when used for GDOI.

   Section 7.1 describes how the ISAKMP Phase 1 protocols meet the
   requirements of a GDOI "phase 1" protocol.

Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2, 
respectively.

I would also delete Appendix A.  The currently proposed IKEv2 mechanism 
isn't reusing these fields and the KINK option never got defined.

#3) Sec 3.2: r/Hashes are computed in the manner described within RFC 
2409./Hashes are computed in the manner described within [RFC2409].

#4) Sec 3.2: expand prf on first use.

#5) Sec 3.3: 2 lower case "must" should they be "MUST"?
              1 lower case "should" should it be "SHOULD"?

#6) Sec 4.2: Something is wrong with this:

   Flags MUST have the Encryption bit set according to [RFC2008, Section
   3.1].

Maybe it should be:

   Flags MUST have the Encryption bit set according to Section 3.1 of
   [RFC2408].

#7) Sec 5: r/in accordance with RFC 2408./in accordance with [RFC2408].

#8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408].

#9) Sec 5.2: This is difficult to parse:

    The
    next payload MUST NOT be a SAK Payload or SAT Payload type, but the
    next non-Security Association type payload.

Maybe it's supposed to be:

    The
    next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST
    be the
    next non-Security Association type payload.

#9) Sec 5.2: r/Must/MUST   X4

#10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes payloads 
MUST be

#11) Sec 5.3: r/Must/MUST X2
               r/should/SHOULD
               r/must/MUST

#12) Sec 5.3: What is the conformance requirement for the following:

   Any or all attributes may be optional, depending on the group policy.

#13) Sec 5.3.1:

r/ attributes may be present / attributes MAY be present  or change to 
say they are OPTIONAL.

r/attributes must/attributes MUST

#14) Sec 5.3.1:

The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a
    GROUPKEY-PULL message.

What happens if it's included in the PUSH message?

#15) Just noted to instances of GROUPKEY_.  Aren't they supposed to be 
GROUPKEY-*?

#16) Sec 5.3.3.3: r/as recommended in/as defined in

#17) Sec 5.3.6: Any reason not to point to FIPS 180-3?

#18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present 
in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload

#19) Sec 5.3.7: Does anybody really want RSA-PSS?

#20) Sec 5.4: r/Must/MUST
               r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408].

#21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of [RFC5374]
                 r/should/SHOULD X2 ??

#22) Sec 5.5: r/Must/MUST

#23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port bullets 
r/should/SHOULD ?

#24) Sec 5.5.1: r/from RFC 2407/from [RFC2407]
                 r/[RFC2407],/[RFC2407]),
                 r/ESP must also/ESP MUST also

#25) Sec 1.3: Add GSPD

#26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374]

#27) Sec 5.5.1.1.1: r/must/MUST ?

#28) Sec 5.5.1.1.1: In the following, is 2119 language needed:

    SA TEK payload
    may be required in one or both directions.

#29) Sec 5.5.2: r/All Security Protocols must provide/All Security 
Protocols MUST provide

#30) Sec 5.6.1: r/The attributes must follow/The attributes MUST follow
                 r/At least one TEK must be/At least one TEK MUST be

#31) Sec 5.6.1.2: r/to the member./to the GM.

#32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes 
MUST follow

#33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only

#34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST

#35) Sec 1.3: add SSIV

#36) Sec 5.7: r/Must/MUST
               r/must/MUST X3

#37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they 
MUST be

#38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543, 
4754, 4868, 5903 are normative according to the following: 
http://www.ietf.org/iesg/statement/normative-informative.html

Assuming you delete App A, remove references to 4330 and 5996.

Please ensure the classification of the other references are in 
accordance with the IESG statement.  If you've got any questions, let me 
know.  I don't want to find out later that some informative reference to 
an informative RFC is actually a normative reference and we need to do a 
2nd IETF LC to note the DOWNREF.

I still need to finish Section 7 and 8.

spt

On 3/31/11 12:14 PM, Vincent Roca wrote:
> Hello everybody,
>
> As you probably noticed the GDOI draft has been significantly
> updated WRT the previous 07 version. For details see:
>
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-msec-gdoi-update-08.txt
>
> This situation motivates another WGLC. So please review
>
> draft-ietf-msec-gdoi-update-08
> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/
>
> and send comments to the WG mailing list by April 18th.
> (NB: if ever this deadline is too close, then tell me...)
>
> Regards,
>
> Vincent
> _______________________________________________
> MSEC mailing list
> MSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/msec
>