From nobody Wed Apr 30 06:51:00 2014 Return-Path: X-Original-To: msec@ietfa.amsl.com Delivered-To: msec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0861A08DF for ; Wed, 30 Apr 2014 06:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.17 X-Spam-Level: X-Spam-Status: No, score=-14.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBeAA4CVsYl5 for ; Wed, 30 Apr 2014 06:50:52 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 617DE1A08DC for ; Wed, 30 Apr 2014 06:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12365; q=dns/txt; s=iport; t=1398865851; x=1400075451; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=k3IVMCjFmLe6kIESnox5hdMsMptNq6WPDVlXJec4f+M=; b=cSXigER1VwfJF/MfMWiOnvu+TkTsHAmi3qsR6nKUqhO1QURmX/L9Bp5v 0eOtP1kCcoOx5ED7SR5TNVxQyRYmU6stgWwp8GlWDU5YPc3lnDJANVo4t EolwgdPnAIXIDivAPgh+9cI03Lach4c4EKbxQaPR3LrBhzt3ZXkU3uXHs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABr/YFOrRDoJ/2dsb2JhbABZgwbFaIEeFnSCJQEBAQMBeQULC0ZXBhOIOQfJPReLQoMPB4MkgRUEigWPIpJrg1Ed X-IronPort-AV: E=Sophos;i="4.97,958,1389744000"; d="scan'208,217";a="108960659" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 30 Apr 2014 13:50:50 +0000 Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3UDomJq017444; Wed, 30 Apr 2014 13:50:48 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_2673E109-C16E-4283-914C-FEE5D4DF8A76" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: <0815908A-7B2F-4A0B-9654-5367962995B6@inria.fr> Date: Wed, 30 Apr 2014 06:50:47 -0700 Message-Id: <9D95662F-312D-40C6-95E8-4EEB2A84F386@cisco.com> References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> <7CD270C5-2E9F-45A5-B434-8A4EB6146C24@cisco.com> <0815908A-7B2F-4A0B-9654-5367962995B6@inria.fr> To: Vincent Roca X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/msec/R1aO1_dBGULDOiKz4VxaCPtj6m0 Cc: msec@ietf.org, Kathleen Moriarty , draft-weis-gdoi-iec62351-9@tools.ietf.org Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:50:57 -0000 --Apple-Mail=_2673E109-C16E-4283-914C-FEE5D4DF8A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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 wrote: > Hi Brian, >=20 > I finally gave a look at the document (draft-weis-gdoi-iec62351-9-03). > Here are my comments: > =20 > Section 2.2. SA TEK Payload > ---------------------------- >=20 > ** typo: > An GDOI_PROTO_IEC_61850 SA TEK includes =3D> A GDOI_PROTO_IEC_61850 SA = TEK includes > ^^ > ** typo: > represents a SPI =3D> 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. >=20 > ** typo: > are define in Section 2.2. =3D> are defined in Section 2.2.X > ^^ > (several occurrences) > =20 > ** 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. > =20 > Section 2.3: > ------------ =20 >=20 > ** 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. >=20 > ** Typo: "The KD TYPE MUST be TEK" =3D> "The KD Type MUST be TEK" > ^^^^ > =20 > ** Fig 6: The figure mentions "KD Length", but this is a Key Packet. > Should it be the "Key Packet Length" instead? >=20 > Appendix A: > ----------- >=20 > ** I find it strange to provide actual field payloads, without = respecting the field size. E.g.: > OID=3D<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=3D field. =20 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. >=20 > BTW, these figures are not numbered which makes it more complicated to = reference them. >=20 > ** 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. > =20 > ** Fig p.19:=20 > 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). >=20 >=20 > Cheers, >=20 > Vincent >=20 [snip] Thanks, Brian --Apple-Mail=_2673E109-C16E-4283-914C-FEE5D4DF8A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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 <vincent.roca@inria.fr> = 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 =3D> A GDOI_PROTO_IEC_61850 SA = TEK includes
                =                     =        ^^
** typo:
represents a SPI =3D> = 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. =3D> 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      
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" =3D> "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=3D<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=3D<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).

