Re: [radext] [AD] AUTH48 [LB]: RFC 8044 <draft-ietf-radext-datatypes-08.txt> NOW AVAILABLE

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 11 January 2017 16:43 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 6F8B3129F11; Wed, 11 Jan 2017 08:43:10 -0800 (PST)
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 sAazaDa1M4Kt; Wed, 11 Jan 2017 08:43:09 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 DA19B129F08; Wed, 11 Jan 2017 08:43:08 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id 11so115876566qkl.3; Wed, 11 Jan 2017 08:43:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gD4lZC+RT6wnV6LqSXbmERQUGi+rLhms+7llCXqHOVQ=; b=LcDpvEzBgq8ghlJ0p1wCnL/DKm3+Zn3EiTcC64ZPd/NURqw4YdQ5lZLlBpZPm20yir dSZqm0OfYkZT3nB+H60/EFG3oWg/ainfFYJe3X8JETqxj9JaV7N6+kUwsvWGTwO0gl2d 5mwkzjktVfptnmlkrnSt1fin31omONIQhtZs1mXSkCG0mnrBxPIWucA9Sa6SKVT1SHMp z8g4BbQSaxCM3vzHJkcVkJsBbrc1JPitGvGoAFg6C38iwP44SS7zw46CK7qer8dHDQMk LjgVa3CqkyqkBN6CXw7OdEalb0c9Nkt4JKIzt3+TLxUhV226hU2ZobWXHXMVPxtK6k53 JjTA==
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=gD4lZC+RT6wnV6LqSXbmERQUGi+rLhms+7llCXqHOVQ=; b=dtHjtH2LLqemlb/LkgO7NHUBcdQQnZ/dkDobBRx2LqXC18bQsvrqUePWTH4jpYP37P gKCxZtdYie7TVIc02Y6bKeDJjG6J9otLy4iaul0f0mELa0LlMw0Xr32DaamcTYnj/ocl GpILf5b0x0Gdm9YNcSaujQAbeRSax5DSJhKVeYW8YNypMOBUHJaYBx8sljosFz41h0Gk DnPqdA0GNP520uQZe2D4LlRxHGxLxk+IHsz3ZZvQqmCQjGQVcfPYsqMpUrT0O/UThn5S uwoJuwhCCfBGBm2cUgUGj7Lsv3uHpX9HdL9mHSmPPRVmCyf3C4brN9ahG2aQ+Psu1AqP CoxQ==
X-Gm-Message-State: AIkVDXJpSDVfM1kjgN6YIfzCfbTwwJecdJZGDnGmOkjjH0mKxy5lWoCHV+EIdbYNaukqjSc4nYipbRbrDH0LXA==
X-Received: by 10.55.162.65 with SMTP id l62mr8831071qke.17.1484152988041; Wed, 11 Jan 2017 08:43:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.161.101 with HTTP; Wed, 11 Jan 2017 08:43:07 -0800 (PST)
In-Reply-To: <FF91E7C3-72C4-4F77-A957-ED8219B9C523@freeradius.org>
References: <20170109233022.14EE5B81304@rfc-editor.org> <CAHbuEH7A2+WyuexCVtFsk8bFGMG5nqOEDwbZY12oVgmwZtaJ5w@mail.gmail.com> <FF91E7C3-72C4-4F77-A957-ED8219B9C523@freeradius.org>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Wed, 11 Jan 2017 11:43:07 -0500
Message-ID: <CAHbuEH7-E9VUH+ZxJdqQpr=hjhKFf0obEPLKZLwJHUZBmqF21w@mail.gmail.com>
To: Alan DeKok <aland@freeradius.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: multipart/alternative; boundary=001a114d83cea505ee0545d44b05
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/Q7SONPhKD-_Vv4ehnTbEQvYwMBQ>
Cc: Winter Stefan <stefan.winter@restena.lu>, "radext@ietf.org" <radext@ietf.org>, radext-chairs@ietf.org, radext-ads@ietf.org, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Re: [radext] [AD] AUTH48 [LB]: RFC 8044 <draft-ietf-radext-datatypes-08.txt> NOW AVAILABLE
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: Wed, 11 Jan 2017 16:43:10 -0000

Adding the IESG and the working group to see if there are any concerns with
the following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org> wrote:

>
> > > > a) RFCs 4072 and 7268 are not cited anywhere in this document.
> > > > Please let us know where they should be cited; otherwise, the
> > > > listings will be removed.
> > >
> > > The RFCs are referenced simply because this document is updating
> > > attributes that they define.
> >
> > Can you please list the specific updates from the 2 mentioned RFCs here
> and then I'll figure out if this needs to go back through the WG and last
> calls or not.
>
> http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-
> types-2
>
>   RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, but t's
> defined to have a Diameter data type "OctetString".   We can't use
> "OctetString" for a RADIUS data types, so the "data types" document defines
> it as the RADIUS data type "string". Which ends up being the same for all
> intents and purposes.
>
>   RFC 7268 defines a bunch of attributes.  Most are of 32-bit integers,
> which maps well to the data types doc.  The only real "new" thing is
> EAPoL-Announcement.  It's defined manually in RFC 7268 as "concatenate the
> fragments together before looking at it".  The data types doc calls this
> out as a special data type "concat", along with EAP-Message, and a few
> others.
>
>   I think everyone is in agreement as to what the data types should be.
> The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 talks
> about this attribute, but doesn't really give an adequate definition for
> it.  So the data types document picks something, which is compatible with
> the original definition, but uses a now-standard data type"
>
>   i.e. the original spec isn't so much wrong, as unclear and incomplete.
>

This seems like a small enough 'updates' that I think it should be fine to
progress just adding the note that RFC4072 and RFC7268 are updated.

Any objections?  The alternative would be to put this back through the last
call process, but I think this looks small enough to avoid that.  It would
really just be for process sake IMO.


>   Alan DeKok.
>
>


-- 

Best regards,
Kathleen