Subject: Re: [KEYPROV] Second Last Call: draft-ietf-keyprov-dskpp (Dynamic Symmetric Key Provisioning Protocol (DSKPP)) to Proposed Standard

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 13 Jul 2010 10:24:51 +0900

Dear IESG,

On 2010/05/27 6:48, The IESG wrote:
> The IESG has received a request from the Provisioning of Symmetric Keys
> WG (keyprov) to consider the following document:
>
> - 'Dynamic Symmetric Key Provisioning Protocol (DSKPP) '
>     <draft-ietf-keyprov-dskpp-11.txt>  as a Proposed Standard
>
> This is a second Last Call and is intended to confirm community
> support for publication with respect to two specific issues:
>
> (1) As a result of IESG evaluation, an informative reference to RFC 2781,
> "UTF-16, an encoding of ISO 10646", was changed to a normative
> reference.  RFC 2781 was published as an Informational RFC; the IESG
> would like to determine whether the community believes RFC 2781 is
> sufficiently mature for a normative downref.

I'm only commenting on this point, not on point (2).

RFC 2781 was done as informational mainly to make clear that the default 
encoding for Unicode in the IETF is UTF-16. The main thing that RFC 2781 
does is point to Unicode and ISO 10646 as the definitive reference for 
UTF-16.

RFC 2781 also defines the labels UTF-16, UTF-16BE, and UTF-16LE for 
labeling streams of UTF-16-encoded text. These labels come with very 
specific provisions for endianness and for use of the BOM (byte order 
mark). From the context of using 'UTF-16' in 
draft-ietf-keyprov-dskpp-11.txt, I think it is amply clear that this 
refers to text that always starts with a BOM, because otherwise, it 
wouldn't be well-formed XML.

So I think the way this is done is fine. However, I do not think that a 
reference to UTF-16 (and for that, to UTF-8) was strictly needed, 
because these are defined indirectly by XML. On the other hand, I was 
VERY surprised to not find XML as a normative reference!

Regards,   Martin.

> (2) IPR notice #332 may apply to this document, but is not explicitly
> linked to this draft.  Since this was not highlighted in the Last Call,
> the IESG would like to determine whether this affects community
> consensus.  For additional information, see:
>
>        https://datatracker.ietf.org/ipr/332/
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-06-09. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-11.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16358&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]