Re: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00

Matt Rogers <mrogers@redhat.com> Mon, 10 April 2017 18:14 UTC

Return-Path: <mrogers@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5358C1270A0 for <kitten@ietfa.amsl.com>; Mon, 10 Apr 2017 11:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwEbAl8Aswik for <kitten@ietfa.amsl.com>; Mon, 10 Apr 2017 11:13:59 -0700 (PDT)
Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB424129A8F for <kitten@ietf.org>; Mon, 10 Apr 2017 11:13:58 -0700 (PDT)
Received: by mail-qt0-f175.google.com with SMTP id c45so70822494qtb.1 for <kitten@ietf.org>; Mon, 10 Apr 2017 11:13:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oinQfFm1WZkEauNhj9Wcn1H4RQBwZR1jSQ5sa3fibXw=; b=EPc9/Ma4uCYl2WOOamUZ39k4g270gXM+Y2bETrNgOboHqgIgdGlRgTYyPejpTSzAvq Q3yvTEoWk51EzyBRk9oi6HnIQTPujdXyz1OlibXIJ1E6+ZXzcPSuWtEci478SFsDQoM3 myiXu8k/XyPIa1IGOtfJELE0IjIzfQVwjZtBULOY6n+v+ULi5W8Q5Qzp75xrvUYpe//7 OzVHgdFOvA4PnAUL/iIDPvk+jmiRFgwWYH3QAfi2WOw2wcxQ0k87Jl3V0+OTBeX2va3T 6a3xKNfx/ZbJzdbDKKj5FJmA4j7NvA6M8IKxFsJS+wSqnlYK8TZzCZVacD8roGdaRHB/ b7Tw==
X-Gm-Message-State: AFeK/H1wuq9Cc5eaed+MPXjW57O+K6Gm9TI5k0wjNo7bbrVRQOgJeDgi9L741PK9ENEzwJ3jJMUCVO3E4e5JwvFq
X-Received: by 10.200.3.46 with SMTP id q46mr58300679qtg.243.1491848038095; Mon, 10 Apr 2017 11:13:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.175.181 with HTTP; Mon, 10 Apr 2017 11:13:27 -0700 (PDT)
In-Reply-To: <2ccb915d-4a10-1ced-d8c8-298e1aec6373@mit.edu>
References: <x7dzige39sj.fsf@equal-rites.mit.edu> <CAAeFVfwexk8THERJZ5Qm+sTB+FVMWsRSOXninGFmMWehzwiz-A@mail.gmail.com> <2ccb915d-4a10-1ced-d8c8-298e1aec6373@mit.edu>
From: Matt Rogers <mrogers@redhat.com>
Date: Mon, 10 Apr 2017 14:13:27 -0400
Message-ID: <CAAeFVfwY2T3XndS3=bJ3qBqiv4=_pSM-UkOtGPG6gCq+1yM2mw@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kitten@ietf.org, Benjamin Kaduk <kaduk@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/yrjoc9Y5xaWBvYNvk9J1FkVmF0g>
Subject: Re: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2017 18:14:00 -0000

On Mon, Apr 3, 2017 at 12:32 PM, Greg Hudson <ghudson@mit.edu> wrote:
>
>   The URI RR has service information encoded in its ownername.  In
>   order to encode the service for a specific owner name one uses
>   service parameters.  Valid service parameters used are either
>   Enumservice Registrations registered by IANA, or prefixes used
>   for the SRV resource record.
>
> which seems like a slightly more restrictive statement than the one in
> RFC 7553.  We may need some guidance from the chairs or ADs on the
> mechanics of moving forward here.  Simply making the reference
> informative doesn't seem sufficient, as the URI RR type is fundamental
> to this standard.
>
> (To be clear, I think what we're doing ought to be fine, and that it's
> generally pointless to include a transport label in a URI record owner
> name like one would in a SRV owner name.  The question is one of
> conformance with the pre-existing standard, not practicality.)
>

I'll leave this as normative at the moment, but perhaps it warrants
some text to explain the difference between our use of the owner name
and the RFC 7553 guidelines.