Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 14 October 2016 17:54 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992CC12986D; Fri, 14 Oct 2016 10:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zHtA6-tBIkpt; Fri, 14 Oct 2016 10:54:20 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 11CC612986F; Fri, 14 Oct 2016 10:54:20 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id 83so99516520vkd.0; Fri, 14 Oct 2016 10:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lK1fQhPywjUz7DOnXT+SAyhtwEO/q6cW+/S0IOizAQ0=; b=Zwrc5TQUEqS9NsjhqX8Cbe/KaPf5CXT6fpVrI3DB6pizHX8YHPIRGd5jPy4BAxTH12 gfSBpSNbRSoheAe+jUAAMywKqoeEcKAkKpbWlw8A+3nH6hVF4rHTrEhO310Ts3e7nLt/ 9YP0aCu40cq9Ra4HvJHvIvlTBq8U07hxo7iD+lnzaaWIfAHTbQYnAwNsn9/Pf9I2B/uX Xtm4zVkJQ3bHDx4YhcAra99Qafpf7bbxLUKMvqkfLmZCvcQcHJF/btS3UzzuI0iwK7Zq LAnB+3DPJZuHHPZfsVO4V2+sEt+yhY9CM8JnTPazghDppLVI+ShjssZb5jVpZYOqcjnQ AADw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lK1fQhPywjUz7DOnXT+SAyhtwEO/q6cW+/S0IOizAQ0=; b=RAGfO5beRFJRjdF3QQdOQNkmyjnqJrufAtLMP/mIx/CsqJzKgY1eH6ZvpR7dIB35pF kS++l5u0hrflBJpb5Uv5m6tVxSZ2Y638mfoNiUQt6K35TFiosRrR112L4ZXtqMcniMmp Xb0NuDxbYA93i8rtBWeCYl+BemltOf8uCh+3Nqg5a6kHq2wnV9iNAoVztGi6moIA7SiQ vPLui3HtXbHZBZzAROO6jApoyPR28ZFnUGL3WCQBWshS28OqnY1OwqeW3eRfqS2CpBni TahlFo9ETLpHoY1M4jvWMkYn/zbbnyXNc5TCwPm0xf6C8Jq9MEPuMxQWhvWDo1h5APpG QiQw==
X-Gm-Message-State: AA6/9RlqudqR1kGOHk0mkp+opX6aH0lEw+UZ6Ey40i9UU4xQaPZJ1OKZAahynZUfqUMuvMxMbAQSw56DC1EeKw==
X-Received: by 10.31.73.71 with SMTP id w68mr7997611vka.13.1476467659184; Fri, 14 Oct 2016 10:54:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.82.68 with HTTP; Fri, 14 Oct 2016 10:54:18 -0700 (PDT)
In-Reply-To: <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com>
References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <CAHbuEH7+Gw=zDiN66Aydmie2M4dXcVqjLKWHixR7Qe6ECfN9Hg@mail.gmail.com> <D0152C61-D391-482B-BF1E-45180F89DA41@cooperw.in> <EACFFDF5-3974-4778-8EDD-A68410BAD972@gmail.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> <32661_1476458174_5800F6BE_32661_2282_1_6B7134B31289DC4FAF731D844122B36E03D07880@OPEXCLILM43.corporate.adroot.infra.ftgroup> <02671AAF-B095-42FC-8BD8-37D2C847CD5A@deployingradius.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Fri, 14 Oct 2016 13:54:18 -0400
Message-ID: <CAHbuEH4Ai146sv1gvC00zSwwzA7v6+4yJO=fozp7U6nJvvaZ8g@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Content-Type: multipart/alternative; boundary="001a1148d00a591ffb053ed6ea9f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/ga-YsSA2oCqWE9sicUdbdf3ngLM>
Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" <draft-ietf-radext-ip-port-radius-ext@ietf.org>, "radext@ietf.org" <radext@ietf.org>, "lionel.morand@orange.com" <lionel.morand@orange.com>, Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, "radext-chairs@ietf.org" <radext-chairs@ietf.org>
Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2016 17:54:22 -0000

On Fri, Oct 14, 2016 at 11:42 AM, Alan DeKok <aland@deployingradius.com>
wrote:

>
> > On Oct 14, 2016, at 11:16 AM, <lionel.morand@orange.com> <
> lionel.morand@orange.com> wrote:
> > Can you elaborate a little bit?
> > What do you call 'appropriate parent TLV'?
>
>   The idea is that if you have a TLV, it can:
>
> a) define it's own sub-TLVs
>
> b) use a pre-defined registry for sub-TLVs.
>
>   That's it.
>
>   If a TLV is defined to use option (a), there's no conflict with other
> TLVs.  It's sub-TLVs are completely independent of all other sub-TLVs.  And
> it *cannot* use TLVs from a registry.
>
>   If a TLV is defined to use option (b), then it *cannot* define it's own
> sub-TLVs.  It MUST use the registry.  Which means re-using sub-TLVs from
> the registry.  Because that's what registries are for.
>
>   sub-TLVs defined in a registry can't conflict with other sub-TLVs,
> because each TLV space is entirely independent... unless you define them to
> overlap.
>
> > If a registry is defined to track allocated value for sub-TLV, how to
> avoid collision if "All other TLV parents are free to specify whatever
> sub-TLVs they want".
>
>   That question is based on assumptions I don't understand.  As such, it
> can't really be answered other than with "it doesn't work like that".
>
>   If we have a registry, fine.  Use it.  If we don't have a registry, then
> attributes not using the registry... don't use the registry.  And there's
> no conflict.  Because they're not using the registry.
>
>   There is no more conflict here than with Service-Type and
> Framed-Protocol.  Both are "integer" attributes.  Both define a registry.
> But adding an entry to Service-Type doesn't mean that that number is now
> also defined for Framed-Protocol, much less have any special meaning for
> any other "integer" attribute.
>
>   Perhaps you could explain why you think there would be any conflict
> between sub-TLVs?
>

It seems the WG is just down to a preference question as I don't see how
there would be conflicts except if different parties defined their own
sub-TLVs and they didn't match.  Could that occur?  I have to dig deeper to
make sure I'm not missing anything.

For the future, you can ask IANA these sorts of questions via email or at
meetings to work through preferences if you are looking for their opinion.
I should have caught that this was an issue and am not sure why I didn't
before putting it on a telechat.  So, that was my fault.

Thank you.

>
>   Alan DeKok.
>
>


-- 

Best regards,
Kathleen