Subject: Re: [Ietf-krb-wg] PROTO review comments on draft-ietf-krb-wg-kerberos-set-passwd-07.txt

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Feb 2008 02:20:08 -0600

On Wed, Jan 30, 2008 at 05:14:03PM -0500, Jeffrey Hutzelman wrote:
> --On Wednesday, January 30, 2008 03:55:48 PM -0600 Nicolas Williams 
> <[email-masked]> wrote:
> 
> >On Wed, Nov 07, 2007 at 03:03:08PM -0500, Jeffrey Hutzelman wrote:
> 
> >>[JTH.4] (Section 3.5) "The server SHOULD localize...".  This should
> >>probably say "... when possible" or some such.  Every implementation will
> >>have cases where it cannot localize.
> >
> >Isn't "SHOULD" sufficient?  Why does it need a qualifier?  Why not "MUST
> >... where possible"?  That would seem stronger in just the right way.
> 
> SHOULD is actually pretty strong.  I don't recall what I was getting at 
> here, but I suspect I was trying to make it a bit weaker by providing 
> conditions in which the SHOULD does not apply.

That seems unnecessary.  "SHOULD" already does what you want.

> >>[JTH.6] (Section 3.6) The protocol no longer uses extensibility markers
> >>throughout.
> >
> >Indeed.  We had a discussion about this.
> 
> Yup.  I believe the intent of the comment was "... but this section still 
> _claims_ it uses them throughout".

Actually, extensibility markers are retained in many places, just not in
each operation's SEQUENCEs.

> >Should we have an operation for listing available operations?
> 
> Possibly.  I think that only becomes relevant when we start having multiple 
> extensions that add different operations.

You can always probe them.

> 
> >>[JTH.17] (Section 6) The second paragraph states:
> >>   Clients SHOULD NOT negotiate support for legacy major versions
> >>   of this protocol unless configured otherwise.
> >>
> >>I think you mean "unless configured to do so".
> >
> >Same thing.
> 
> IMHO my formulation is clearer.

I don't agree.  I think this is not a significant issue anyways.  The
RFC-Editor will probably do whatever is best here.

> >>[JTH.20] * (Section 7.2) Framing is incorporated by reference from
> >>RFC3244; thus, this is a normative reference.
> >
> >But RFC3244 is Informational.  What to do?
> 
> The nature of the reference is normative; the type of document being 
> referenced is not relevant to this fact.  The reference should be moved.

OK.

> Then you can ask whether it is OK for a standards track document to have a 
> normative reference to an informational RFC.  The answer is "yes", but it 
> will have to be called out explicitly in the last call.

OK.

> An alternative would be to repeat the framing description in this document, 
> avoiding the need for the normative reference.

Yeah, but I'd rather avoid that.

> I look forward to your responses, discussion from the WG on the issues 
> we've raised, and perhaps a new version of the document.

I think we need a new version only for the moving the reference to
RFC3244 to the normative references section.  But is that worthwhile?
Can't this just be a note to the IESG and RFC-Editor?

Nico
-- 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Feb 2008 12:51:53 -0500

--On Monday, February 25, 2008 02:20:08 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> >> probably say "... when possible" or some such.  Every implementation
>> >> will have cases where it cannot localize.
>> >
>> > Isn't "SHOULD" sufficient?  Why does it need a qualifier?  Why not
>> > "MUST ... where possible"?  That would seem stronger in just the right
>> > way.
>>

Fine.  I can't remember what I was trying to accomplish here, and the 
current text seems OK, so let's just leave it alone.

>> >> [JTH.6] (Section 3.6) The protocol no longer uses extensibility
>> >> markers throughout.
>> >
>> Yup.  I believe the intent of the comment was "... but this section
>> still  _claims_ it uses them throughout".
>

Yes, they are.  I'm not arguing for any changes to where extensibility 
markers are used.  The point is simply this: The first paragraph of section 
3.6 says "The protocol... uses extensibility markers throughout.".  I read 
"throughout" as "everywhere", and while that was true when the sentence was 
written, it is no longer true.  Thus, the statement is in error and IMHO 
should be corrected or removed.

>> Possibly.  I think that only becomes relevant when we start having
>> multiple  extensions that add different operations.
>

Indeed.  So, I think we've agreed that we don't need to introduce any sort 
of capability negotiation mechanism at this time.

> I don't agree.

Fine.

> I think this is not a significant issue anyways.

We certainly agree on this.

> The RFC-Editor will probably do whatever is best here.

Possibly.  Keep an eye on this section in AUTH48, to insure the meaning 
isn't inadvertently changed.

> Can't this just be a note to the IESG and RFC-Editor?

I think we need a new version for the other textual changes you've made in 
the course of this discussion.  If it were just moving the reference, then 
yes, we could certainly do that in an RFC-Editor note.

I believe all of the issues I've raised have been addressed, except that I 
still haven't heard from anyone that they've actually compiled the ASN.1 
module, and this is a requirement before we can move forward.

-- Jeff