Subject: Re: [Ietf-krb-wg] AppsDir review of draft-ietf-krb-wg-kdc-model

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Jun 2012 12:02:29 -0400

>>>>> "Tobias" == Tobias Gondrom <[email-masked]> writes:

    Tobias> One basic question:
    Tobias> This draft aims for Standards Track, yet as far as I understood, it is
    Tobias> not required that the used field names are in fact the same across
    Tobias> different implementations but only that name-mappings exist. The ID
    Tobias> also uses a modified RFC2119 language definition to allow that.
    Tobias> I would like to ask, whether possibly Informational Status would be
    Tobias> more appropriate for this draft?

My concern is that this does specify mandatory behavior of
implementations and that it's likely that a schema would want to
normatively refer to this document for semantics of attributes.

    Tobias> reference to expired ID: draft-ietf-krb-wg-kerberos-set-passwd
    Tobias> Am not so happy that the draft refers to drafts (which is expired in
    Tobias> 2009) for set/change password protocol. I lack the knowledge of the
    Tobias> context of why the WG chose to expire this ID at the time and why it
    Tobias> is now used as a reference here. Is there another resource you could
    Tobias> refer to instead? Do you want to revive the set-passwd ID?
    Tobias> Especially as the reference is part of a mandatory part ("SHALL only")
    Tobias> of the security considerations 6, I am having a hard time to see this
    Tobias> as only "informational" and how to refer here to an expired draft....

Leif, I think it would be desirable to clean up section 6 to imply that
we expect there to be protocols to use to write keys such as the
set/change password protocol.  Possibly adding a note that a schema that
implements keys at all is expected to choose a normative protocol for
writing key objects.

Do people think that would be a good approach for this?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 04 Jun 2012 13:51:33 -0400

On Mon, 2012-06-04 at 17:38 +0100, Tobias Gondrom wrote:
> On 04/06/12 17:02, Sam Hartman wrote:
> >>>>>> "Tobias" == Tobias Gondrom<[email-masked]>  writes:
> >
> Does it have to be Standards Track for that purpose?
> (note: I don't have a strong opinion on this, just feel uneasy with 
> using the watered down 2119 definitions in the draft and the 
> name-mapping, and then to go for Standards Track....)

The present document is a data model.  Its "implementations" are schemas
or the like; that is, other documents.  The RFC2119 language is in fact
not "watered down"; rather, it is the case that, for example, we may
REQUIRE a schema to include a particular field without requiring that
every implementation of that schema support that field.

The particular point you raised about names is not, in fact a problem.
Read with the understanding that an implementation of this document is a
schema or the like and _not_ a piece of software, the language in the
third paragraph of section 1 means that an LDAP schema or XML DTD based
on this document would not be required to use the same field names as
are used in the model, provided the document defining such a schema or
DTD makes clear which of its fields correspond to which fields in the
data model.

Yes, this document wants to be standards track.  It is intended to
define the semantics of data items used by the KDC and made visible in
one or more standards track management protocols.

> On a personal note: Would still be curious about the intentions for 
> draft-ietf-krb-wg-kerberos-set-passwd?

It is an item on our current charter, to which we intend eventually to
return.  Both the author and the working group have been concentrating
on other work for some time.

-- Jeff

---

From: Leif Johansson <[email-masked]>
Date: Tue, 05 Jun 2012 14:08:57 +0200

> To me this reads that, first the schemas will not have direct

Correct. Direct interoperability between (say) XML schema and
LDAP schema is not a useful goal. The fact that they represent
the same underlying model is.

Does that clarify things?

	Cheers Leif

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 Jun 2012 09:53:56 -0400

On Tue, 2012-06-05 at 13:29 +0100, Tobias Gondrom wrote:
> Question: In the light of this, why does the ID aim for Standards
> Track (and not for Informational)?

Because it is intended to be the basis for standards-track schema
documents, which will specify presentation but incorporate semantics by
reference from this document.  Multiple schemas/DTDs/whatever based on
this document are isomorphic representations of the same data, and the
structure and semantics of that data are standardized here.

-- Jeff

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 05 Jun 2012 15:41:16 +0100

> structure and semantics of that data are standardized here.

Ok. Can see your point.

Best regards, Tobias

---

From: Leif Johansson <[email-masked]>
Date: Mon, 04 Jun 2012 18:33:10 +0200

On 06/04/2012 06:02 PM, Sam Hartman wrote:
> Tobias> One basic question: Tobias> This draft aims for Standards
> Track, yet as far as I understood, it is Tobias> not required that
> the used field names are in fact the same across Tobias> different
> implementations but only that name-mappings exist. The ID Tobias>
> also uses a modified RFC2119 language definition to allow that. 
> Tobias> I would like to ask, whether possibly Informational Status
> would be Tobias> more appropriate for this draft?
> 

Yes.

> 
> Tobias> reference to expired ID:
> draft-ietf-krb-wg-kerberos-set-passwd Tobias> Am not so happy that
> the draft refers to drafts (which is expired in Tobias> 2009) for
> set/change password protocol. I lack the knowledge of the Tobias>
> context of why the WG chose to expire this ID at the time and why
> it Tobias> is now used as a reference here. Is there another
> resource you could Tobias> refer to instead? Do you want to revive
> the set-passwd ID? Tobias> Especially as the reference is part of a
> mandatory part ("SHALL only") Tobias> of the security
> considerations 6, I am having a hard time to see this Tobias> as
> only "informational" and how to refer here to an expired draft....
> 
> Leif, I think it would be desirable to clean up section 6 to imply
> that we expect there to be protocols to use to write keys such as
> the set/change password protocol.  Possibly adding a note that a
> schema that implements keys at all is expected to choose a
> normative protocol for writing key objects.
> 

