Subject: RE: Open Issues on draft-ietf-kitten-2478bis

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Wed, 24 Nov 2004 17:42:29 -0800

Martin Rex wrote:
> Folks, this is NOT about whether we put MAY or SHOULD into an entirely
new document.  

Your claim is ridiculously false!  Vanilla 2478 does not contain a "MAY"
in the terminology of RFC 2119. Even if a MAY were in RFC 2478,
promoting it to a "SHOULD" does not break compatibility: the *receiver*
will need to handle the optimistic token even we use a "MAY" there.

-- Larry

P.S. I do not want to go too far on this, but would the word "bloody
sports" rings a bell here?

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, November 24, 2004 2:50 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: Open Issues on draft-ietf-kitten-2478bis

Liqiang\ wrote:
> 
> Jeff wrote:
> >    Is there consensus on the mailing list?
> 
> Humm... This sounds a call for the duty of the chair. 
> 
> Folks, if you spoke before, I urge you to speak again.
> 
> Ken, Sam, Nico, Wyllys, and me preferred "SHOULD", please speak if 
> this is accurate.

If the consensus context was about the MAY or SHOULD support optimistic
token, then I have Ken on the record for MAY (from his posting to this
mailing list, I don't know about IETF hallway discussions).

Folks, this is NOT about whether we put MAY or SHOULD into an entirely
new document.  This is about whether there are strong reasons that
justify changing a MAY into a SHOULD for an existing spec.

As it is, such a change will not affect interoperability, so a change is
neither necessary nor advisable.

> 
> > There was a discussion on the history of the term "mechanism
> >   variants".  
> 
> Section 6 actually described what is a "mechanism variant". I agree we

> can add a forward reference here.

Sorry, but I strongly disagree.
Section 6 further adds to the confusion by being extremely
ambiguous/vague, and the motivation for rev'ving rfc2478 was to reduce
ambiguity.

Either we drop the mentioning of variants entirely or we standardize
them in a non-ambiguous fashion. (Which might prove rather difficult,
given the original ambiguity an few, if any, actual use in
implementations.

Anyone from Bull or the Original SESAME project listening?

SESAME was the European counterpart for DCE, partly funded as a research
project of the Europeaon union and a cooperation of at least one
University and three companies Bull (FR), SSE/Siemens (IR) and ICL (UK)
?

-Martin

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Sat, 27 Nov 2004 16:16:33 -0500

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    >> Folks, this is NOT about whether we put MAY or SHOULD into an
    Liqiang(Larry)> new document.

    Liqiang(Larry)> Your claim is ridiculously false!  Vanilla 2478
    Liqiang(Larry)> does not contain a "MAY" in the terminology of RFC
    Liqiang(Larry)> 2119. Even if a MAY were in RFC 2478, promoting it
    Liqiang(Larry)> to a "SHOULD" does not break compatibility: the
    Liqiang(Larry)> *receiver* will need to handle the optimistic
    Liqiang(Larry)> token even we use a "MAY" there.

    Liqiang(Larry)> -- Larry

I wouldn't use language as strong as Larry, but I do agree with what
he says.  Promoting MAYs to SHOULD based on implementation experience
is one of the things that commonly happens as standards are revised.
Promoting SHOULD to MUST also happens; if you do that you need to
recycle at proposed because you may cause implementations of the old
spec not to conform to the new spec.

You definitely want to make it possible to write an implementation
that will work with the new and the old spec.

I think a lot of Martin's reluctance here may come from the API part
of GSSAPI.  Interoperability rules for an API are more tricky in some
ways than for a protocol. 

--Sam