Re: [HOKEY] Oversight in key management draft

["Hoeper Katrin-QWKN37" <khoeper at motorola.com>]

Hi Glen,

See my comments in line. 

Katrin
> -----Original Message-----
> From: Glen Zorn [mailto:gwz at net-zen.net]
> Sent: Tuesday, July 07, 2009 8:07 AM
> To: Hoeper Katrin-QWKN37
> Cc: hokey at ietf.org
> Subject: RE: Oversight in key management draft
> 
> Glen Zorn [mailto:gwz at net-zen.net] writes:
> 
> > Hi, Katrin.  While doing a final review as part of the document
> > shepherding
> > process, I noticed what I think is an oversight that may have
occurred
> > while
> > removing the RADIUS-specific stuff from the draft: section 4 says
"The
> > following key types are defined: 0 (DSRK), 1 (USRK) and 2 (DSUSRK)."
> > This
> > seems out of place now.
> 
[KH] 
The Key Request Token (KRT) carries (among other things) the key type of
the requested key. In the draft we specify three keys that can be
requested/delivered, i.e. DSRK, USRK and DSUSRK.

For that reason I thought it still makes sense to assign those numbers
to identify these keys, independent of which AAA protocol is used.

Do you think it should be left to the implementers to define the key
types?
If so, should we provide any guidance on this in the draft?

> As does the IANA Considerations section & BTW, remind me why this is
> Standards Track instead of a BCP...
> 
[KH] Sorry, I cannot remind you, because when I became the new editor of
this document this decision was already made and I cannot recall any
discussions on this topic. What do previous contributors think about
this?

I think changing it to BCP might be a good idea, given that we do not
know any current implementations that use the KDE protocol defined in
the draft.


> > If it is an error, do you want to fix it now
> > or
> > wait for IETF Last Call?
> >
> > ~gwz
> >
> > Play assigns meaning to human activity--work erases it.
> >   -- P.L. Wilson
> >
> >
> >
>