Yeah that is totally doable.

	Cheers Leif

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 04 Jun 2012 17:38:46 +0100

> Do people think that would be a good approach for this?
Would work for me.

Best regards, Tobias

---

From: Leif Johansson <[email-masked]>
Date: Mon, 04 Jun 2012 20:58:42 +0200

On 06/04/2012 06:38 PM, Tobias Gondrom wrote:
>> Tobias>  One basic question: Tobias>  This draft aims for
>> Standards Track, yet as far as I understood, it is Tobias>  not
>> required that the used field names are in fact the same across 
>> Tobias>  different implementations but only that name-mappings 
>> exist. The ID Tobias>  also uses a modified RFC2119 language
>> definition to allow that. Tobias>  I would like to ask, whether
>> possibly Informational Status would be Tobias>  more appropriate
>> for this draft?
>> 
> Does it have to be Standards Track for that purpose? (note: I don't
> have a strong opinion on this, just feel uneasy with using the
> watered down 2119 definitions in the draft and the name-mapping,
> and then to go for Standards Track....)

It isn't watered-down at all! The reason we have that section is to
clarify what an implementation of the information-model actually is (a
schema) and what it means to be compliant with the information model.

The RFC2919 terms mean what they always mean - just in a non-typical
context (i.e not just viz an bits-on-the-wire implementation)

	Cheers Leif

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 05 Jun 2012 13:29:17 +0100

On 05/06/12 13:08, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/N9tUACgkQ8Jx8FtbMZneLbwCgsX+Zi9/noL1o3Q/1hhpOVhBh
> eN8An17oppZSQn6lzfhmfSyqR4EJMkRw
> =s/FA
> -----END PGP SIGNATURE-----
Thank you for the confirmation.
Question: In the light of this, why does the ID aim for Standards Track 
(and not for Informational)?

Best regards, Tobias

---

From: Leif Johansson <[email-masked]>
Date: Tue, 05 Jun 2012 14:37:11 +0200

On 06/05/2012 02:29 PM, Tobias Gondrom wrote:
> Correct. Direct interoperability between (say) XML schema and LDAP
> schema is not a useful goal. The fact that they represent the same
> underlying model is.
> 
> Cheers Leif Thank you for the confirmation. Question: In the light
> of this, why does the ID aim for Standards Track (and not for
> Informational)?

Because a standards-track LDAP schema (say) may need to _implement_
this information-model.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 05 Jun 2012 12:27:56 +0100

> context (i.e not just viz an bits-on-the-wire implementation)

Leif, Sam and Jeff,
thank you for your answers.
As I said I have no strong opinion on the Intended Status, but at the 
moment my concerns remain.
Please let me explain why I perceived 2119 to be watered down in this case.

Maybe to provide the context, let me copy the relevant sections from the 
draft once more here:
section 1 states:
" Implementations of this document MAY decide to change the names used
    (e.g. principalName).  If so an implementation MUST provide a name to
    name mapping to this document.  In particular schema languages may
    have different conventions for caseing, eg camelCase vs use of '_'
    and '-' to separate 'words' in a name.  Implementations MUST call out
    such conventions explicitly."

Plus section 2:
"   This document describes an information model for kerberos 5 but does
    not directly describe any mapping onto a particular schema- or
    modelling language.  Hence an implementation of this model consists
    of a mapping to such a language - e.g. an LDAP or SQL schema.  The
    precise interpretation of terms from [RFC2119] therefore require some
    extra explanation.

    The terms MUST or REQUIRED means that schema implementing this model
    must have a way to represent the feature (i.e that it is mandatory to
    implement) but that unless otherwise specified the feature may
    represent an optional element in the chosen schema definition
    language.

    However MUST also means that a KDC or administrative interface
    implementing this information model MUST provide the feature and
    associated behavior consistent with schema."

To me this reads that, first the schemas will not have direct 
interoperability, because they can use different names, etc. (Yes, I 
read that there must be a mapping, still direct interoperability remains 
a question.) And second the MUST requirement feels for me vague ("must 
have a way to represent the feature"). All this reads to me more like an 
Informational RFC rather than a Proposed Std.
Of course it is open whether you want/need interoperability between 
different kdc models at the schema level. Probably you don't really. In 
which case again the question pops up why Std Track and not Informational?

But as I said, this is only my humble opinion.
Maybe the best way would be for the AD to simply give this a quick look 
in the IESG during LC.
And if the WG has discussed that aspect already before and came to the 
consensus that Std Track is the right way to go, I would not see a need 
to re-open that discussion.

Best regards, Tobias

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 05 Jun 2012 12:07:43 +0100

> one or more standards track management protocols.

Will try to answer to that together with Sam's and Leif's email.

> on other work for some time.

It expired in 2009. That is even by IETF standards a long time to 
eventually return to the draft.

Best regards, Tobias