Re: [Int-dir] draft-kivinen-802-15-ie-02.txt

[Charlie Perkins <[e-mail]>]

Hello Tero and all,

I reviewed the document revision ...-04.txt that you sent.  It looks 
good.  I have a couple of miniscule editorial comments down below.

Regarding the need for the Vendor IE section:  it still seems to me that 
the section would work well as an appendix.  But, especially if it is to 
be maintained in the normative text, perhaps the title could be changed 
to "Vendor Specific IE not needed" to make the purpose of the section 
even more clear.

On further reflection, I think you are indeed right that any additional 
security policy should anyway be checked at protocol layers higher than 
the MAC layer, and your wording in the Security Considerations section 
does express that thought.

Miniscule editorial suggestions follow:

  * "                                              it is never
    encrypted, but they may be authenticated"
      o the clauses are mismatched.  I think the simplest fix is to
        delete the word "they".


  * "IETF would requests" --> "IETF would request" --> "The IETF would
    request" --> "The IETF requests"
      o The first one is wrong, the second one uses the subjunctive but
        I don't know why, the third one sounds a little better to me,
        but the fourth one is declarative and I think that is actually
        best for what is intended.  In the next sentence I think that
        "Furthermore IETF" should be "Furthermore the IETF".  This could
        simply be a regional preference on my part.


I'd also like to echo Pascal's appreciation for your production of this 
badly needed Internet Draft.

Regards,
Charlie P.



On 10/24/2016 7:31 AM, Tero Kivinen wrote:
> Charlie Perkins writes:
>> I am an assigned INT directorate reviewer for
>> <draft-kivinen-802-15-ie-02.txt>.  These comments were written primarily for
>> the benefit of the Internet Area Directors.  Document editors and shepherd(s)
>> should treat these comments just like they would treat comments from any other
>> IETF contributors and resolve them along with any other Last Call comments
>> that have been received. For more details on the INT Directorate, see
>> http://www.ietf.org/iesg/directorate.html.
>>
>> I made a lot of minor editorial changes to the draft, because I think that the
>> draft needs improvements for readability and clarity.  For this purpose,
>> please see the attached files.  draft-kivinen-802-15-ie-02cep.txt contains all
>> of my comments (marked with "CEP") and revisions.
> I have tried to make all your changes to my draft, but as your review
> was for 02, and there was already 03 out there, I could not make
> direct apply for your changes. Please, check them from the attached
> version (both final text and diff from your version to the 04
> version).
>
> I will submit the 04 version when I get feedback from you, whether the
> changes done were ok.
>
>> A few more general comments:
>>
>>    * I do not understand why Section 5 is included.  It doesn't seem to have
>>      any effect on the request for allocation.
> The reason why section 5 is needed, is to explain that there is no
> need to do vendor specific range in the IETF IE, as there is so many
> other ways to do vendor specific IEs already.
>
> I.e., section 8 do not have range reserved for Private Use. In normal
> case we always have such range, now we do not.
>
>>    * Section 6 should be reworded so that the request is made to ANA, not
>>      802.15.4
> Pat Kinney already commented this, and I took his text for this.
>
>>    * Since all uses of the newly allocated IE will share the same security
>>      model, perhaps it should be mentioned that if a different security model
>>      is needed, another IE might be requested
> We cannot get another IE, as Operations manual does not permit
> 802.15.4 to give us another...
>
> On the other hand, higher layer processing those IETF IEs will make
> their own security processing checks, and we do not really want to
> use MAC level checks. The MAC level checks are needed for those things
> which are acted on the MAC level. IETF IE should not have anything
> like that, so we do not need to rely on the MAC level checks.
>
>>    * Although I have made a number of editorial suggestions, I think the
>>      document still will need a close proofreading.
> That seems to be always an issue with my drafts :-)
>
>> For other comments, please refer to the attached rfcdiff file.
> For the:
>
>      /* CEP: The above paragraph states that the Length field is part
>         of the IETF IE, but the Length field is not shown in Figure 1.
>         */
>
> The Length field is part of the IEEE 802.15.4 Payload IE format, and
> is not shown in the Figure 1, as it is not part of the IETF IE subtype
> format.
>
> I changed the text to say :
>
> 	The length of the subtype content can be calculated from the
> 	IEEE 802.15.4 Payload IE Length field of the IETF IE.
>
> I.e., added "IEEE 802.15.4 Payload IE" before the Length field to
> indicate it is not part of the IETF IE.
>
>
>