=20 > 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. >=20 This is probably an RFC Editor question, but the many references online = say the difference is whether the following word starts with a vowel = *sound*, not whether it is spelled with an initial vowel or consonant. https://owl.english.purdue.edu/owl/resource/591/01/ The choice of article is actually based upon the phonetic (sound) = quality of the first letter in a word, not on the orthographic (written) = representation of the letter. If the first letter makes a vowel-type = sound, you use "an"; if the first letter would make a consonant-type = sound, you use "a." http://www.quickanddirtytips.com/education/grammar/a-versus-an?page=3Dall The rule is that you use a before words that start with a consonant = sound and an before words that start with a vowel sound (1)<> There are also references to what to do before acronym - the difference = is whether people ordinarily say the acronym by spelling out the acronym = (FTP =3D=3D "ef" "tea" "pea") or trying to pronounce it as a word (NAT = =3D=3D "nat"). = http://blog.apastyle.org/apastyle/2012/04/using-a-or-an-with-acronyms-and-= abbreviations.html = http://www.chicagomanualofstyle.org/qanda/data/faq/topics/Abbreviations.ht= ml?old=3DAbbreviations_questions01.html http://andromeda.rutgers.edu/~jlynch/Writing/a.html So it depends on whether the community says "spy" when encountering SPI, = or "es" "pea" "eye". And this nifty video, explaining the sound vs spelling distinction and = also the Old English origins of the a/an distinction. http://www.merriam-webster.com/video/0029-an.htm --Sandy From nobody Wed Apr 30 10:23:06 2014 Return-Path: X-Original-To: msec@ietfa.amsl.com Delivered-To: msec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDB81A7030 for ; Wed, 30 Apr 2014 10:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.651, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrrTWCh1-ZA1 for ; Wed, 30 Apr 2014 10:23:03 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB681A0942 for ; Wed, 30 Apr 2014 10:23:02 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id s3UHMwLM011639 for ; Wed, 30 Apr 2014 13:22:58 -0400 Message-ID: <53613171.3050007@concordia.ca> Date: Wed, 30 Apr 2014 13:22:57 -0400 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: msec@ietf.org References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> <7CD270C5-2E9F-45A5-B434-8A4EB6146C24@cisco.com> <0815908A-7B2F-4A0B-9654-5367962995B6@inria.fr> <9D95662F-312D-40C6-95E8-4EEB2A84F386@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2014/04/30 13:22:58 EDT Archived-At: http://mailarchive.ietf.org/arch/msg/msec/YnX22ALxQg7qU3RomtxKswviahw Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:23:05 -0000 Sandy, You have it completely right. The classic examples of this are the need to say "a AAA" and "a AAAA", because "AAA" is pronounced (by the IETF community) as "Triple A", and "AAAA" is pronounced as "Quad A". Bill On 30/04/2014 12:29 PM, Sandra Murphy wrote: > > On Apr 30, 2014, at 9:50 AM, Brian Weis wrote: > >> 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 wrote: >> >>> >>> ** 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. >> > > This is probably an RFC Editor question, but the many references online say the difference is whether the following word starts with a vowel *sound*, not whether it is spelled with an initial vowel or consonant. > > https://owl.english.purdue.edu/owl/resource/591/01/ > The choice of article is actually based upon the phonetic (sound) quality of the first letter in a word, not on the orthographic (written) representation of the letter. If the first letter makes a vowel-type sound, you use "an"; if the first letter would make a consonant-type sound, you use "a." > > http://www.quickanddirtytips.com/education/grammar/a-versus-an?page=all > The rule is that you use a before words that start with a consonant sound and an before words that start with a vowel sound (1)<> > > There are also references to what to do before acronym - the difference is whether people ordinarily say the acronym by spelling out the acronym (FTP == "ef" "tea" "pea") or trying to pronounce it as a word (NAT == "nat"). > > http://blog.apastyle.org/apastyle/2012/04/using-a-or-an-with-acronyms-and-abbreviations.html > http://www.chicagomanualofstyle.org/qanda/data/faq/topics/Abbreviations.html?old=Abbreviations_questions01.html > http://andromeda.rutgers.edu/~jlynch/Writing/a.html > > So it depends on whether the community says "spy" when encountering SPI, or "es" "pea" "eye". > > And this nifty video, explaining the sound vs spelling distinction and also the Old English origins of the a/an distinction. > > http://www.merriam-webster.com/video/0029-an.htm > > --Sandy > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8