RE: [Hokeyp] [Emu] Re: MSK but no EMSK
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Hokeyp] [Emu] Re: MSK but no EMSK
Hi Blumenthal,
see below,
BR,
Michael
> -----Original Message-----
> From: hokeyp-bounces at opendiameter.org
> [mailto:hokeyp-bounces at opendiameter.org] On Behalf Of Blumenthal, Uri
> Sent: Friday, November 17, 2006 10:22 PM
> To: hokeyp at opendiameter.org; emu at ietf.org
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
>
> >The discussion focuses on the problem EMSK is optional or mandatory.
>
> I don't think this is a problem - GENERATION of EMSK is
> compulsoty as spelled out in RFC 3578.
Michael=>>Really, people were talking about it. Yes, it is compulsory in
RFC3578.
>
> The problem is non-compliance. Some, er, people seem to think
> "the standard says do A, but since I don't use A at the
> moment - I won't bother."
>
> >RFC3578 defined EMSK is mandatory,
>
> And that should be the end of discussion.
Michael=>> I agree.
>
> > but it is not used at all.
>
> First - do you know all the applications that use
> key-generating EAP methods? But really - who cares?
Michael=>> As far as know, it is so.
>
> >If EMSK must be used, it is mandatory. if no, I think, it
> may be better
> >that it is optional.
>
> VERY strongly disagree. Mandatory is what is explicitly
> specified as mandatory, period. Otherwise many would
> implement just those pieces and features of the standard that
> his particular product needs today.
Michael=>>Blumenthal, I think, it is discussions'intention that some
upcoming solutions become better. people express themselive opinions here,
so different opinions are common.
>
> (I'm proud of my restraint - not even once using a term
> "B*S*" :-) _______________________________________________
> Hokeyp mailing list
> Hokeyp at opendiameter.org
> http://www.opendiameter.org/mailman/listinfo/hokeyp
>
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.