Re: AppsDir review of draft-ietf-krb-wg-kdc-model

On 04/06/12 19:58, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/04/2012 06:38 PM, Tobias Gondrom wrote:
>> On 04/06/12 17:02, Sam Hartman wrote:
>>>>>>>> "Tobias" == Tobias Gondrom<[email protected]>
>>>>>>>> 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.
>> 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


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