Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351

[Brian Weis <[e-mail]>]

Hi Vincent,

Many thanks for your review. I've addressed them, with some notes inline.

On Mar 3, 2014, at 10:27 AM, Vincent Roca <[e-mail]> wrote:

> Hi Brian,
> 
> I finally gave a look at the document (draft-weis-gdoi-iec62351-9-03).
> Here are my comments:
>      
> Section 2.2.  SA TEK Payload
> ----------------------------
> 
> ** typo:
> An GDOI_PROTO_IEC_61850 SA TEK includes => A GDOI_PROTO_IEC_61850 SA TEK includes
>                                            ^^
> ** typo:
> represents a SPI => represents an SPI
>                                ^^
> (there are many occurrences of "a SPI", is it volontary?)

I double checked with some sources, and the general rule (at least for American English) is "a" before a consonant, and "an" before a vowel. There are a few special rules but "a before s" does not seem to be one of them.

> 
> ** typo:
> are define in Section 2.2. => are defined in Section 2.2.X
>                                        ^^
> (several occurrences)
>       
> ** There is a window of 2 keys (CK and NK). Each of them have timing values, representing
> their validity time till it needs to be updated. As I understand, the CK will take the
> value of the NK upon CK expiration. Potentially, the CK/NK timing values can be different.
> Is it an issue (e.g. if the NK remaining lifetime is < CK remaining lifetime, the NK must
> be updated before the CK) ? I imagine this is discussed elsewhere. A note might be useful.

This case is not mentioned; I've added a note.

>      
> Section 2.3:
> ------------              
> 
> ** incoherencies:
> there are several occurences of "KD payload", whereas it is written "Key Download Payload" elsewhere.
> Also, section 1.3 mentions:
>    KD    Key Download Payload
> i.e. includes the payload in the KD acronym definition.

> 
> ** Typo: "The KD TYPE MUST be TEK" => "The KD Type MUST be TEK"
>                                               ^^^^
>    
> ** Fig 6: The figure mentions "KD Length", but this is a Key Packet.
> Should it be the "Key Packet Length" instead?
> 
> Appendix A:
> -----------
> 
> ** I find it strange to provide actual field payloads, without respecting the field size. E.g.:
> 	OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02>
> is 13 byte long if I understand correctly, but in the figure, it only spans 3 bytes.
> Same remark for the OID SP=<DER for 233.252.0.1> field.    

Sorry this is confusing. The field ends in a "~", which is a shortcut for saying the length of the field goes beyond the bytes shown, which (if you know that) makes the example easier to understand. I'll see if I can make the example clearer.

> 
> BTW, these figures are not numbered which makes it more complicated to reference them.
> 
> ** I was also wondering if there are alignment requirements. In theory no as there is
> no padding field. I haven't seen any note for this, whereas all figures are presented in
> such a way that 16-bit fields are correctly aligned. A note could be added to section B.1.

A note is a good idea. It's hard to mandate padding when there are multiple variable-length fields.

>  
> ** Fig p.19: 
> typo: There is a trailing "2" character in "RESERVED2".

Actually, that's what the field is called in the  KD Payload definition (RFC 6407, Section 5.6).

> 
> 
> Cheers,
> 
>    Vincent
> 

[snip]

Thanks,
Brian