From nobody Wed Aug 3 07:35:45 2016 Return-Path: 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 8523212D0C8 for ; Wed, 3 Aug 2016 07:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 haTuTM4Stcnx for ; Wed, 3 Aug 2016 07:35:36 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 AA4B512D1A9 for ; Wed, 3 Aug 2016 07:33:17 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id n129so146812260vke.3 for ; Wed, 03 Aug 2016 07:33:17 -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:content-transfer-encoding; bh=9dNk+CJ/uBDfpqgBdgloU7RRcl3H8isd7S+gY4pqA3A=; b=bKbYHg0brSNS7sDqqr8hByfqjWfjrwWWRDmS/6460A0WVV+etUO9UV9pYWbCmlax8d dSeARhJ/a1/3JNw5cWyYI6V+DPYjtFAL/sbwj/M6xTDgFLyuQqGhcF5aqpwi2VOJLLZ7 Lupo79N1VfYaCr8xbeky52UKOg7Y376EcjQFQhfwOPxW/5cdnfR8Ey/pqo9HdBVTtPks TNw/iHVV55UadmeosG5/ZNZ0B9Nc0Vcjt6ty+xVLWgU+kcPwEHtzT7etGtF5Cx9vknvt Xf1Ix9HBBa+I+N/xBeE8AbP0C2v8RGew/PUV/Z38n/xfmKT2cUY+k+zJYbdyIeK2h2jx d0cg== 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:content-transfer-encoding; bh=9dNk+CJ/uBDfpqgBdgloU7RRcl3H8isd7S+gY4pqA3A=; b=VVazBs2bHlqPaPl4Qwah1fuZIWdV0CnuKL4PJVC+QzyNs8WtWvX+jB/H8672B78IyH mT5mWkxML3Z2fe5ph8i3Fc2SA+ABhqyoNQxR/4ttxbr5IzIMVAMfgsbv5MxPBoxbCuwl rgINW6sPcvVhI5BwOyqs8ll6sk/90KWUTwJCQjS5UA5EPC4KItXXFBS0v6WKqoGBbv/R YXzCmYEzQ2hI2J9Gsmf8iTCE9B/smwiGSZxkOWbV35W4an1db150HqMwguzlCdA+FpDk hDlJ2ttiEhJL3ofCj4gCMajQlM2aPBP6Ljd5mD5PQ/PvPwrO9vqSyUqDSGa8iaCabYOZ 3Njw== X-Gm-Message-State: AEkoouvKxeEYDpO+1+YzTKKIH2CQXkaYqR77p1duwFcirqt7oMzhzjGKoaNgcaWTrOw4sJ8YdrN8cYLor/QEOw== X-Received: by 10.31.174.141 with SMTP id x135mr33109141vke.25.1470234796672; Wed, 03 Aug 2016 07:33:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.37.104 with HTTP; Wed, 3 Aug 2016 07:33:16 -0700 (PDT) In-Reply-To: References: <29432_1468945047_578E5297_29432_1897_1_6B7134B31289DC4FAF731D844122B36E01F147FC@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Kathleen Moriarty Date: Wed, 3 Aug 2016 10:33:16 -0400 Message-ID: To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:35:44 -0000 Hello, Is there any chance we could get the abstract updated so I can put this in IETF last call in time for the telechat in 2 weeks? That means the update would be needed by today. Thank you, Kathleen On Thu, Jul 28, 2016 at 2:52 PM, Kathleen Moriarty wrote: > Hi, > > Sorry I didn't see this sooner. In reading the shepherd report, I see > that the abstract should also list the RFCs this updates. Could that > be added and then I'll kick off last call? I'll put it on the > telechat in 3 weeks now. > > On Tue, Jul 19, 2016 at 12:17 PM, wrote: >> Hi, >> >> Would it better to add (or repeat) such clarifications in the IANA consi= derations section? > > I think it's fine to refer back to a single location since there are > no changes. It's a rather complex IANA section. >> >> As a new version (simple update so far) is required anyway, I think it i= s OK to wait for this new version and launch the IETF LC with a normal 2-we= ek period at least the next week (or ASAP after publication of the draft). > > OK, thanks! I'll start last call as soon as the abstract fix is in as > that should be very simple and I'd rather avoid more people commenting > on the same thing. > > Thanks, > Kathleen > >> >> Regards, >> >> Lionel >> >>> -----Message d'origine----- >>> De : radext [mailto:radext-bounces@ietf.org] De la part de Kathleen Mor= iarty >>> Envoy=C3=A9 : mardi 19 juillet 2016 17:43 >>> =C3=80 : Alan DeKok >>> Cc : radext@ietf.org >>> Objet : Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-ra= dext- >>> datatypes-04.txt >>> >>> Hi Alan, >>> >>> Thanks for the quick response. inline. >>> >>> On Tue, Jul 19, 2016 at 11:20 AM, Alan DeKok >>> wrote: >>> > On Jul 16, 2016, at 10:48 PM, Kathleen Moriarty >>> wrote: >>> >> >>> >> Hello, >>> >> >>> >> Thank you for another very well written draft that serves a clear >>> >> purpose and is easy to read and understand. I just have 2 questions >>> >> that should be really easy and then would like to know when the WG >>> >> prefers me to start IETF last call. And if you'd like IETF last cal= l >>> >> to start this week, should it be extended for a 3rd week? >>> >> >>> >> Comments/questions: >>> >> Section 2.1.1 >>> >> Should this say "be of a valid data type" >>> >> Attr-Data >>> >> >>> >> The "Value" field of an Attribute as defined in [RFC2865] >>> >> Section 5. The contents of this field MUST be a valid data >>> >> type as defined in the RADIUS Data Type registry. >>> > >>> > I'm fine with the change. I'm not sure it makes a substantive chan= ge, tho. >>> >>> Thanks. >>> > >>> >> IANA Section 4.2 >>> >> Does the registration policy remain unchanged from rfc3575? >>> > >>> > Yes. >>> > >>> >> If so, it >>> >> would be helpful to state that since 4.1 defines the registration >>> >> policy as requiring IETF review, >>> > >>> > The intent there is that new data types requires IETF review with S= tandards >>> Action. It doesn't change the registration requirements for the RADIUS >>> attributes registry. >>> > >>> > Maybe this is clearer: >>> > >>> > This section defines a new RADIUS registry, called "Data Type". >>> > Allocation in this registry requires IETF Review. The "Registration >>> > Procedures" for the Data Type Registry are "Standards Action". >>> > >>> >>> I'm fine with the text you have my question was about 4.2, but included= the >>> above for context on the question. >>> >>> > >>> >> different from what happens for 4.2 >>> >> according to the description in rfc3575. >>> > >>> > OK. >>> > >>> > Maybe adding text here would be good: >>> > >>> > The existing registration requirements for the Attribute Type Registr= y >>> > are unchanged. >>> >>> Perfect, thanks. >>> >>> Kathleen >>> >>> > >>> > Alan DeKok. >>> > >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> > > > > -- > > Best regards, > Kathleen --=20 Best regards, Kathleen From nobody Wed Aug 3 10:03:54 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A810712D1C7; Wed, 3 Aug 2016 10:03:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160803170348.6265.39303.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2016 10:03:48 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-datatypes-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 17:03:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Author : Alan DeKok Filename : draft-ietf-radext-datatypes-06.txt Pages : 37 Date : 2016-08-03 Abstract: RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFC 2865, 3162, 6158, and 6572. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-datatypes-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-datatypes-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 3 11:03:45 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9C12B01B; Wed, 3 Aug 2016 11:03:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160803180345.6185.91442.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2016 11:03:45 -0700 Archived-At: Cc: radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, Stefan Winter Subject: [radext] Last Call: (Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 18:03:45 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFC 2865, 3162, 6158, and 6572. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3576: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (Informational - Independent Submission Editor stream) rfc5904: RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support (Informational - IETF stream) rfc2866: RADIUS Accounting (Informational - IETF stream) rfc2867: RADIUS Accounting Modifications for Tunnel Protocol Support (Informational - IETF stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Tue Aug 9 08:28:24 2016 Return-Path: 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 62DE812D8DA; Tue, 9 Aug 2016 08:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham 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 p7qQhYyPE4bd; Tue, 9 Aug 2016 08:28:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF7112D8C8; Tue, 9 Aug 2016 08:28:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GAAQBx9alX/yYyC4ddHAEBglkhLVZ8B?= =?us-ascii?q?4VGh2Crd4E9QCOFegKBSzgUAQEBAQEBAQNaJ4JTOQYHLwEBAQEBASMCDy8SAQE?= =?us-ascii?q?cAQMSG0wSARUHDhZAJgEEDg0aiA8BDaZOmnIBAQEBAQEEAQEBAQEBAQEaBYYri?= =?us-ascii?q?GgmHoIpC1iCLwWOGIVdhUQBhhyKWIRbgyaFV5AsHjaBV4IjbwEBhWRGAX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2GAAQBx9alX/yYyC4ddHAEBglkhLVZ8B4VGh2Crd4E9QCO?= =?us-ascii?q?FegKBSzgUAQEBAQEBAQNaJ4JTOQYHLwEBAQEBASMCDy8SAQEcAQMSG0wSARUHD?= =?us-ascii?q?hZAJgEEDg0aiA8BDaZOmnIBAQEBAQEEAQEBAQEBAQEaBYYriGgmHoIpC1iCLwW?= =?us-ascii?q?OGIVdhUQBhhyKWIRbgyaFV5AsHjaBV4IjbwEBhWRGAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,495,1464667200"; d="scan'208,217";a="165300038" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Aug 2016 11:28:15 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 09 Aug 2016 11:28:14 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0294.000; Tue, 9 Aug 2016 17:28:10 +0200 From: "Romascanu, Dan (Dan)" To: General Area Review Team Thread-Topic: Gen-ART LC review of draft-ietf-radext-datatypes-04.txt Thread-Index: AdHyUp+ehzJGYnAzRqKWyh5pUHwS4w== Date: Tue, 9 Aug 2016 15:28:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA75267BC5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "radext@ietf.org" , "draft-ietf-radext-datatypes.all@tools.ietf.org" Subject: [radext] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 15:28:22 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75267BC5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am the assigned Gen-ART reviewer for this draft. The General Area Review = Team (Gen-ART) reviews all IETF documents being processed by the IESG for t= he IETF Chair. Please treat these comments just like any other last call c= omments. For more information, please see the FAQ at https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Document: draft-ietf-radext-datatypes-04.txt Reviewer: Dan Romascanu Review Date: 8/9/16 IETF LC End Date: 8/17/16 IESG Telechat date: 8/18/16 Summary: Ready with issues. This is an important document that tries to bring clarification to a number= of different interpretations and recommendations around the RADIUS specifi= cations. Being familiar - up to a certain point - with the history, I belie= ve that it's long due and that it will be very useful. There are however a = number of issues which I believe need to be clarified before the document i= s approved by the IESG. Major issues: 1. Although the document makes the claim that it does not impact prev= ious specifications and implementations, I am not sure this is completely t= he case. For example, the statement in RFC 6158, section 2.1 about 'all oth= er data formats (than the ones defined there) being NOT RECOMMENDED is obso= lete by this document. I think that there is a need to make clear what is n= ot longer valid or recommended in specifications that this document updates= . 2. This document creates a new IANA registry and updates another one.= There is no mention however about the policy of adding new entries or maki= ng other modifications to the new registry. A reminder of the RADIUS Attrib= ute Type registry policy would also help. Minor issues: 1. In section 3.5 - there is no mention that the string length is lim= ited to 253 octets. This is obvious if we assume the definition of "string= " sticking with previous RADIUS documents, and clear by the fact that "conc= at" deals in 3.6 with transport of more than 253 octets, but for clarity I = believe that this needs to be explicitly stated. 2. It is not clear why the Prefix-Length value greater than 128 for i= pv6prefix in 3.10 and greater than 32 for ipv4prefix in 3.11 need only SHOU= LD be treated as "invalid attributes". Why not MUST? If there are exception= cases it would be good to explain them. Nits/editorial comments: 1. Section 2.1.4: The paragraph that starts with 'The "Value" field s= hould be given ....' needs to use capitalized SHOULD to be consistent with = the paragraph that refer to the "Name" and "Format" fields. --_000_9904FB1B0159DA42B0B887B7FA8119CA75267BC5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft= . The General Area Review Team (Gen-ART) reviews all IETF documents being p= rocessed by the IESG for the IETF Chair.  Please treat these comments = just like any other last call comments.

 

For more information, please see the FAQ at<= /o:p>

 

https://trac.tools.iet= f.org/area/gen/trac/wiki/GenArtfaq

 

Document: draft-ietf-radext-datatypes-04.txt=

Reviewer: Dan Romascanu

Review Date: 8/9/16

IETF LC End Date: 8/17/16

IESG Telechat date: 8/18/16

 

Summary:

 

Ready with issues.

 

This is an important document that tries to bring= clarification to a number of different interpretations and recommendations= around the RADIUS specifications. Being familiar – up to a certain p= oint – with the history, I believe that it’s long due and that it will be very useful. There are however a n= umber of issues which I believe need to be clarified before the document is= approved by the IESG.

 

Major issues:

 

1.       Although the document make= s the claim that it does not impact previous specifications and implementat= ions, I am not sure this is completely the case. For example, the statement= in RFC 6158, section 2.1 about ‘all other data formats (than the ones defined there) being NOT RECOMMENDED is = obsolete by this document. I think that there is a need to make clear what = is not longer valid or recommended in specifications that this document upd= ates.

2.       This document creates a ne= w IANA registry and updates another one. There is no mention however about = the policy of adding new entries or making other modifications to the new r= egistry. A reminder of the RADIUS Attribute Type registry policy would also help.

 

Minor issues:

 

1.       In section 3.5 – the= re is no mention that the string length is limited to 253 octets. This is o= bvious if we assume the definition of  “string” sticking w= ith previous RADIUS documents, and clear by the fact that “concat” deals in 3.6 with transport of more than 253 octets, = but for clarity I believe that this needs to be explicitly stated.

2.       It is not clear why the Pr= efix-Length value greater than 128 for ipv6prefix in 3.10 and greater than = 32 for ipv4prefix in 3.11 need only SHOULD be treated as “invalid att= ributes”. Why not MUST? If there are exception cases it would be good to explain them.

 

Nits/editorial comments:

 

1.       Section 2.1.4: The paragra= ph that starts with ‘The “Value” field should be given &#= 8230;.’ needs to use capitalized SHOULD to be consistent with the par= agraph that refer to the “Name” and “Format” fields= .

 

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA75267BC5AZFFEXMB04globa_-- From nobody Tue Aug 9 09:38:21 2016 Return-Path: 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 7F48712D844; Tue, 9 Aug 2016 09:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 kq-PjjXvajMs; Tue, 9 Aug 2016 09:38:17 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id ADDEA12D850; Tue, 9 Aug 2016 09:38:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id DA850199F; Tue, 9 Aug 2016 16:38:14 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spsY5353PsCP; Tue, 9 Aug 2016 16:38:14 +0000 (UTC) Received: from [10.188.40.108] (ppp-seco11pa2-46-193-134-192.wb.wifirst.net [46.193.134.192]) by mail.networkradius.com (Postfix) with ESMTPSA id 0C547B91; Tue, 9 Aug 2016 16:38:13 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Alan DeKok In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com> Date: Tue, 9 Aug 2016 18:38:12 +0200 Message-Id: <0945BC67-129B-4B91-97FE-99D95367CB46@freeradius.org> References: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "radext@ietf.org" , General Area Review Team , "draft-ietf-radext-datatypes.all@tools.ietf.org" Subject: Re: [radext] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 16:38:19 -0000 --Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 9, 2016, at 5:28 PM, Romascanu, Dan (Dan) = wrote: > 1. Although the document makes the claim that it does not impact = previous specifications and implementations, I am not sure this is = completely the case. As noted in the document, implementations have already chosen data = types for all existing attributes. I haven't seen any conflicting data = types. i.e. all implementations seem to have made the same choices. The document updates previous specifications, most notably where the = specifications are inconsistent and/or wrong. So it does impact = previous specifications, but only to codify standard corrections. Which = (as noted above) all implementations have already fixed in practice. > For example, the statement in RFC 6158, section 2.1 about 'all other = data formats (than the ones defined there) being NOT RECOMMENDED is = obsolete by this document. I think that there is a need to make clear = what is not longer valid or recommended in specifications that this = document updates Maybe this works: This document updates [RFC6158] to permit the data types defined in the "Data Type Registry" as "basic data types", as per Section 2.1 of that document. The recommendations of [RFC6158] are otherwise unchanged. I think that should clarify the issue. > 2. This document creates a new IANA registry and updates another = one. There is no mention however about the policy of adding new entries = or making other modifications to the new registry. A reminder of the = RADIUS Attribute Type registry policy would also help. The -06 rev has the following text: 4.1. Create a Data Type Registry This section defines a new RADIUS registry, called "Data Type". Allocation in this registry requires IETF Review. The "Registration Procedures" for this registry are "Standards Action". Which I think satisfies your concern. > Minor issues: > > 1. In section 3.5 =E2=80=93 there is no mention that the string = length is limited to 253 octets. This is obvious if we assume the = definition of =E2=80=9Cstring=E2=80=9D sticking with previous RADIUS = documents, and clear by the fact that =E2=80=9Cconcat=E2=80=9D deals in = 3.6 with transport of more than 253 octets, but for clarity I believe = that this needs to be explicitly stated. Yes and no. RFC 6929 allows for extended attributes to carry more = than 253 octets of data. The same comment applies to attributes of type = "text". I'll add some text clarifying this. > 2. It is not clear why the Prefix-Length value greater than 128 = for ipv6prefix in 3.10 and greater than 32 for ipv4prefix in 3.11 need = only SHOULD be treated as =E2=80=9Cinvalid attributes=E2=80=9D. Why not = MUST? If there are exception cases it would be good to explain them. The text was mostly taken from previous standards. I'm OK with it = being a MUST. > Nits/editorial comments: > > 1. Section 2.1.4: The paragraph that starts with =E2=80=98The = =E2=80=9CValue=E2=80=9D field should be given =E2=80=A6.=E2=80=99 needs = to use capitalized SHOULD to be consistent with the paragraph that refer = to the =E2=80=9CName=E2=80=9D and =E2=80=9CFormat=E2=80=9D fields. Fixed, thanks. Alan DeKok. --Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXqgb0AAoJEH0Oec13Yh7NVh8H/iLkP3UQ0KNjb/o0BttIDO3n /s66eb1j/vjACECo36qRR7BuUrZPlYDrtwsKEhNAMozDIxB9wu8+Kt9TwEKC+4pG PuDpjPE2FVqjFkXHjO9WzFMtECG4TXCVmh7DL5qQh6MRLExNrVsolugBq4eWMA24 rQOTHCHznQzwxPQ1AdvzP2YKaLiI+g5is1mwYaSMo7YeBAe/iAfsLDOZ9gj3vfw4 FagglBBHnfoyZP8bYOxQ1D6e8I0l3KTBeT/uOvNqtbtKGx3U4DcoY7oILyuaWK3d 772l/YkOob/0Joa6/t+vdaw5VVzv3rw0MWKxTVSW+eiSMVbF65t77fHNHWE7Bvg= =dR7m -----END PGP SIGNATURE----- --Apple-Mail=_CDEE4BBC-A3FB-49EE-8003-C44F9403BA41-- From nobody Tue Aug 9 10:03:44 2016 Return-Path: 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 633FA12D606; Tue, 9 Aug 2016 10:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=unavailable 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 zlmRHYdbQM7Q; Tue, 9 Aug 2016 10:03:33 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAFB12D1A3; Tue, 9 Aug 2016 10:03:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EiAQByDKpX/yYyC4ddGgEBAQGCWSEtV?= =?us-ascii?q?nwHjSard4E9QCOFegKBSzgUAQEBAQEBAQNaJ4JTOQYHLwEBAQEBASMCDy8SAQE?= =?us-ascii?q?ZAQEBAQMSZxACAQgNBAMBAQELJDIdCAEBBA4FCBqIDwENpkCaagEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFhiuETIQcJh6DDIIvBY4YhV2FRAGGHIpYhFuDJoVXjDS?= =?us-ascii?q?DeB42gVeCI24BAQGFZEYBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EiAQByDKpX/yYyC4ddGgEBAQGCWSEtVnwHjSard4E9QCO?= =?us-ascii?q?FegKBSzgUAQEBAQEBAQNaJ4JTOQYHLwEBAQEBASMCDy8SAQEZAQEBAQMSZxACA?= =?us-ascii?q?QgNBAMBAQELJDIdCAEBBA4FCBqIDwENpkCaagEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BARcFhiuETIQcJh6DDIIvBY4YhV2FRAGGHIpYhFuDJoVXjDSDeB42gVeCI24BA?= =?us-ascii?q?QGFZEYBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,495,1464667200"; d="scan'208,217";a="200277118" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Aug 2016 13:03:15 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 09 Aug 2016 13:03:15 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0294.000; Tue, 9 Aug 2016 13:03:14 -0400 From: "Romascanu, Dan (Dan)" To: General Area Review Team Thread-Topic: Gen-ART LC review of draft-ietf-radext-datatypes-04.txt Thread-Index: AdHyUp+ehzJGYnAzRqKWyh5pUHwS4wADR5CR Date: Tue, 9 Aug 2016 17:03:12 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75267D0D@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.152.73.21] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA75267D0DAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "radext@ietf.org" , "draft-ietf-radext-datatypes.all@tools.ietf.org" Subject: Re: [radext] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 17:03:36 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75267D0DAZFFEXMB04globa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alan, Thanks for the quick response. The planned edits seem to address all the is= sues that I raised. There are good chances that I will just say 'I am happy= ' when I will see the revised I-D. Regards, Dan ________________________________ From: Gen-art [gen-art-bounces@ietf.org] on behalf of Romascanu, Dan (Dan) Sent: Tuesday, August 09, 2016 6:28 PM To: General Area Review Team Cc: radext@ietf.org; draft-ietf-radext-datatypes.all@tools.ietf.org Subject: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt I am the assigned Gen-ART reviewer for this draft. The General Area Review = Team (Gen-ART) reviews all IETF documents being processed by the IESG for t= he IETF Chair. Please treat these comments just like any other last call c= omments. For more information, please see the FAQ at https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Document: draft-ietf-radext-datatypes-04.txt Reviewer: Dan Romascanu Review Date: 8/9/16 IETF LC End Date: 8/17/16 IESG Telechat date: 8/18/16 Summary: Ready with issues. This is an important document that tries to bring clarification to a number= of different interpretations and recommendations around the RADIUS specifi= cations. Being familiar =96 up to a certain point =96 with the history, I b= elieve that it=92s long due and that it will be very useful. There are howe= ver a number of issues which I believe need to be clarified before the docu= ment is approved by the IESG. Major issues: 1. Although the document makes the claim that it does not impact prev= ious specifications and implementations, I am not sure this is completely t= he case. For example, the statement in RFC 6158, section 2.1 about =91all o= ther data formats (than the ones defined there) being NOT RECOMMENDED is ob= solete by this document. I think that there is a need to make clear what is= not longer valid or recommended in specifications that this document updat= es. 2. This document creates a new IANA registry and updates another one.= There is no mention however about the policy of adding new entries or maki= ng other modifications to the new registry. A reminder of the RADIUS Attrib= ute Type registry policy would also help. Minor issues: 1. In section 3.5 =96 there is no mention that the string length is l= imited to 253 octets. This is obvious if we assume the definition of =93st= ring=94 sticking with previous RADIUS documents, and clear by the fact that= =93concat=94 deals in 3.6 with transport of more than 253 octets, but for = clarity I believe that this needs to be explicitly stated. 2. It is not clear why the Prefix-Length value greater than 128 for i= pv6prefix in 3.10 and greater than 32 for ipv4prefix in 3.11 need only SHOU= LD be treated as =93invalid attributes=94. Why not MUST? If there are excep= tion cases it would be good to explain them. Nits/editorial comments: 1. Section 2.1.4: The paragraph that starts with =91The =93Value=94 f= ield should be given =85.=92 needs to use capitalized SHOULD to be consiste= nt with the paragraph that refer to the =93Name=94 and =93Format=94 fields. --_000_9904FB1B0159DA42B0B887B7FA8119CA75267D0DAZFFEXMB04globa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Alan,

Thanks for the quick response. The planned edits seem to address all the is= sues that I raised. There are good chances that I will just say 'I am happy= ' when I will see the revised I-D.

Regards,

Dan

From: Gen-art [gen-art-bounces@ietf.org] = on behalf of Romascanu, Dan (Dan)
Sent: Tuesday, August 09, 2016 6:28 PM
To: General Area Review Team
Cc: radext@ietf.org; draft-ietf-radext-datatypes.all@tools.ietf.org<= br> Subject: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-= 04.txt

I am the assigned Gen-ART reviewer for this draft= . The General Area Review Team (Gen-ART) reviews all IETF documents being p= rocessed by the IESG for the IETF Chair.  Please treat these comments = just like any other last call comments.

 

For more information, please see the FAQ at

 

http= s://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

 

Document: draft-ietf-radext-datatypes-04.txt

Reviewer: Dan Romascanu

Review Date: 8/9/16

IETF LC End Date: 8/17/16

IESG Telechat date: 8/18/16

 

Summary:

 

Ready with issues.

 

This is an important document that tries to bring= clarification to a number of different interpretations and recommendations= around the RADIUS specifications. Being familiar =96 up to a certain point= =96 with the history, I believe that it=92s long due and that it will be very useful. There are however a numbe= r of issues which I believe need to be clarified before the document is app= roved by the IESG.

 

Major issues:

 

1.=        Although the document makes the clai= m that it does not impact previous specifications and implementations, I am= not sure this is completely the case. For example, the statement in RFC 61= 58, section 2.1 about =91all other data formats (than the ones defined there) being NOT RECOMMENDED is obsolete by= this document. I think that there is a need to make clear what is not long= er valid or recommended in specifications that this document updates.

2.=        This document creates a new IANA reg= istry and updates another one. There is no mention however about the policy= of adding new entries or making other modifications to the new registry. A= reminder of the RADIUS Attribute Type registry policy would also help.

 

Minor issues:

 

1.=        In section 3.5 =96 there is no menti= on that the string length is limited to 253 octets. This is obvious if we a= ssume the definition of  =93string=94 sticking with previous RADIUS do= cuments, and clear by the fact that =93concat=94 deals in 3.6 with transport of more than 253 octets, but for clarity I bel= ieve that this needs to be explicitly stated.

2.=        It is not clear why the Prefix-Lengt= h value greater than 128 for ipv6prefix in 3.10 and greater than 32 for ipv= 4prefix in 3.11 need only SHOULD be treated as =93invalid attributes=94. Wh= y not MUST? If there are exception cases it would be good to explain them.

 

Nits/editorial comments:

 

1.=        Section 2.1.4: The paragraph that st= arts with =91The =93Value=94 field should be given =85.=92 needs to use cap= italized SHOULD to be consistent with the paragraph that refer to the =93Na= me=94 and =93Format=94 fields.

 

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA75267D0DAZFFEXMB04globa_-- From nobody Wed Aug 10 15:00:53 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2FB88126579; Wed, 10 Aug 2016 15:00:47 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A5412D145; Wed, 10 Aug 2016 15:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.427 X-Spam-Level: X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham 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 qfECX9zw9Cxb; Wed, 10 Aug 2016 15:00:45 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A43E126579; Wed, 10 Aug 2016 15:00:45 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (8.13.8/8.13.8) with ESMTP id u7AM0iVV016421; Wed, 10 Aug 2016 22:00:44 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 293D1C20536; Wed, 10 Aug 2016 22:00:44 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" In-Reply-To: <20160728185219.12937.1632.idtracker@ietfa.amsl.com> References: <20160728185219.12937.1632.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #920427 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 10 Aug 2016 22:00:44 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160810220047.2FB88126579@ietfa.amsl.com> Resent-Date: Wed, 10 Aug 2016 15:00:47 -0700 (PDT) Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org, iesg@ietf.org Subject: [radext] [IANA #920427] Last Call: (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: drafts-lastcall-comment@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 22:00:47 -0000 (BEGIN IANA COMMENTS) IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-radext-ip-port-radius-ext-10.txt. If any part of this review is inaccurate, please let us know. IANA has a question about one of the actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there are three actions which IANA must complete. First, in the IPFIX Information Elements subregistry of the IP Flow Information Export (IPFIX) Entities registry located at: https://www.iana.org/assignments/ipfix/ three new information elements are to be registered as follows: ElementID: [ TBD-at-registration ] Name: transportType Data Type: unsigned8 Data Type Semantics: Status: current Description: The value indicates TCP/UDP ports and ICMP Identifiers (1), TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5). Units: Range: References: [ RFC-to-be ] ElementID: [ TBD-at-registration ] Name: natTransportLimit Data Type: unsigned16 Data Type Semantics: Status: current Description: The value is the max number of IP transport ports to be assigned to an end user associated with one or more IPv4 addresses. Units: Range: References: [ RFC-to-be ] ElementID: [ TBD-at-registration ] Name: localID Data Type: string Data Type Semantics: Status: current Description: The value is an IPv4 or IPv6 address, a MAC address, a VLAN ID, etc. Units: Range: References: [ RFC-to-be ] IANA Question --> for each of these three registrations, could the authors please supply the data type semantics and the units to be registered with these values? As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the Radius Attribute Types subregistry of the Radius Types registry located at: http://www.iana.org/assignments/ three new Radius attribute types are to be registered under the 241 Extended-Attribute-1 type as follows: Value: 241.[ TBD-at-registration ] Description: IP-Port-Limit-Info Reference: [ RFC-to-be ] Value: 241.[ TBD-at-registration ] Description: IP-Port-Range Reference: [ RFC-to-be ] Value: 241.[ TBD-at-registration ] Description: IP-Port-Forwarding-Map Reference: [ RFC-to-be ] Third, IANA notes that the authors request: This specification requests allocation of the following TLVs: Name Value Meaning ---- ----- ------- IP-Port-Type 1 see Section 3.2.1 IP-Port-Limit 2 see Section 3.2.2 IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 IP-Port-Int-IPv4-Addr 4 see Section 3.2.4 IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 IP-Port-Int-Port 6 see Section 3.2.6 IP-Port-Ext-Port 7 see Section 3.2.7 IP-Port-Alloc 8 see Section 3.2.8 IP-Port-Range-Start 9 see Section 3.2.9 IP-Port-Range-End 10 see Section 3.2.10 IP-Port-Local-Id 11 see Section 3.2.11 IANA Question --> Specifically, in what registry are these new TLVs to be registered? IANA understands that the three actions above are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Specialist ICANN (END IANA COMMENTS) From nobody Wed Aug 10 15:05:14 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFC312D898; Wed, 10 Aug 2016 15:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147086670969.12699.1427486850762749814.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2016 15:05:09 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 22:05:10 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Wed Aug 10 18:35:23 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD02127735; Wed, 10 Aug 2016 18:35:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147087932207.13426.4445088302556614329.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2016 18:35:22 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 01:35:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-11.txt Pages : 37 Date : 2016-08-10 Abstract: This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 10 18:35:30 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ECE12D11F; Wed, 10 Aug 2016 18:35:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147087932245.13426.15405740528418485895.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2016 18:35:22 -0700 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 01:35:22 -0000 A new version (-11) has been submitted for draft-ietf-radext-ip-port-radius-ext: https://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Aug 10 18:43:40 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E19F512D534; Wed, 10 Aug 2016 18:43:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F6712D177; Wed, 10 Aug 2016 18:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham 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 yUE90-Nle16O; Wed, 10 Aug 2016 18:43:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8C412B078; Wed, 10 Aug 2016 18:43:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPF63129; Thu, 11 Aug 2016 01:43:27 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 11 Aug 2016 02:43:26 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.36]) by SJCEML702-CHM.china.huawei.com ([10.218.25.35]) with mapi id 14.03.0235.001; Wed, 10 Aug 2016 18:43:20 -0700 From: Dean cheng To: "drafts-lastcall-comment@iana.org" Thread-Topic: [IANA #920427] Last Call: (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard Thread-Index: AQHR81KsYr6ULxlls0yOoZp4Iw74Q6BC+yyQ Date: Thu, 11 Aug 2016 01:43:19 +0000 Message-ID: References: <20160728185219.12937.1632.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57ABD83F.006A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.36, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 16621bab62d9bf09c3d6fc4c09dec891 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160811014332.E19F512D534@ietfa.amsl.com> Resent-Date: Wed, 10 Aug 2016 18:43:32 -0700 (PDT) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" , "iesg@ietf.org" Subject: Re: [radext] [IANA #920427] Last Call: (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 01:43:33 -0000 SGkgU2FicmluYSwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cy4NCldl J3ZlIGp1c3QgdXBsb2FkZWQgYSBuZXcgcmV2aXNpb24gKDExLnR4dCkNCnRoYXQgaW50ZW5kcyB0 byByZXNvbHZlIElBTkEgcXVlc3Rpb25zIGFzDQpmb2xsb3dzOg0KDQo+IElBTkEgUXVlc3Rpb24g LS0+IGZvciBlYWNoIG9mIHRoZXNlIHRocmVlIHJlZ2lzdHJhdGlvbnMsIGNvdWxkIHRoZQ0KPiBh dXRob3JzIHBsZWFzZSBzdXBwbHkgdGhlIGRhdGEgdHlwZSBzZW1hbnRpY3MgYW5kIHRoZSB1bml0 cyB0byBiZQ0KPiByZWdpc3RlcmVkIHdpdGggdGhlc2UgdmFsdWVzPw0KDQpSZWdhcmRzDQpEZWFu DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2FicmluYSBUYW5hbWFs IHZpYSBSVCBbbWFpbHRvOmRyYWZ0cy1sYXN0Y2FsbC1jb21tZW50QGlhbmEub3JnXQ0KPiBTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAxMCwgMjAxNiAzOjAxIFBNDQo+IENjOiBpZXNnQGlldGYub3Jn OyBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQuYWxsQGlldGYub3JnDQo+IFN1 YmplY3Q6IFtJQU5BICM5MjA0MjddIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBv cnQtcmFkaXVzLQ0KPiBleHQtMTAudHh0PiAoUkFESVVTIEV4dGVuc2lvbnMgZm9yIElQIFBvcnQg Q29uZmlndXJhdGlvbiBhbmQgUmVwb3J0aW5nKQ0KPiB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiAN Cj4gKEJFR0lOIElBTkEgQ09NTUVOVFMpDQo+IA0KPiBJRVNHL0F1dGhvcnMvV0cgQ2hhaXJzOg0K PiANCj4gSUFOQSBoYXMgY29tcGxldGVkIGl0cyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1yYWRleHQt aXAtcG9ydC1yYWRpdXMtZXh0LQ0KPiAxMC50eHQuIElmIGFueSBwYXJ0IG9mIHRoaXMgcmV2aWV3 IGlzIGluYWNjdXJhdGUsIHBsZWFzZSBsZXQgdXMga25vdy4NCj4gDQo+IElBTkEgaGFzIGEgcXVl c3Rpb24gYWJvdXQgb25lIG9mIHRoZSBhY3Rpb25zIHJlcXVlc3RlZCBpbiB0aGUgSUFOQQ0KPiBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBJQU5BIHVuZGVy c3RhbmRzIHRoYXQsIHVwb24gYXBwcm92YWwgb2YgdGhpcyBkb2N1bWVudCwgdGhlcmUgYXJlIHRo cmVlDQo+IGFjdGlvbnMgd2hpY2ggSUFOQSBtdXN0IGNvbXBsZXRlLg0KPiANCj4gRmlyc3QsIGlu IHRoZSBJUEZJWCBJbmZvcm1hdGlvbiBFbGVtZW50cyBzdWJyZWdpc3RyeSBvZiB0aGUgSVAgRmxv dw0KPiBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKSBFbnRpdGllcyByZWdpc3RyeSBsb2NhdGVk IGF0Og0KPiANCj4gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaXBmaXgvDQo+IA0K PiB0aHJlZSBuZXcgaW5mb3JtYXRpb24gZWxlbWVudHMgYXJlIHRvIGJlIHJlZ2lzdGVyZWQgYXMg Zm9sbG93czoNCj4gDQo+IEVsZW1lbnRJRDogWyBUQkQtYXQtcmVnaXN0cmF0aW9uIF0NCj4gTmFt ZTogdHJhbnNwb3J0VHlwZQ0KPiBEYXRhIFR5cGU6IHVuc2lnbmVkOA0KPiBEYXRhIFR5cGUgU2Vt YW50aWNzOg0KPiBTdGF0dXM6IGN1cnJlbnQNCj4gRGVzY3JpcHRpb246IFRoZSB2YWx1ZSBpbmRp Y2F0ZXMgVENQL1VEUCBwb3J0cyBhbmQgSUNNUCBJZGVudGlmaWVycyAoMSksDQo+IFRDUC9VRFAg cG9ydHMgKDIpLCBUQ1AgcG9ydHMgKDMpLCBVRFAgcG9ydHMgKDQpIG9yIElDTVAgaWRlbnRpZmll cnMgKDUpLg0KPiBVbml0czoNCj4gUmFuZ2U6DQo+IFJlZmVyZW5jZXM6IFsgUkZDLXRvLWJlIF0N Cj4gDQo+IEVsZW1lbnRJRDogWyBUQkQtYXQtcmVnaXN0cmF0aW9uIF0NCj4gTmFtZTogbmF0VHJh bnNwb3J0TGltaXQNCj4gRGF0YSBUeXBlOiB1bnNpZ25lZDE2DQo+IERhdGEgVHlwZSBTZW1hbnRp Y3M6DQo+IFN0YXR1czogY3VycmVudA0KPiBEZXNjcmlwdGlvbjogVGhlIHZhbHVlIGlzIHRoZSBt YXggbnVtYmVyIG9mIElQIHRyYW5zcG9ydCBwb3J0cyB0byBiZQ0KPiBhc3NpZ25lZCB0byBhbiBl bmQgdXNlciBhc3NvY2lhdGVkIHdpdGggb25lIG9yIG1vcmUgSVB2NCBhZGRyZXNzZXMuDQo+IFVu aXRzOg0KPiBSYW5nZToNCj4gUmVmZXJlbmNlczogWyBSRkMtdG8tYmUgXQ0KPiANCj4gRWxlbWVu dElEOiBbIFRCRC1hdC1yZWdpc3RyYXRpb24gXQ0KPiBOYW1lOiBsb2NhbElEDQo+IERhdGEgVHlw ZTogc3RyaW5nDQo+IERhdGEgVHlwZSBTZW1hbnRpY3M6DQo+IFN0YXR1czogY3VycmVudA0KPiBE ZXNjcmlwdGlvbjogVGhlIHZhbHVlIGlzIGFuIElQdjQgb3IgSVB2NiBhZGRyZXNzLCBhIE1BQyBh ZGRyZXNzLCBhDQo+IFZMQU4gSUQsIGV0Yy4NCj4gVW5pdHM6DQo+IFJhbmdlOg0KPiBSZWZlcmVu Y2VzOiBbIFJGQy10by1iZSBdDQo+IA0KPiBJQU5BIFF1ZXN0aW9uIC0tPiBmb3IgZWFjaCBvZiB0 aGVzZSB0aHJlZSByZWdpc3RyYXRpb25zLCBjb3VsZCB0aGUNCj4gYXV0aG9ycyBwbGVhc2Ugc3Vw cGx5IHRoZSBkYXRhIHR5cGUgc2VtYW50aWNzIGFuZCB0aGUgdW5pdHMgdG8gYmUNCj4gcmVnaXN0 ZXJlZCB3aXRoIHRoZXNlIHZhbHVlcz8NCj4gDQo+IEFzIHRoaXMgZG9jdW1lbnQgcmVxdWVzdHMg cmVnaXN0cmF0aW9ucyBpbiBhbiBFeHBlcnQgUmV2aWV3IG9yDQo+IFNwZWNpZmljYXRpb24gUmVx dWlyZWQgKHNlZSBSRkMgNTIyNikgcmVnaXN0cnksIHdlIHdpbGwgaW5pdGlhdGUgdGhlDQo+IHJl cXVpcmVkIEV4cGVydCBSZXZpZXcgdmlhIGEgc2VwYXJhdGUgcmVxdWVzdC4gRXhwZXJ0IHJldmll dyB3aWxsIG5lZWQNCj4gdG8gYmUgY29tcGxldGVkIGJlZm9yZSB5b3VyIGRvY3VtZW50IGNhbiBi ZSBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24gYXMNCj4gYW4gUkZDLg0KPiANCj4gU2Vjb25kLCBp biB0aGUgUmFkaXVzIEF0dHJpYnV0ZSBUeXBlcyBzdWJyZWdpc3RyeSBvZiB0aGUgUmFkaXVzIFR5 cGVzDQo+IHJlZ2lzdHJ5IGxvY2F0ZWQgYXQ6DQo+IA0KPiBodHRwOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzLw0KPiANCj4gdGhyZWUgbmV3IFJhZGl1cyBhdHRyaWJ1dGUgdHlwZXMgYXJlIHRv IGJlIHJlZ2lzdGVyZWQgdW5kZXIgdGhlIDI0MQ0KPiBFeHRlbmRlZC1BdHRyaWJ1dGUtMSB0eXBl IGFzIGZvbGxvd3M6DQo+IA0KPiBWYWx1ZTogMjQxLlsgVEJELWF0LXJlZ2lzdHJhdGlvbiBdDQo+ IERlc2NyaXB0aW9uOiBJUC1Qb3J0LUxpbWl0LUluZm8NCj4gUmVmZXJlbmNlOiBbIFJGQy10by1i ZSBdDQo+IA0KPiBWYWx1ZTogMjQxLlsgVEJELWF0LXJlZ2lzdHJhdGlvbiBdDQo+IERlc2NyaXB0 aW9uOiBJUC1Qb3J0LVJhbmdlDQo+IFJlZmVyZW5jZTogWyBSRkMtdG8tYmUgXQ0KPiANCj4gVmFs dWU6IDI0MS5bIFRCRC1hdC1yZWdpc3RyYXRpb24gXQ0KPiBEZXNjcmlwdGlvbjogSVAtUG9ydC1G b3J3YXJkaW5nLU1hcA0KPiBSZWZlcmVuY2U6IFsgUkZDLXRvLWJlIF0NCj4gDQo+IFRoaXJkLCBJ QU5BIG5vdGVzIHRoYXQgdGhlIGF1dGhvcnMgcmVxdWVzdDoNCj4gDQo+IFRoaXMgc3BlY2lmaWNh dGlvbiByZXF1ZXN0cyBhbGxvY2F0aW9uIG9mIHRoZSBmb2xsb3dpbmcgVExWczoNCj4gTmFtZSBW YWx1ZSBNZWFuaW5nDQo+IC0tLS0gLS0tLS0gLS0tLS0tLQ0KPiBJUC1Qb3J0LVR5cGUgMSBzZWUg U2VjdGlvbiAzLjIuMQ0KPiBJUC1Qb3J0LUxpbWl0IDIgc2VlIFNlY3Rpb24gMy4yLjINCj4gSVAt UG9ydC1FeHQtSVB2NC1BZGRyIDMgc2VlIFNlY3Rpb24gMy4yLjMgSVAtUG9ydC1JbnQtSVB2NC1B ZGRyIDQgc2VlDQo+IFNlY3Rpb24gMy4yLjQgSVAtUG9ydC1JbnQtSVB2Ni1BZGRyIDUgc2VlIFNl Y3Rpb24gMy4yLjUgSVAtUG9ydC1JbnQtDQo+IFBvcnQgNiBzZWUgU2VjdGlvbiAzLjIuNiBJUC1Q b3J0LUV4dC1Qb3J0IDcgc2VlIFNlY3Rpb24gMy4yLjcgSVAtUG9ydC0NCj4gQWxsb2MgOCBzZWUg U2VjdGlvbiAzLjIuOCBJUC1Qb3J0LVJhbmdlLVN0YXJ0IDkgc2VlIFNlY3Rpb24gMy4yLjkgSVAt DQo+IFBvcnQtUmFuZ2UtRW5kIDEwIHNlZSBTZWN0aW9uIDMuMi4xMCBJUC1Qb3J0LUxvY2FsLUlk IDExIHNlZSBTZWN0aW9uDQo+IDMuMi4xMQ0KPiANCj4gSUFOQSBRdWVzdGlvbiAtLT4gU3BlY2lm aWNhbGx5LCBpbiB3aGF0IHJlZ2lzdHJ5IGFyZSB0aGVzZSBuZXcgVExWcyB0bw0KPiBiZSByZWdp c3RlcmVkPw0KPiANCj4gSUFOQSB1bmRlcnN0YW5kcyB0aGF0IHRoZSB0aHJlZSBhY3Rpb25zIGFi b3ZlIGFyZSB0aGUgb25seSBvbmVzDQo+IHJlcXVpcmVkIHRvIGJlIGNvbXBsZXRlZCB1cG9uIGFw cHJvdmFsIG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBOb3RlOiAgVGhlIGFjdGlvbnMgcmVxdWVz dGVkIGluIHRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYmUgY29tcGxldGVkDQo+IHVudGlsIHRoZSBk b2N1bWVudCBoYXMgYmVlbiBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24gYXMgYW4gUkZDLiBUaGlz DQo+IG1lc3NhZ2UgaXMgb25seSB0byBjb25maXJtIHdoYXQgYWN0aW9ucyB3aWxsIGJlIHBlcmZv cm1lZC4NCj4gDQo+IA0KPiBUaGFuayB5b3UsDQo+IA0KPiBTYWJyaW5hIFRhbmFtYWwNCj4gSUFO QSBTcGVjaWFsaXN0DQo+IElDQU5ODQo+IA0KPiAoRU5EIElBTkEgQ09NTUVOVFMpDQoNCg== From nobody Thu Aug 11 00:06:58 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0659812D0B6; Thu, 11 Aug 2016 00:06:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147089921601.31065.5751946917584412488.idtracker@ietfa.amsl.com> Date: Thu, 11 Aug 2016 00:06:56 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [radext] Last Call Expired: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 07:06:56 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Thu Aug 11 01:32:23 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 688AC12B059; Thu, 11 Aug 2016 01:32:18 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26512D0BE; Thu, 11 Aug 2016 01:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 rKiKtNDbfCBH; Thu, 11 Aug 2016 01:32:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D9712B059; Thu, 11 Aug 2016 01:32:12 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 19A5C3B435D; Thu, 11 Aug 2016 10:32:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D49F027C053; Thu, 11 Aug 2016 10:32:09 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 10:32:09 +0200 From: To: Dean cheng , "drafts-lastcall-comment@iana.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_RE:_[IANA_#920427]_Last_Call:__(RADIUS_Extensions_for_IP_Port_Co?= =?iso-8859-1?Q?nfiguration_and_Reporting)_to_Proposed_Standard?= Thread-Index: AQHR86rZ5VsTs7ywIEi1HBZayXJEaQ== Date: Thu, 11 Aug 2016 08:32:09 +0000 Message-ID: <27431_1470904330_57AC3809_27431_1603_1_6B7134B31289DC4FAF731D844122B36E01F5D742@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160728185219.12937.1632.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01F5D742OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160811083218.688AC12B059@ietfa.amsl.com> Resent-Date: Thu, 11 Aug 2016 01:32:18 -0700 (PDT) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" , "iesg@ietf.org" Subject: [radext] =?iso-8859-1?q?RE=A0=3A_RE=3A_=5BIANA_=23920427=5D_Last_?= =?iso-8859-1?q?Call=3A_=3Cdraft-ietf-radext-ip-port-radius-ext-10=2Etxt?= =?iso-8859-1?q?=3E_=28RADIUS_Extensions_for_IP_Port_Configuration_and_Rep?= =?iso-8859-1?q?orting=29_to_Proposed_Standard?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 08:32:18 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01F5D742OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dean, Thank you for the update. However, it is recommended to answer first to the= questions (form IANA or others) before updating the draft. It would avoid = too many iterations. And it will allow to check if the proposed answers are= correct/acceptable. Regards, Lionel Le 11 ao=FBt 2016 03:43, Dean cheng a =E9crit : Hi Sabrina, Thank you for the review and comments. We've just uploaded a new revision (11.txt) that intends to resolve IANA questions as follows: > IANA Question --> for each of these three registrations, could the > authors please supply the data type semantics and the units to be > registered with these values? Regards Dean > -----Original Message----- > From: Sabrina Tanamal via RT [mailto:drafts-lastcall-comment@iana.org] > Sent: Wednesday, August 10, 2016 3:01 PM > Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org > Subject: [IANA #920427] Last Call: ext-10.txt> (RADIUS Extensions for IP Port Configuration and Reporting) > to Proposed Standard > > (BEGIN IANA COMMENTS) > > IESG/Authors/WG Chairs: > > IANA has completed its review of draft-ietf-radext-ip-port-radius-ext- > 10.txt. If any part of this review is inaccurate, please let us know. > > IANA has a question about one of the actions requested in the IANA > Considerations section of this document. > > IANA understands that, upon approval of this document, there are three > actions which IANA must complete. > > First, in the IPFIX Information Elements subregistry of the IP Flow > Information Export (IPFIX) Entities registry located at: > > https://www.iana.org/assignments/ipfix/ > > three new information elements are to be registered as follows: > > ElementID: [ TBD-at-registration ] > Name: transportType > Data Type: unsigned8 > Data Type Semantics: > Status: current > Description: The value indicates TCP/UDP ports and ICMP Identifiers (1), > TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5). > Units: > Range: > References: [ RFC-to-be ] > > ElementID: [ TBD-at-registration ] > Name: natTransportLimit > Data Type: unsigned16 > Data Type Semantics: > Status: current > Description: The value is the max number of IP transport ports to be > assigned to an end user associated with one or more IPv4 addresses. > Units: > Range: > References: [ RFC-to-be ] > > ElementID: [ TBD-at-registration ] > Name: localID > Data Type: string > Data Type Semantics: > Status: current > Description: The value is an IPv4 or IPv6 address, a MAC address, a > VLAN ID, etc. > Units: > Range: > References: [ RFC-to-be ] > > IANA Question --> for each of these three registrations, could the > authors please supply the data type semantics and the units to be > registered with these values? > > As this document requests registrations in an Expert Review or > Specification Required (see RFC 5226) registry, we will initiate the > required Expert Review via a separate request. Expert review will need > to be completed before your document can be approved for publication as > an RFC. > > Second, in the Radius Attribute Types subregistry of the Radius Types > registry located at: > > http://www.iana.org/assignments/ > > three new Radius attribute types are to be registered under the 241 > Extended-Attribute-1 type as follows: > > Value: 241.[ TBD-at-registration ] > Description: IP-Port-Limit-Info > Reference: [ RFC-to-be ] > > Value: 241.[ TBD-at-registration ] > Description: IP-Port-Range > Reference: [ RFC-to-be ] > > Value: 241.[ TBD-at-registration ] > Description: IP-Port-Forwarding-Map > Reference: [ RFC-to-be ] > > Third, IANA notes that the authors request: > > This specification requests allocation of the following TLVs: > Name Value Meaning > ---- ----- ------- > IP-Port-Type 1 see Section 3.2.1 > IP-Port-Limit 2 see Section 3.2.2 > IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 IP-Port-Int-IPv4-Addr 4 see > Section 3.2.4 IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 IP-Port-Int- > Port 6 see Section 3.2.6 IP-Port-Ext-Port 7 see Section 3.2.7 IP-Port- > Alloc 8 see Section 3.2.8 IP-Port-Range-Start 9 see Section 3.2.9 IP- > Port-Range-End 10 see Section 3.2.10 IP-Port-Local-Id 11 see Section > 3.2.11 > > IANA Question --> Specifically, in what registry are these new TLVs to > be registered? > > IANA understands that the three actions above are the only ones > required to be completed upon approval of this document. > > Note: The actions requested in this document will not be completed > until the document has been approved for publication as an RFC. This > message is only to confirm what actions will be performed. > > > Thank you, > > Sabrina Tanamal > IANA Specialist > ICANN > > (END IANA COMMENTS) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E01F5D742OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dean,

Thank you for the update. However, it is recommended to answer first to the= questions (form IANA or others) before updating the draft. It would avoid = too many iterations. And it will allow to check if the proposed answers are= correct/acceptable.

Regards,

Lionel

Le 11 ao=FBt 2016 03:43, Dean cheng <dean.cheng@h= uawei.com> a =E9crit :
Hi Sabrina,

Thank you for the review and comments.
We've just uploaded a new revision (11.txt)
that intends to resolve IANA questions as
follows:

> IANA Question --> for each of these three registrations, could the<= br> > authors please supply the data type semantics and the units to be
> registered with these values?

Regards
Dean

> -----Original Message-----
> From: Sabrina Tanamal via RT [mailto:drafts-lastcall-comment@iana.org]
> Sent: Wednesday, August 10, 2016 3:01 PM
> Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org > Subject: [IANA #920427] Last Call: <draft-ietf-radext-ip-port-radiu= s-
> ext-10.txt> (RADIUS Extensions for IP Port Configuration and Report= ing)
> to Proposed Standard
>
> (BEGIN IANA COMMENTS)
>
> IESG/Authors/WG Chairs:
>
> IANA has completed its review of draft-ietf-radext-ip-port-radius-ext-=
> 10.txt. If any part of this review is inaccurate, please let us know.<= br> >
> IANA has a question about one of the actions requested in the IANA
> Considerations section of this document.
>
> IANA understands that, upon approval of this document, there are three=
> actions which IANA must complete.
>
> First, in the IPFIX Information Elements subregistry of the IP Flow
> Information Export (IPFIX) Entities registry located at:
>
> https://www.iana.o= rg/assignments/ipfix/
>
> three new information elements are to be registered as follows:
>
> ElementID: [ TBD-at-registration ]
> Name: transportType
> Data Type: unsigned8
> Data Type Semantics:
> Status: current
> Description: The value indicates TCP/UDP ports and ICMP Identifiers (1= ),
> TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5= ).
> Units:
> Range:
> References: [ RFC-to-be ]
>
> ElementID: [ TBD-at-registration ]
> Name: natTransportLimit
> Data Type: unsigned16
> Data Type Semantics:
> Status: current
> Description: The value is the max number of IP transport ports to be > assigned to an end user associated with one or more IPv4 addresses.
> Units:
> Range:
> References: [ RFC-to-be ]
>
> ElementID: [ TBD-at-registration ]
> Name: localID
> Data Type: string
> Data Type Semantics:
> Status: current
> Description: The value is an IPv4 or IPv6 address, a MAC address, a
> VLAN ID, etc.
> Units:
> Range:
> References: [ RFC-to-be ]
>
> IANA Question --> for each of these three registrations, could the<= br> > authors please supply the data type semantics and the units to be
> registered with these values?
>
> As this document requests registrations in an Expert Review or
> Specification Required (see RFC 5226) registry, we will initiate the > required Expert Review via a separate request. Expert review will need=
> to be completed before your document can be approved for publication a= s
> an RFC.
>
> Second, in the Radius Attribute Types subregistry of the Radius Types<= br> > registry located at:
>
> http://www.iana.org/assig= nments/
>
> three new Radius attribute types are to be registered under the 241
> Extended-Attribute-1 type as follows:
>
> Value: 241.[ TBD-at-registration ]
> Description: IP-Port-Limit-Info
> Reference: [ RFC-to-be ]
>
> Value: 241.[ TBD-at-registration ]
> Description: IP-Port-Range
> Reference: [ RFC-to-be ]
>
> Value: 241.[ TBD-at-registration ]
> Description: IP-Port-Forwarding-Map
> Reference: [ RFC-to-be ]
>
> Third, IANA notes that the authors request:
>
> This specification requests allocation of the following TLVs:
> Name Value Meaning
> ---- ----- -------
> IP-Port-Type 1 see Section 3.2.1
> IP-Port-Limit 2 see Section 3.2.2
> IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 IP-Port-Int-IPv4-Addr 4 see<= br> > Section 3.2.4 IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 IP-Port-Int- > Port 6 see Section 3.2.6 IP-Port-Ext-Port 7 see Section 3.2.7 IP-Port-=
> Alloc 8 see Section 3.2.8 IP-Port-Range-Start 9 see Section 3.2.9 IP-<= br> > Port-Range-End 10 see Section 3.2.10 IP-Port-Local-Id 11 see Section > 3.2.11
>
> IANA Question --> Specifically, in what registry are these new TLVs= to
> be registered?
>
> IANA understands that the three actions above are the only ones
> required to be completed upon approval of this document.
>
> Note:  The actions requested in this document will not be complet= ed
> until the document has been approved for publication as an RFC. This > message is only to confirm what actions will be performed.
>
>
> Thank you,
>
> Sabrina Tanamal
> IANA Specialist
> ICANN
>
> (END IANA COMMENTS)

 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E01F5D742OPEXCLILM43corp_-- From nobody Thu Aug 11 07:23:31 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B1A2F12D7B8; Thu, 11 Aug 2016 07:23:09 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8547412D7B6; Thu, 11 Aug 2016 07:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham 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 eexOyIA9j2sx; Thu, 11 Aug 2016 07:23:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E47012D728; Thu, 11 Aug 2016 07:21:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUD86577; Thu, 11 Aug 2016 14:21:13 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 11 Aug 2016 15:21:12 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.36]) by SJCEML703-CHM.china.huawei.com ([169.254.5.218]) with mapi id 14.03.0235.001; Thu, 11 Aug 2016 07:21:06 -0700 From: Dean cheng To: "lionel.morand@orange.com" , "drafts-lastcall-comment@iana.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_RE:_[IANA_#920427]_Last_Call:__(RADIUS_Extensions_for_IP_Port_Co?= =?iso-8859-1?Q?nfiguration_and_Reporting)_to_Proposed_Standard?= Thread-Index: AQHR81KsYr6ULxlls0yOoZp4Iw74Q6BC+yyQgADpOoD//+rVAA== Date: Thu, 11 Aug 2016 14:21:05 +0000 Message-ID: References: <20160728185219.12937.1632.idtracker@ietfa.amsl.com> , <27431_1470904330_57AC3809_27431_1603_1_6B7134B31289DC4FAF731D844122B36E01F5D742@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <27431_1470904330_57AC3809_27431_1603_1_6B7134B31289DC4FAF731D844122B36E01F5D742@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.59] Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F686E942927SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57AC89DA.01C6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.36, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1bcb86c5dde91b9b4302b5c451ea5cb6 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160811142309.B1A2F12D7B8@ietfa.amsl.com> Resent-Date: Thu, 11 Aug 2016 07:23:09 -0700 (PDT) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" , "iesg@ietf.org" Subject: Re: [radext] =?iso-8859-1?q?RE=A0=3A_RE=3A_=5BIANA_=23920427=5D_Last_?= =?iso-8859-1?q?Call=3A_=3Cdraft-ietf-radext-ip-port-radius-ext-10=2Etxt?= =?iso-8859-1?q?=3E_=28RADIUS_Extensions_for_IP_Port_Configuration_and_Rep?= =?iso-8859-1?q?orting=29_to_Proposed_Standard?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 14:23:10 -0000 --_000_DC7880973D477648AC15A3BA66253F686E942927SJCEML701CHMchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lionel, Sorry but I wasn't aware of that. Regards Dean From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Thursday, August 11, 2016 1:32 AM To: Dean cheng; drafts-lastcall-comment@iana.org Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org Subject: RE : RE: [IANA #920427] Last Call: (RADIUS Extensions for IP Port Configuration and Reporting) = to Proposed Standard Hi Dean, Thank you for the update. However, it is recommended to answer first to the= questions (form IANA or others) before updating the draft. It would avoid = too many iterations. And it will allow to check if the proposed answers are= correct/acceptable. Regards, Lionel Le 11 ao=FBt 2016 03:43, Dean cheng > a =E9crit : Hi Sabrina, Thank you for the review and comments. We've just uploaded a new revision (11.txt) that intends to resolve IANA questions as follows: > IANA Question --> for each of these three registrations, could the > authors please supply the data type semantics and the units to be > registered with these values? Regards Dean > -----Original Message----- > From: Sabrina Tanamal via RT [mailto:drafts-lastcall-comment@iana.org] > Sent: Wednesday, August 10, 2016 3:01 PM > Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius= -ext.all@ietf.org > Subject: [IANA #920427] Last Call: ext-10.txt> (RADIUS Extensions for IP Port Configuration and Reporting) > to Proposed Standard > > (BEGIN IANA COMMENTS) > > IESG/Authors/WG Chairs: > > IANA has completed its review of draft-ietf-radext-ip-port-radius-ext- > 10.txt. If any part of this review is inaccurate, please let us know. > > IANA has a question about one of the actions requested in the IANA > Considerations section of this document. > > IANA understands that, upon approval of this document, there are three > actions which IANA must complete. > > First, in the IPFIX Information Elements subregistry of the IP Flow > Information Export (IPFIX) Entities registry located at: > > https://www.iana.org/assignments/ipfix/ > > three new information elements are to be registered as follows: > > ElementID: [ TBD-at-registration ] > Name: transportType > Data Type: unsigned8 > Data Type Semantics: > Status: current > Description: The value indicates TCP/UDP ports and ICMP Identifiers (1), > TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5). > Units: > Range: > References: [ RFC-to-be ] > > ElementID: [ TBD-at-registration ] > Name: natTransportLimit > Data Type: unsigned16 > Data Type Semantics: > Status: current > Description: The value is the max number of IP transport ports to be > assigned to an end user associated with one or more IPv4 addresses. > Units: > Range: > References: [ RFC-to-be ] > > ElementID: [ TBD-at-registration ] > Name: localID > Data Type: string > Data Type Semantics: > Status: current > Description: The value is an IPv4 or IPv6 address, a MAC address, a > VLAN ID, etc. > Units: > Range: > References: [ RFC-to-be ] > > IANA Question --> for each of these three registrations, could the > authors please supply the data type semantics and the units to be > registered with these values? > > As this document requests registrations in an Expert Review or > Specification Required (see RFC 5226) registry, we will initiate the > required Expert Review via a separate request. Expert review will need > to be completed before your document can be approved for publication as > an RFC. > > Second, in the Radius Attribute Types subregistry of the Radius Types > registry located at: > > http://www.iana.org/assignments/ > > three new Radius attribute types are to be registered under the 241 > Extended-Attribute-1 type as follows: > > Value: 241.[ TBD-at-registration ] > Description: IP-Port-Limit-Info > Reference: [ RFC-to-be ] > > Value: 241.[ TBD-at-registration ] > Description: IP-Port-Range > Reference: [ RFC-to-be ] > > Value: 241.[ TBD-at-registration ] > Description: IP-Port-Forwarding-Map > Reference: [ RFC-to-be ] > > Third, IANA notes that the authors request: > > This specification requests allocation of the following TLVs: > Name Value Meaning > ---- ----- ------- > IP-Port-Type 1 see Section 3.2.1 > IP-Port-Limit 2 see Section 3.2.2 > IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 IP-Port-Int-IPv4-Addr 4 see > Section 3.2.4 IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 IP-Port-Int- > Port 6 see Section 3.2.6 IP-Port-Ext-Port 7 see Section 3.2.7 IP-Port- > Alloc 8 see Section 3.2.8 IP-Port-Range-Start 9 see Section 3.2.9 IP- > Port-Range-End 10 see Section 3.2.10 IP-Port-Local-Id 11 see Section > 3.2.11 > > IANA Question --> Specifically, in what registry are these new TLVs to > be registered? > > IANA understands that the three actions above are the only ones > required to be completed upon approval of this document. > > Note: The actions requested in this document will not be completed > until the document has been approved for publication as an RFC. This > message is only to confirm what actions will be performed. > > > Thank you, > > Sabrina Tanamal > IANA Specialist > ICANN > > (END IANA COMMENTS) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_DC7880973D477648AC15A3BA66253F686E942927SJCEML701CHMchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Lionel,

 <= /p>

Sorry but I wasn't aware = of that.

 <= /p>

Regards=

Dean

 <= /p>

From: lionel.m= orand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, August 11, 2016 1:32 AM
To: Dean cheng; drafts-lastcall-comment@iana.org
Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org=
Subject: RE : RE: [IANA #920427] Last Call: <draft-ietf-rade= xt-ip-port-radius-ext-10.txt> (RADIUS Extensions for IP Port Configurati= on and Reporting) to Proposed Standard

 

Hi Dean,

Thank you for the update. However, it is recommended to answer first to the= questions (form IANA or others) before updating the draft. It would avoid = too many iterations. And it will allow to check if the proposed answers are= correct/acceptable.

Regards,

Lionel

Le 11 ao=FBt 2016 03:43, Dean cheng <dean.cheng@huawei.com> a =E9crit :=

Hi Sabrina,

Thank you for the review and comments.
We've just uploaded a new revision (11.txt)
that intends to resolve IANA questions as
follows:

> IANA Question --> for each of these three registrations, could the<= br> > authors please supply the data type semantics and the units to be
> registered with these values?

Regards
Dean

> -----Original Message-----
> From: Sabrina Tanamal via RT [mailto:drafts-lastcall-comment@iana.org]
> Sent: Wednesday, August 10, 2016 3:01 PM
> Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org
> Subject: [IANA #920427] Last Call: <draft-ietf-radext-ip-port-radiu= s-
> ext-10.txt> (RADIUS Extensions for IP Port Configuration and Report= ing)
> to Proposed Standard
>
> (BEGIN IANA COMMENTS)
>
> IESG/Authors/WG Chairs:
>
> IANA has completed its review of draft-ietf-radext-ip-port-radius-ext-=
> 10.txt. If any part of this review is inaccurate, please let us know.<= br> >
> IANA has a question about one of the actions requested in the IANA
> Considerations section of this document.
>
> IANA understands that, upon approval of this document, there are three=
> actions which IANA must complete.
>
> First, in the IPFIX Information Elements subregistry of the IP Flow > Information Export (IPFIX) Entities registry located at:
>
> https://www.iana.o= rg/assignments/ipfix/
>
> three new information elements are to be registered as follows:
>
> ElementID: [ TBD-at-registration ]
> Name: transportType
> Data Type: unsigned8
> Data Type Semantics:
> Status: current
> Description: The value indicates TCP/UDP ports and ICMP Identifiers (1= ),
> TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5= ).
> Units:
> Range:
> References: [ RFC-to-be ]
>
> ElementID: [ TBD-at-registration ]
> Name: natTransportLimit
> Data Type: unsigned16
> Data Type Semantics:
> Status: current
> Description: The value is the max number of IP transport ports to be > assigned to an end user associated with one or more IPv4 addresses. > Units:
> Range:
> References: [ RFC-to-be ]
>
> ElementID: [ TBD-at-registration ]
> Name: localID
> Data Type: string
> Data Type Semantics:
> Status: current
> Description: The value is an IPv4 or IPv6 address, a MAC address, a > VLAN ID, etc.
> Units:
> Range:
> References: [ RFC-to-be ]
>
> IANA Question --> for each of these three registrations, could the<= br> > authors please supply the data type semantics and the units to be
> registered with these values?
>
> As this document requests registrations in an Expert Review or
> Specification Required (see RFC 5226) registry, we will initiate the > required Expert Review via a separate request. Expert review will need=
> to be completed before your document can be approved for publication a= s
> an RFC.
>
> Second, in the Radius Attribute Types subregistry of the Radius Types<= br> > registry located at:
>
> http://www.iana.org/assig= nments/
>
> three new Radius attribute types are to be registered under the 241 > Extended-Attribute-1 type as follows:
>
> Value: 241.[ TBD-at-registration ]
> Description: IP-Port-Limit-Info
> Reference: [ RFC-to-be ]
>
> Value: 241.[ TBD-at-registration ]
> Description: IP-Port-Range
> Reference: [ RFC-to-be ]
>
> Value: 241.[ TBD-at-registration ]
> Description: IP-Port-Forwarding-Map
> Reference: [ RFC-to-be ]
>
> Third, IANA notes that the authors request:
>
> This specification requests allocation of the following TLVs:
> Name Value Meaning
> ---- ----- -------
> IP-Port-Type 1 see Section 3.2.1
> IP-Port-Limit 2 see Section 3.2.2
> IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 IP-Port-Int-IPv4-Addr 4 see<= br> > Section 3.2.4 IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 IP-Port-Int- > Port 6 see Section 3.2.6 IP-Port-Ext-Port 7 see Section 3.2.7 IP-Port-=
> Alloc 8 see Section 3.2.8 IP-Port-Range-Start 9 see Section 3.2.9 IP-<= br> > Port-Range-End 10 see Section 3.2.10 IP-Port-Local-Id 11 see Section > 3.2.11
>
> IANA Question --> Specifically, in what registry are these new TLVs= to
> be registered?
>
> IANA understands that the three actions above are the only ones
> required to be completed upon approval of this document.
>
> Note:  The actions requested in this document will not be complet= ed
> until the document has been approved for publication as an RFC. This > message is only to confirm what actions will be performed.
>
>
> Thank you,
>
> Sabrina Tanamal
> IANA Specialist
> ICANN
>
> (END IANA COMMENTS)

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_DC7880973D477648AC15A3BA66253F686E942927SJCEML701CHMchi_-- From nobody Mon Aug 15 12:56:21 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B7B4112D75C; Mon, 15 Aug 2016 12:56:15 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9240C12D76B for ; Mon, 15 Aug 2016 12:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=redhoundsoftware-com.20150623.gappssmtp.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 FyB_yBet-f4S for ; Mon, 15 Aug 2016 12:56:13 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 0C95912D75C for ; Mon, 15 Aug 2016 12:56:13 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id x25so25866216qtx.2 for ; Mon, 15 Aug 2016 12:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=dJMhGiBB0rr3mnd78VeaRF++unrNucAp9WA1as42Tec=; b=sqm/cXeAu8NMX9Q55Vpu0MB97zSSA50kWlA9e2OqVTNfXQgMs4a1inF1GnMdnJ3RXO Nin8rHFnyEGsV3DqALDNcj+qpxuu+coSdRVszHkvBgY/hPr9ZrDEIUF56rVHlvQbABHk TVRBz4HYWD2GSasKmSjvKlDO+sf26eV9Qn8AchRIzJ5vbiQTLgihVxDJVdEoK/JbpZ67 zTEgw6J7howheiNqhEbJEChm8Zrf0lhFOwBuz3C3HUCJkryaU1qxh7+dhEGriyVpaj5V NfBBprpzNND7iLAXqt/+U9hSPYHT0QShWbcvRi3Og7NWqhgoJcgFEmotsQfU11Zt03py nGlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=dJMhGiBB0rr3mnd78VeaRF++unrNucAp9WA1as42Tec=; b=TEasD4XfZ8IAVzmPzXPG1+YY6BZ+ap8twc+i+ZsDMe5vqnuD02M60JY51BPeEIDlGG yBFugy2tvpA+A9S4oRg+c/SvMEdNNu3anm9SmWIZG7ezlmBA6dlRXBUZn335XuvuOHl6 LJolxMJbZhDdc7eK2oVPmASx3zUIdya6Djcg7ZokNkYoBrOShhz4ZLgPNB6JkH/TOwX0 8IVgL95OZOAl21sURKszPAO9ffmkAmhZghUSJlm1YvcQjHOMI8Bp8rx92XVePvb4jlHO ZKt7uYysvmm+5/DDiyzpiWooPm25ltrfpJBkZczXzKM+hA6M7JApMXSVNhjkx1stgoVO 9PUg== X-Gm-Message-State: AEkoouuSQoLOae2Rcqcl+9+iisRMQyK/Zhfq83k7DuKAAWxnOS75Oz48ktEocIstosfhVg== X-Received: by 10.200.46.25 with SMTP id r25mr34336892qta.114.1471290972081; Mon, 15 Aug 2016 12:56:12 -0700 (PDT) Received: from [192.168.2.29] (pool-96-255-23-4.washdc.fios.verizon.net. [96.255.23.4]) by smtp.gmail.com with ESMTPSA id p2sm13249253qta.15.2016.08.15.12.56.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 15 Aug 2016 12:56:11 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.5.8.151023 Date: Mon, 15 Aug 2016 15:56:05 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: secdir review of draft-ietf-radext-ip-port-radius-ext-10 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160815195615.B7B4112D75C@ietfa.amsl.com> Resent-Date: Mon, 15 Aug 2016 12:56:15 -0700 (PDT) Archived-At: Cc: iesg@ietf.org, secdir@ietf.org Subject: [radext] secdir review of draft-ietf-radext-ip-port-radius-ext-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 19:56:16 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behavior for specific hosts. I've a few questions/comments: - The Security Considerations section currently references the security considerations from 2865 and 5176. Should 6887 be included to address considerations related to the forwarding attribute? - When the port limit attribute is used, does presentation of a new "global" setting undo previously established IP specific settings (or vice versa)? - Should the IP-Port-Range attribute require at least one of IP-Port-Ext-IPv4-Addr or IP-Port-Local-Id to be present? How is the attribute used when both are absent? - The summary statement associated with the attributes in section 1 might benefit from indicating the purpose of the attribute relative to each packet type in which it may appear (for example, the purpose of a port limit info attribute is different when included in an Access-Request than in an Access-Response). - Each attribute lists applicable packet types and indicates the attribute must not appear in any other packet type. It may be worth adding a note to clarify what should happen if the attribute does appear (assuming ignore). - The UE acronym on page 30 should be expanded. - In 3.1.2, change "are previously allocated" to "were previously allocated". - In 4.1.3, is "RADIUS associate" a commonly used term? This seems like a requirement on use with CoA-Requests that should be mentioned earlier. From nobody Tue Aug 16 08:29:24 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E99FA12B02C; Tue, 16 Aug 2016 08:29:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147136135892.23006.12001987221551537605.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 08:29:18 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Alexey Melnikov's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 15:29:19 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- On page 12: IP-Port-Int-IPv6-Addr TLV This TLV contains an IPv4 address that is associated with the Typo: should be IPv6? internal IP port number contained in the IP-Port-Int-Port TLV. For IPv6 network, either this TLV or IP-Port-Local-Id TLV must be included as part of the IP-Port-Forwarding-Map Attribute. Refer to Section 3.2.5. From nobody Tue Aug 16 12:02:13 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E08DA12D61D; Tue, 16 Aug 2016 12:02:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 12:02:06 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [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 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 19:02:07 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I find the absence of any definition of error handling behavior in this document to be a problem. I realize that the attributes specified in this document are meant to be transmitted between components that are all operated by the same administrative entity, but implementors can still make mistakes, and for those cases it seems like error handling should be defined. For example: - What happens if the AAA server sends an IP-Port-Limit-Info attribute with a larger limit than the CGN is able to allocate to that particular user? What is the CGN supposed to do and how is that communicated back to the AAA server? - What happens if the CGN sends an IP-Port-Range attribute that encompasses a larger range than a previously sent IP-Port-Limit-Info? What is the AAA server supposed to do? - What happens if the AAA server sends an IP-Port-Forwarding-Map attribute to map a port that is not within the requesting host's allocated range? Is the CGN expected to change the mapping and send a CoA with a different IP-Port-Forwarding-Map, or communicate some sort of error, or something else? There are surely other error cases. I think it's worth going through the uses of each attribute and specifying all the error handling behavior. This seems especially important since part of the motivation for these attributes is for identification and the consequences of erroneous identification could be severe for the user. Discussion of those consequences is also missing from Section 6. (2) Section 3.1.2 says: "For port allocation, both IP-Port-Range-Start TLV and IP- Port-Range-End TLV must be included; for port deallocation, the inclusion of these two TLVs is optional and if not included, it implies that all ports that are previously allocated are now deallocated." How does an AAA server distinguish between port allocation and deallocation requests if a deallocation request includes a range start and range end? Is the server supposed to assume that whatever range is specified by the most recently received IP-Port-Range attribute represents the only range of allocated ports for the host? What is the meaning of sending an IP-Port-Range request with only a start value or an end value but not both (as seems to be allowable by the above)? (3) The specification of IP-Port-Local-Id seems to allow for unnecessary exposure of potentially sensitive information. There is no explanation given for why the combination of the other identifiers included in IP-Port-Range and IP-Port-Forwarding attributes is insufficient to identify the host in DS-Extra-Lite and Lightweight 4over6 cases. As defined, it sounds like implementations could put basically any user, device, or interface identifier in there. If this TLV is actually necessary to communicate what these attributes are trying to accomplish, the justification for it should be provided and the limitations on when this field may be used and what kind of identifiers can appear here should be stated. (4) The shepherd write-up discusses two different approaches to defining the sub-TLV types and then says: "Both approaches were considered as valid and the WG has decided to let IANA decide what the approach is preferred when allocating the TLV-Type for the sub-TLVs defined in this document." This is not appropriate. The document needs to explicitly define how the types should be allocated and should not leave the decision to IANA. I see that IANA has already noted that Section 7.3 is ambiguous about this; the WG needs to make a choice. (5) Section 6 seems to be missing a discussion of the consequences of communicating erroneous port range and port mapping information. Since part of the motivation for these attributes is identification of the host, this needs to be discussed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) What does it mean for an IP-Port-Range attribute to have IP-Port-Type 1 or 2? Can numbers in the whole range be used for any of the port or identifier types? Or is the range expected to be split up somehow among the multiple types? I think this needs to be explained. (2) In 4.1.4, how does the ISP know that Joe is traveling? From nobody Tue Aug 16 12:51:14 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D24C712D743; Tue, 16 Aug 2016 12:51:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147137707081.22859.2851427602812447816.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 12:51:10 -0700 Archived-At: Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Alissa Cooper's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 19:51:11 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-radext-datatypes-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 4.1, if the registration policy is Standards Action doesn't that obviate the need to say anything about IETF Review? From nobody Tue Aug 16 13:41:45 2016 Return-Path: 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 AF82B12D821; Tue, 16 Aug 2016 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 iQ5rjIAmEOa2; Tue, 16 Aug 2016 13:41:40 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 A4AA712D778; Tue, 16 Aug 2016 13:41:37 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 74so141687203uau.0; Tue, 16 Aug 2016 13:41:37 -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=+skGdqnk+ssMPR7G/cUdYE+qR9ndDT6nAp387UHTEIM=; b=vddSmmfQrmqzNSksr5BAWNcMZN5qWyt+pgO55S0prVl59PNGaZram3PY2HYyjJLAOg /echWGPrbQfenj3fOTTGO6Dl920xzx99HR19JaUe3P3+CY9aGp2/Iu5lIsYxboKgXIco 0dXeq6UzZ/b66aXs2A1OS4UzFkNdH+n/6a272ShRjH5i/dlygwcc5DGsIN6hX8w4Kam8 /mXzerRAaqAsW4xwIdXhKibcFyXbQVweWPlwN2a/euXkkBtbiaIXh3sTictkHOZsfVi1 qYcaStWmn2qDFO6RWtHnZH2mLMtFW1cb9fhVGELGjzfMoRT+9Gts/Lh6XZlrQDUZgRsU +L/Q== 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=+skGdqnk+ssMPR7G/cUdYE+qR9ndDT6nAp387UHTEIM=; b=ftPhMIJMObdtMs9JHr2T0gZL7c+NZK0SeMRc61cQAxremFTPg01zaH3kJcd5pKb+p9 Vvpadm+E4QTLCg0O65ZFOhuhbU4JSz6sSsfRT/IV0P01v2Re+wfCqRJoMs1AsBjYyDsj 3D5LVgRYfTEy1oMvjn2haNPUzyOcCRG9ITnsVLzNY3dNIN801hF9Hypn6nSd5Ot+guUB kFNy64lkImEKHB5f0l41kiqWRODp3gKMkggt3r0VhXj1l4ts8q6WKWaJzxT900+27i1A cz8d5mLu8eqJbuX4/UWALrynTCWwlDtjYeY8lOiBZEXAwrBtW/1laxHQ5Z6YUvvq0NdP hdhQ== X-Gm-Message-State: AEkoouvDKw8fBMbL80H4ClpS043RfQyMMZ5a9mntdRQ36L2Zr719Xvu8NXQkOWT8SvGrpNd4krvFQKDTBZ6dZQ== X-Received: by 10.176.81.237 with SMTP id h42mr17629973uaa.95.1471380096700; Tue, 16 Aug 2016 13:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Tue, 16 Aug 2016 13:41:36 -0700 (PDT) In-Reply-To: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 16 Aug 2016 16:41:36 -0400 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , The IESG , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 20:41:43 -0000 Alissa, Thanks for your detailed review, this is helpful. Hopefully we will be able to resolve this with the editors and shepherd before Thursday. I have one question in line that may help with the resolution for at least #1 & #6. On Tue, Aug 16, 2016 at 3:02 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-radext-ip-port-radius-ext-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) I find the absence of any definition of error handling behavior in > this document to be a problem. I realize that the attributes specified in > this document are meant to be transmitted between components that are all > operated by the same administrative entity, but implementors can still > make mistakes, and for those cases it seems like error handling should be > defined. For example: > > - What happens if the AAA server sends an IP-Port-Limit-Info attribute > with a larger limit than the CGN is able to allocate to that particular > user? What is the CGN supposed to do and how is that communicated back to > the AAA server? > > - What happens if the CGN sends an IP-Port-Range attribute that > encompasses a larger range than a previously sent IP-Port-Limit-Info? > What is the AAA server supposed to do? > > - What happens if the AAA server sends an IP-Port-Forwarding-Map > attribute to map a port that is not within the requesting host's > allocated range? Is the CGN expected to change the mapping and send a CoA > with a different IP-Port-Forwarding-Map, or communicate some sort of > error, or something else? > > There are surely other error cases. I think it's worth going through the > uses of each attribute and specifying all the error handling behavior. > This seems especially important since part of the motivation for these > attributes is for identification and the consequences of erroneous > identification could be severe for the user. Discussion of those > consequences is also missing from Section 6. As an alternative, I usually approach this type of problem as defining what is acceptable and making everything else less acceptable. White lists are much easier to maintain and eliminate the possibility of missing something. If you and the WG agree, could we go forward with that approach instead of defining all possible problems, just limiting what is acceptable and making everything else an error? This approach applies to a few of your other discuss points as well, namely #2, #5, and to some degree #3. > > (2) Section 3.1.2 says: > > "For port allocation, both IP-Port-Range-Start TLV and IP- > Port-Range-End TLV must be included; for port deallocation, the > inclusion of these two TLVs is optional and if not included, it > implies that all ports that are previously allocated are now > deallocated." > > How does an AAA server distinguish between port allocation and > deallocation requests if a deallocation request includes a range start > and range end? Is the server supposed to assume that whatever range is > specified by the most recently received IP-Port-Range attribute > represents the only range of allocated ports for the host? What is the > meaning of sending an IP-Port-Range request with only a start value or an > end value but not both (as seems to be allowable by the above)? > > (3) The specification of IP-Port-Local-Id seems to allow for unnecessary > exposure of potentially sensitive information. There is no explanation > given for why the combination of the other identifiers included in > IP-Port-Range and IP-Port-Forwarding attributes is insufficient to > identify the host in DS-Extra-Lite and Lightweight 4over6 cases. As > defined, it sounds like implementations could put basically any user, > device, or interface identifier in there. If this TLV is actually > necessary to communicate what these attributes are trying to accomplish, > the justification for it should be provided and the limitations on when > this field may be used and what kind of identifiers can appear here > should be stated. > > (4) The shepherd write-up discusses two different approaches to defining > the sub-TLV types and then says: "Both approaches were considered as > valid and the WG has decided to let IANA decide what the approach is > preferred when allocating the TLV-Type for the sub-TLVs defined in this > document." This is not appropriate. The document needs to explicitly > define how the types should be allocated and should not leave the > decision to IANA. I see that IANA has already noted that Section 7.3 is > ambiguous about this; the WG needs to make a choice. Thank you, and yes, the WG needs to make a decision. Kathleen > > (5) Section 6 seems to be missing a discussion of the consequences of > communicating erroneous port range and port mapping information. Since > part of the motivation for these attributes is identification of the > host, this needs to be discussed. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) What does it mean for an IP-Port-Range attribute to have IP-Port-Type > 1 or 2? Can numbers in the whole range be used for any of the port or > identifier types? Or is the range expected to be split up somehow among > the multiple types? I think this needs to be explained. > > (2) In 4.1.4, how does the ISP know that Joe is traveling? > > -- Best regards, Kathleen From nobody Tue Aug 16 13:54:51 2016 Return-Path: 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 17FDE12D18E; Tue, 16 Aug 2016 13:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=AdlAXb6O; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=PTlgEqbt 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 ZV-idGpRsOuY; Tue, 16 Aug 2016 13:54:43 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C45812D1BD; Tue, 16 Aug 2016 13:54:43 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 77968204D7; Tue, 16 Aug 2016 16:54:42 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 16 Aug 2016 16:54:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=meXPn8E6g3/pXDgZWbocEvC3JCY=; b=AdlAXb 6OnWY8jRM6qEknQrIc9hgwEECVurScCMVZXa04JqTat+dCTFPm72byPbju5xICVu cvqDifHiQSkn76AQ3Z63gVwzZ83ySaDxUMfHbl88LbSwFm2nUUMdJLZKdGObTmm4 hTnp6zHiK+xICQjI7QtmkVbSrB3chWte/lMg8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=meXPn8E6g3/pXDg ZWbocEvC3JCY=; b=PTlgEqbt/TqBS/xJAjR72wbpx3fq3hfd0Kgi/SVcIfluiX3 zJajVnb08u3GqCdr7R6rz7lkqxR7MjQ/+6CX1NtSc1vE/HS6fKtZI3OHg/SoyBUy HW1l3V3XXtg7CmtryhAKuJcwaNe6qLkMpHjcfoH7XfYwDgkqJEtHsjgPQgto= X-Sasl-enc: qv3KFKpxyN2eWkxVjZ/plfQbATybb8Y6Gd+h3VUzsA2Y 1471380881 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 24072F296F; Tue, 16 Aug 2016 16:54:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Tue, 16 Aug 2016 16:54:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , IESG , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 20:54:46 -0000 > On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty = wrote: >=20 > Alissa, >=20 > Thanks for your detailed review, this is helpful. Hopefully we will > be able to resolve this with the editors and shepherd before Thursday. > I have one question in line that may help with the resolution for at > least #1 & #6. >=20 > On Tue, Aug 16, 2016 at 3:02 PM, Alissa Cooper = wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> (1) I find the absence of any definition of error handling behavior = in >> this document to be a problem. I realize that the attributes = specified in >> this document are meant to be transmitted between components that are = all >> operated by the same administrative entity, but implementors can = still >> make mistakes, and for those cases it seems like error handling = should be >> defined. For example: >>=20 >> - What happens if the AAA server sends an IP-Port-Limit-Info = attribute >> with a larger limit than the CGN is able to allocate to that = particular >> user? What is the CGN supposed to do and how is that communicated = back to >> the AAA server? >>=20 >> - What happens if the CGN sends an IP-Port-Range attribute that >> encompasses a larger range than a previously sent IP-Port-Limit-Info? >> What is the AAA server supposed to do? >>=20 >> - What happens if the AAA server sends an IP-Port-Forwarding-Map >> attribute to map a port that is not within the requesting host's >> allocated range? Is the CGN expected to change the mapping and send a = CoA >> with a different IP-Port-Forwarding-Map, or communicate some sort of >> error, or something else? >>=20 >> There are surely other error cases. I think it's worth going through = the >> uses of each attribute and specifying all the error handling = behavior. >> This seems especially important since part of the motivation for = these >> attributes is for identification and the consequences of erroneous >> identification could be severe for the user. Discussion of those >> consequences is also missing from Section 6. >=20 > As an alternative, I usually approach this type of problem as defining > what is acceptable and making everything else less acceptable. White > lists are much easier to maintain and eliminate the possibility of > missing something. If you and the WG agree, could we go forward with > that approach instead of defining all possible problems, just limiting > what is acceptable and making everything else an error? =20 I think it=E2=80=99s fine to say =E2=80=9Cthe only correct behavior is = X=E2=80=9D but you still need to say what implementations are expected = to do when not-X happens. And X will have different values for the = different usages of each of these attributes. Alissa > This approach > applies to a few of your other discuss points as well, namely #2, #5, > and to some degree #3. >=20 >>=20 >> (2) Section 3.1.2 says: >>=20 >> "For port allocation, both IP-Port-Range-Start TLV and IP- >> Port-Range-End TLV must be included; for port deallocation, the >> inclusion of these two TLVs is optional and if not included, it >> implies that all ports that are previously allocated are now >> deallocated." >>=20 >> How does an AAA server distinguish between port allocation and >> deallocation requests if a deallocation request includes a range = start >> and range end? Is the server supposed to assume that whatever range = is >> specified by the most recently received IP-Port-Range attribute >> represents the only range of allocated ports for the host? What is = the >> meaning of sending an IP-Port-Range request with only a start value = or an >> end value but not both (as seems to be allowable by the above)? >>=20 >> (3) The specification of IP-Port-Local-Id seems to allow for = unnecessary >> exposure of potentially sensitive information. There is no = explanation >> given for why the combination of the other identifiers included in >> IP-Port-Range and IP-Port-Forwarding attributes is insufficient to >> identify the host in DS-Extra-Lite and Lightweight 4over6 cases. As >> defined, it sounds like implementations could put basically any user, >> device, or interface identifier in there. If this TLV is actually >> necessary to communicate what these attributes are trying to = accomplish, >> the justification for it should be provided and the limitations on = when >> this field may be used and what kind of identifiers can appear here >> should be stated. >>=20 >> (4) The shepherd write-up discusses two different approaches to = defining >> the sub-TLV types and then says: "Both approaches were considered as >> valid and the WG has decided to let IANA decide what the approach is >> preferred when allocating the TLV-Type for the sub-TLVs defined in = this >> document." This is not appropriate. The document needs to explicitly >> define how the types should be allocated and should not leave the >> decision to IANA. I see that IANA has already noted that Section 7.3 = is >> ambiguous about this; the WG needs to make a choice. >=20 > Thank you, and yes, the WG needs to make a decision. >=20 > Kathleen >=20 >>=20 >> (5) Section 6 seems to be missing a discussion of the consequences of >> communicating erroneous port range and port mapping information. = Since >> part of the motivation for these attributes is identification of the >> host, this needs to be discussed. >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> (1) What does it mean for an IP-Port-Range attribute to have = IP-Port-Type >> 1 or 2? Can numbers in the whole range be used for any of the port or >> identifier types? Or is the range expected to be split up somehow = among >> the multiple types? I think this needs to be explained. >>=20 >> (2) In 4.1.4, how does the ISP know that Joe is traveling? >>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Tue Aug 16 14:15:29 2016 Return-Path: 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 F32DA12D181; Tue, 16 Aug 2016 14:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 BGQC2FpwajLz; Tue, 16 Aug 2016 14:15:25 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 CB1E912B024; Tue, 16 Aug 2016 14:15:24 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id c52so3741823qte.1; Tue, 16 Aug 2016 14:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2UgViBvL/I+tT2krSavk7g0yhsv/bvir4d4tnY7Y54c=; b=N/+IiRtWYJ3YMOwc+CrNJzX6v5MnKFJ+XpejpY52frC++M/Tu2N+WTpkZAuwaJ3hKq zunbojBormaJ6lI7TC6sZa9+jkOY/KL1nO+MVnS83Zq66jXF5eyMOLIONBxzFnsSsyWl 0MAxbnFojpeMOujFTYKY5oompIdHlWQogXEz1ckchTkWtiBXUXOqLQfFTo5jbNoLFg3P ehC7RSNqUN0xKI6O/VjpIAgD7srqCEMhEF8yNGLNkoAnitKKs0P9pedlKP66j8Ee54Lc j2LPV/2TRj1IlQb4Ecw9tFuwoPaO/w07e2N/ispPSQmtz3XRTuEPCSvXdPyTGzftd+kD 1DFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2UgViBvL/I+tT2krSavk7g0yhsv/bvir4d4tnY7Y54c=; b=ZZ/YzOa8dPLYiEzwrMFiFE3xyDOJDFZiJb9/Nr5E75QBgH0fFKa5vsuJWuplKT5vM3 TMANksx06KdzJmGCnpYxZt0csGk2/Tde8T1p+mlU5ZYyLMYXxsG0YBUEO7FHGWCLrZOJ nWuNjSYlFxK+53Yl4VWd4V6Wq4zXgKiTnuS0JAtfewTHVs9xUcvtQrnoib8c0ow8hqyw F8YSY3mvpzsIC/XshK6ODlcl9htBkarLF0h3/WS2PGhcnUzfST8+lln8r1dAhJw5g0IP s9qq2NqKzHGiDD4QZjeZO34p62izr0Y4hffpdTewRseaZmPpN54bdenhWHcBtAfFBGDf X3Cg== X-Gm-Message-State: AEkoous0qrpaHjbfmcbjbqkwLiidgYf3vASG4QUzNgu6ffwx/rldeQrxjS94cf9yUxcxTQ== X-Received: by 10.200.45.181 with SMTP id p50mr39283483qta.31.1471382123882; Tue, 16 Aug 2016 14:15:23 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id d133sm14836805qke.40.2016.08.16.14.15.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 14:15:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Tue, 16 Aug 2016 17:15:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> To: Alissa Cooper Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , IESG , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:15:27 -0000 Sent from my iPhone > On Aug 16, 2016, at 4:54 PM, Alissa Cooper wrote: >=20 >=20 >> On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty wrote: >>=20 >> Alissa, >>=20 >> Thanks for your detailed review, this is helpful. Hopefully we will >> be able to resolve this with the editors and shepherd before Thursday. >> I have one question in line that may help with the resolution for at >> least #1 & #6. >>=20 >>> On Tue, Aug 16, 2016 at 3:02 PM, Alissa Cooper wrote= : >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> (1) I find the absence of any definition of error handling behavior in >>> this document to be a problem. I realize that the attributes specified i= n >>> this document are meant to be transmitted between components that are al= l >>> operated by the same administrative entity, but implementors can still >>> make mistakes, and for those cases it seems like error handling should b= e >>> defined. For example: >>>=20 >>> - What happens if the AAA server sends an IP-Port-Limit-Info attribute >>> with a larger limit than the CGN is able to allocate to that particular >>> user? What is the CGN supposed to do and how is that communicated back t= o >>> the AAA server? >>>=20 >>> - What happens if the CGN sends an IP-Port-Range attribute that >>> encompasses a larger range than a previously sent IP-Port-Limit-Info? >>> What is the AAA server supposed to do? >>>=20 >>> - What happens if the AAA server sends an IP-Port-Forwarding-Map >>> attribute to map a port that is not within the requesting host's >>> allocated range? Is the CGN expected to change the mapping and send a Co= A >>> with a different IP-Port-Forwarding-Map, or communicate some sort of >>> error, or something else? >>>=20 >>> There are surely other error cases. I think it's worth going through the= >>> uses of each attribute and specifying all the error handling behavior. >>> This seems especially important since part of the motivation for these >>> attributes is for identification and the consequences of erroneous >>> identification could be severe for the user. Discussion of those >>> consequences is also missing from Section 6. >>=20 >> As an alternative, I usually approach this type of problem as defining >> what is acceptable and making everything else less acceptable. White >> lists are much easier to maintain and eliminate the possibility of >> missing something. If you and the WG agree, could we go forward with >> that approach instead of defining all possible problems, just limiting >> what is acceptable and making everything else an error? =20 >=20 > I think it=E2=80=99s fine to say =E2=80=9Cthe only correct behavior is X=E2= =80=9D but you still need to say what implementations are expected to do whe= n not-X happens. And X will have different values for the different usages o= f each of these attributes. >=20 > Alissa >=20 >> This approach >> applies to a few of your other discuss points as well, namely #2, #5, >> and to some degree #3. >>=20 >>>=20 >>> (2) Section 3.1.2 says: >>>=20 >>> "For port allocation, both IP-Port-Range-Start TLV and IP- >>> Port-Range-End TLV must be included; for port deallocation, the >>> inclusion of these two TLVs is optional and if not included, it >>> implies that all ports that are previously allocated are now >>> deallocated." >>>=20 >>> How does an AAA server distinguish between port allocation and >>> deallocation requests if a deallocation request includes a range start >>> and range end? Is the server supposed to assume that whatever range is >>> specified by the most recently received IP-Port-Range attribute >>> represents the only range of allocated ports for the host? What is the >>> meaning of sending an IP-Port-Range request with only a start value or a= n >>> end value but not both (as seems to be allowable by the above)? >>>=20 >>> (3) The specification of IP-Port-Local-Id seems to allow for unnecessary= >>> exposure of potentially sensitive information. There is no explanation >>> given for why the combination of the other identifiers included in >>> IP-Port-Range and IP-Port-Forwarding attributes is insufficient to >>> identify the host in DS-Extra-Lite and Lightweight 4over6 cases. As >>> defined, it sounds like implementations could put basically any user, >>> device, or interface identifier in there. If this TLV is actually >>> necessary to communicate what these attributes are trying to accomplish,= >>> the justification for it should be provided and the limitations on when >>> this field may be used and what kind of identifiers can appear here >>> should be stated. >>>=20 >>> (4) The shepherd write-up discusses two different approaches to defining= >>> the sub-TLV types and then says: "Both approaches were considered as >>> valid and the WG has decided to let IANA decide what the approach is >>> preferred when allocating the TLV-Type for the sub-TLVs defined in this >>> document." This is not appropriate. The document needs to explicitly >>> define how the types should be allocated and should not leave the >>> decision to IANA. I see that IANA has already noted that Section 7.3 is >>> ambiguous about this; the WG needs to make a choice. >>=20 >> Thank you, and yes, the WG needs to make a decision. >>=20 >> Kathleen >>=20 >>>=20 >>> (5) Section 6 seems to be missing a discussion of the consequences of >>> communicating erroneous port range and port mapping information. Since >>> part of the motivation for these attributes is identification of the >>> host, this needs to be discussed. >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> (1) What does it mean for an IP-Port-Range attribute to have IP-Port-Typ= e >>> 1 or 2? Can numbers in the whole range be used for any of the port or >>> identifier types? Or is the range expected to be split up somehow among >>> the multiple types? I think this needs to be explained. >>>=20 >>> (2) In 4.1.4, how does the ISP know that Joe is traveling? >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 From nobody Tue Aug 16 14:16:01 2016 Return-Path: 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 930F012B024; Tue, 16 Aug 2016 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 uHUz4w26lPkT; Tue, 16 Aug 2016 14:15:58 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 677B112D181; Tue, 16 Aug 2016 14:15:54 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id t7so2375846qkh.1; Tue, 16 Aug 2016 14:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b+TS86sjwyF/yYb4HdIPD9KSCKV+jPr9Ftv8RiGvrZg=; b=SX01ptNvqOtCOI7ThupQ19/jTfJiZ2672lmRRSPcddza3uT7wHQ4epUISKsldi8uPU SioQZgRaYzZdwYrJlJ4UVHMEjOatieHH5RclLkYCV4muDZmsBIZG5h6/PtP4EvRcs4YV dOmLHF89Ikf4YwVN7zlH96iQgpljGs38UIc0NncwUm44Ww9iOvUvmoCRI6OUdIFB9a1J IV7cwp4IMcEZmDvSP0sCEjWh4ra0kGmlbOBSpz9mrm6vj7lsyAmI8VCVx/bw6bTH+6rS bYdZnW2lA1G1MDsG+xYFEm1UUHCAum2jziiIUKebeINxwpQ8gCskcmm0D1via7bDTyYv GT+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b+TS86sjwyF/yYb4HdIPD9KSCKV+jPr9Ftv8RiGvrZg=; b=TPNgLvabHbotJSdfm0dPh2ie3q0PGjpPjvChFoqxCBS6XpWstSL6Q84sD4FTXIvjfG NQ+O81jKjwd5lkqDobn7JJxMy3SCnQRndFKMCan9og5J0XvpCFdMJXtVK5n3+euZBBQG bhpwE+faf361F1JyMKms3zueQ+10v7n7Sd5k/40TXwcdf5lx1NgnX4fTADFT/OtlzPxh 1CI/KjYUo5+VG4D+uFaa7fWqTKHVtmH9LC/J7JU4VhBu/0YQOICBUFdMF7ZaQv2OVaKW rL0KNWnvb/vrD9lzDjaGgRYIcvJvNrObUREWwHmH3zsMxODHPdBqBbkcw0/Zuim/kNkg pxAQ== X-Gm-Message-State: AEkoousR5ZwD/H2kqiYUsDd/uWQ7IuRybsYwK+KQcxaXNV+JkA7vW0+meVQa7BEFdM7BCg== X-Received: by 10.233.232.195 with SMTP id a186mr39443594qkg.18.1471382153456; Tue, 16 Aug 2016 14:15:53 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id d133sm14837791qke.40.2016.08.16.14.15.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 14:15:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Tue, 16 Aug 2016 17:15:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> To: Alissa Cooper Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , IESG , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:16:00 -0000 Sent from my iPhone > On Aug 16, 2016, at 4:54 PM, Alissa Cooper wrote: >=20 >=20 >> On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty wrote: >>=20 >> Alissa, >>=20 >> Thanks for your detailed review, this is helpful. Hopefully we will >> be able to resolve this with the editors and shepherd before Thursday. >> I have one question in line that may help with the resolution for at >> least #1 & #6. >>=20 >>> On Tue, Aug 16, 2016 at 3:02 PM, Alissa Cooper wrote= : >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> (1) I find the absence of any definition of error handling behavior in >>> this document to be a problem. I realize that the attributes specified i= n >>> this document are meant to be transmitted between components that are al= l >>> operated by the same administrative entity, but implementors can still >>> make mistakes, and for those cases it seems like error handling should b= e >>> defined. For example: >>>=20 >>> - What happens if the AAA server sends an IP-Port-Limit-Info attribute >>> with a larger limit than the CGN is able to allocate to that particular >>> user? What is the CGN supposed to do and how is that communicated back t= o >>> the AAA server? >>>=20 >>> - What happens if the CGN sends an IP-Port-Range attribute that >>> encompasses a larger range than a previously sent IP-Port-Limit-Info? >>> What is the AAA server supposed to do? >>>=20 >>> - What happens if the AAA server sends an IP-Port-Forwarding-Map >>> attribute to map a port that is not within the requesting host's >>> allocated range? Is the CGN expected to change the mapping and send a Co= A >>> with a different IP-Port-Forwarding-Map, or communicate some sort of >>> error, or something else? >>>=20 >>> There are surely other error cases. I think it's worth going through the= >>> uses of each attribute and specifying all the error handling behavior. >>> This seems especially important since part of the motivation for these >>> attributes is for identification and the consequences of erroneous >>> identification could be severe for the user. Discussion of those >>> consequences is also missing from Section 6. >>=20 >> As an alternative, I usually approach this type of problem as defining >> what is acceptable and making everything else less acceptable. White >> lists are much easier to maintain and eliminate the possibility of >> missing something. If you and the WG agree, could we go forward with >> that approach instead of defining all possible problems, just limiting >> what is acceptable and making everything else an error? =20 >=20 > I think it=E2=80=99s fine to say =E2=80=9Cthe only correct behavior is X=E2= =80=9D but you still need to say what implementations are expected to do whe= n not-X happens. And X will have different values for the different usages o= f each of these attributes. >=20 Agreed, thanks. Kathleen=20 > Alissa >=20 >> This approach >> applies to a few of your other discuss points as well, namely #2, #5, >> and to some degree #3. >>=20 >>>=20 >>> (2) Section 3.1.2 says: >>>=20 >>> "For port allocation, both IP-Port-Range-Start TLV and IP- >>> Port-Range-End TLV must be included; for port deallocation, the >>> inclusion of these two TLVs is optional and if not included, it >>> implies that all ports that are previously allocated are now >>> deallocated." >>>=20 >>> How does an AAA server distinguish between port allocation and >>> deallocation requests if a deallocation request includes a range start >>> and range end? Is the server supposed to assume that whatever range is >>> specified by the most recently received IP-Port-Range attribute >>> represents the only range of allocated ports for the host? What is the >>> meaning of sending an IP-Port-Range request with only a start value or a= n >>> end value but not both (as seems to be allowable by the above)? >>>=20 >>> (3) The specification of IP-Port-Local-Id seems to allow for unnecessary= >>> exposure of potentially sensitive information. There is no explanation >>> given for why the combination of the other identifiers included in >>> IP-Port-Range and IP-Port-Forwarding attributes is insufficient to >>> identify the host in DS-Extra-Lite and Lightweight 4over6 cases. As >>> defined, it sounds like implementations could put basically any user, >>> device, or interface identifier in there. If this TLV is actually >>> necessary to communicate what these attributes are trying to accomplish,= >>> the justification for it should be provided and the limitations on when >>> this field may be used and what kind of identifiers can appear here >>> should be stated. >>>=20 >>> (4) The shepherd write-up discusses two different approaches to defining= >>> the sub-TLV types and then says: "Both approaches were considered as >>> valid and the WG has decided to let IANA decide what the approach is >>> preferred when allocating the TLV-Type for the sub-TLVs defined in this >>> document." This is not appropriate. The document needs to explicitly >>> define how the types should be allocated and should not leave the >>> decision to IANA. I see that IANA has already noted that Section 7.3 is >>> ambiguous about this; the WG needs to make a choice. >>=20 >> Thank you, and yes, the WG needs to make a decision. >>=20 >> Kathleen >>=20 >>>=20 >>> (5) Section 6 seems to be missing a discussion of the consequences of >>> communicating erroneous port range and port mapping information. Since >>> part of the motivation for these attributes is identification of the >>> host, this needs to be discussed. >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> (1) What does it mean for an IP-Port-Range attribute to have IP-Port-Typ= e >>> 1 or 2? Can numbers in the whole range be used for any of the port or >>> identifier types? Or is the range expected to be split up somehow among >>> the multiple types? I think this needs to be explained. >>>=20 >>> (2) In 4.1.4, how does the ISP know that Joe is traveling? >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 From nobody Tue Aug 16 18:02:08 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1439A12B01A; Tue, 16 Aug 2016 18:02:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147139572703.19954.16899242977244663872.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 18:02:07 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Ben Campbell's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 01:02:07 -0000 Ben Campbell has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I originally intended the two comments under "Major Issues" to be points for a DISCUSS position. But I see Alissa has already captured the essence of them in her DISCUSS. Therefore I will ballot NO OBJECTION for now, and will watch that discussion. Major Issues: The guidance for IP-Port-Local-Id TLV contemplates using persistent client identifiers, such as MAC addresses. Is that necessary? I suspect the answer will be "yes". But if that is the case, the draft really needs a privacy considerations section to discuss the implications and tradeoffs. - 3.1.1, paragraph 7: "However, the RADIUS server is not required to honor such a preference." Please describe what it means to "not honor" such a preference? Does the server report an error? Does the transaction succeed, but report a different limit? Does the server just ignore the preference and do its own thing? (I expect this applies to any number of failure conditions.) Minor Issues: - Please clarify the applicability to IPv4 and IPv6. Specifically, I note that you define TLVs for "internal" IPv4 and IPv6 addresses, but only for "external" IPv4 address. I assume that to mean that this supports Nat44 and Nat64 use cases, but not anything that uses IPv6 in the "external" realm? (Whatever the answer, it would be helpful to have a paragraph or two to make that explicit.) -2, definition of "port-based device": Wouldn’t that more properly be called a port-mapping device? (anything using TCP or UDP would seem to be port-based) -3.1.1, last paragraph: This language precludes new extension packet types from using the attribute without updating this document. Is that really the intent? Would it make sense to say something like "... MUST NOT appear in any other RADIUS packet types defined at the time of this writing. If a future packet type uses the attribute, the specification of that packet type will need to define it's usage"? (Note that this issue repeats several times in the document.) Editorial Comments and Nits: - The use of the term "session" seems inconsistent. In some places it seems like an IPFlow or a NAT mapping, but in other places it seems like a network connection (i.e. NAS attachment.) - 1, list item 1: Singular/plural mismatch for "packet". Either "packet" should be "packets", or you need an article before RADIUS. (e.g. a RADIUS...packet.) Note that this error repeats many times in similar patterns throughout the document. -1, list item 2, last sentence: Convoluted sentence. Can it be simplified? -1, last paragraph: It would be helpful to mention that this draft defines IPFIX elements near the top of the section, and also in the abstract. -2, definition of "Internal IP Address": "refers to the IP address that is used as a source IP address" Used by what device? -2, definition of "mapping": I cannot parse the text. (Note that while the last paragraph in the section says this is taken from 6887 and 6888, neither of them seem to use this specific language.) -4.1, second paragraph: " A CGN function in a broadband network would most likely co-located on a BNG." There's a missing word in there somewhere. Maybe a "be" before "co-located"? -6, last paragraph: The paragraph doesn't parse. Should "deployed" be "deployments"? From nobody Tue Aug 16 18:59:24 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1212B028; Tue, 16 Aug 2016 18:59:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 18:59:20 -0700 Archived-At: Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 01:59:20 -0000 Ben Campbell has entered the following ballot position for draft-ietf-radext-datatypes-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -2.1.2, first paragraph: "The specification may, of course, define a new data type and use it in the same document." Am I correct to assume that any such definition must (or maybe MUST) be registered? (Maybe that's already covered in 6929?) -4.1: I'm curious why new data types need a policy as strong as "standards action". Is there a concern that people will get this wrong without the full weight of the IETF consensus process? Is there a concern that the numbering space will run out? Would it be reasonable to have a "specification-required" policy, with some guidance to the designated expert(s)? (Or is it because such data types need to be referenceable from standards track documents, perhaps related to the guidance against vendor-specific types?) From nobody Tue Aug 16 20:43:09 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A439C12D15E; Tue, 16 Aug 2016 20:43:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 20:43:07 -0700 Archived-At: Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 03:43:08 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-radext-datatypes-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.10 It is not clear from this definition how exactly a sender needs to encode this attribute on the wire. e.g. From the spec it looks like an IPv6 prefix such 2001:db8:dead:beef::/64 can legally be encoded using anywhere between 8 octets and 16 octets. What exactly is the preferred encoding? If you intend to allow all of the encodings can you please add an explicit statement to say so. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * I am not sure why this document uses Reserved fields in sections 3.10 and 3.11. Is it for alignment? Please clarify. I don't see exactly why aligning a 4 octet or a 16 octet value to a 16 bit boundary would provide any value. (I personally think such padding related stuff should be in the definition of the radius attribute that uses the datatype and not in the datatype itself but I will not block on this.) * Section 3.7 I think this text is confusing because "octet string" and network byte order do not seem to be compatible. Suggest rewording OLD: The "ifid" data type encodes an Interface-Id as an 8-octet string in network byte order NEW: The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in network byte order * Section 3.10 and 3.11 The separator between the Reserved field and the Prefix Length field is off by one position. From nobody Wed Aug 17 02:12:05 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2A12D1E4; Wed, 17 Aug 2016 02:12:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147142512074.12181.7172134882556272250.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 02:12:00 -0700 Archived-At: Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-radext-datatypes-06=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 09:12:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-radext-datatypes-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "As RADIUS does not encode information about data types in a packet, the numbers assigned to a data type will never occur in a packet." Given the Name must be unique, I don't see why a Value field is needed. Related: There is an inconsitency between section 4.1 and 6 regarding the use of Description/Name. From nobody Wed Aug 17 03:20:18 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C0AB012B036; Wed, 17 Aug 2016 03:20:16 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995EF12D5FF for ; Wed, 17 Aug 2016 03:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.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 BpI_L6Ab8y_A for ; Wed, 17 Aug 2016 03:20:13 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A84312B036 for ; Wed, 17 Aug 2016 03:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z7NQAiBomj8RLo5yoJDB2b9OhK7S13s3WaM77wQPNfw=; b=Hz61gfOouvnGneoKwHAH802t1ZaQysaI9wsewSKaMvCWBC4S68UoECHClLNO2zQm5x2y5DeJbcda8EoeDr6PE+/2/0j5/1Z3J5CFxysekKYr78abbzJ5YJjyQst+2JeA+60YgYccFWM5QNYUq0SbnqzDIOpasext9I4l/orJ7DA= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0079.outbound.protection.outlook.com [94.245.120.79]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-80-jYrbyZAFN3a2OjVg0gzIIw-1; Wed, 17 Aug 2016 11:20:08 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 17 Aug 2016 10:20:05 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0549.023; Wed, 17 Aug 2016 10:20:06 +0000 From: Tim Chown To: "ops-dir@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Thread-Index: AQHR+HCSP7sWZLORekKDzQgrLRshsA== Date: Wed, 17 Aug 2016 10:20:06 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 59b4e30b-f432-4814-8dba-08d3c6880f94 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:GUHATZG5Xujq3yozHbBAYNiMtTPgaP/4qM6E59h4i0uY3YeWiPlsmKsCsTlLD1wt+BviJ9OsOFtRnAGcCO/38WXWurjvK+VH8NolbbO7yodqq2no2HMGHi0Wn4pbzifrh5ou4WC7HcvibFL1wVKNCc3cgkV065pxZZs2Rs91Hto= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(192374486261705)(131327999870524)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0037FD6480 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(97736004)(3660700001)(54356999)(5001770100001)(2900100001)(450100001)(105586002)(2501003)(2906002)(76576001)(6116002)(586003)(81156014)(68736007)(5002640100001)(107886002)(19625215002)(77096005)(50986999)(8936002)(74316002)(7696003)(106116001)(101416001)(3846002)(230783001)(74482002)(87936001)(229853001)(8676002)(86362001)(106356001)(189998001)(9686002)(102836003)(7846002)(16236675004)(66066001)(122556002)(10400500002)(81166006)(3280700002)(92566002)(7736002)(33656002)(19627405001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2016 10:20:06.6736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: jYrbyZAFN3a2OjVg0gzIIw-1 Content-Type: multipart/alternative; boundary="_000_AMSPR07MB455AA9F3AF209ACB296D26BD6140AMSPR07MB455eurprd_" Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160817102016.C0AB012B036@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 03:20:16 -0700 (PDT) Archived-At: Subject: [radext] OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:20:17 -0000 --_000_AMSPR07MB455AA9F3AF209ACB296D26BD6140AMSPR07MB455eurprd_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These = comments were written with the intent of improving the operational aspects = of the IETF drafts. Comments that are not addressed in last call may be inc= luded in AD reviews during the IESG review. Document editors and WG chairs= should treat these comments just like any other last call comments. This draft defines three new RADIUS attributes to be used when communicatin= g with a RADIUS server to facilitate the configuration or reporting of IP a= nd port ranges used with a network appliance, typically a CGN, where there = is a need to constrain the ports available per customer where IP address sh= aring is in use. The three RADIUS attributes are: IP-Port-Limit-Info - defines the maximum number of ports available IP-Port-Range - the specific range of port numbers available IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device I would consider the document to be "Ready with Issues". I have some general comments, followed by some specific comments. Note that= while I am familiar with RADIUS (from an eduroam context) the draft is not one I wa= s familiar with or followed prior to this review. Thus these comments may hav= e already been addressed. General comments: There are at least two areas in which this document has "creep". One is tha= t it is providing an alternative method to PCP to define port forwarding mappings o= n a device. So there is an open question as to whether PCP should be the method of choi= ce for this function, or whether we wish to create a new way to establish such map= pings. Secondly, two of the new attributes support inclusion of a new TLV, IP-Port= -Local-Id, which allows user/device-specific information to be transmitted via RADIUS,= such as MAC address or VLAN ID. While this is intended to allow differentiation of = users for accounting/identification puposes, in doing so it adds an additional potent= ial privacy concern into a new RADIUS attribute, depending on specific use cases of the= TLV. This is not discussed in the Security Considerations section, but probably = should be. I note the new attributes use a number of IPFIX information elements; has t= he draft considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, whic= h says the "lack of a consistent way to log the data makes it difficult to write t= he collector applications that would receive this data and process it to prese= nt useful information"? This draft is introducing a new method to log such elements; = is this a concern at all? The examples of use cases of the new attributes include both NAT44 devices = and CGNs. The dcoument could state more clearly the address sharing scenarios, perhap= s with a simplified network element diagram for each example, showing the user/host,= CPE/NAT44, and NAT444/CGN? Some additional clarity here would be useful (see also comm= ents below). Also, the term "the user" is used in many places in the document where in p= ractice "the customer's CPE" would be more appropriate. Specific comments: NAT64 is mentioned as a use case at the start, but no example is given late= r in the document. This might add useful value. In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements = in the TLV are 16 bit values, but 32 bits are reserved for the element. Similarly = the NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if = the document stated why these elements are being padded out to 32 bits. In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex= users over a smaller number of shared IPv4 addresses, rather its primary design g= oal is to facilitate access to legacy IPv4 content from IPv6-only networks. Th= e text should be clarified. Also in 4.1.1, do users really have service agreements that state port limi= ts? If they do, I doubt users are aware of them (or care...), and the issue is = beyond the scope of this document. In 4.1.2, I think you mean "block", not "bulk"? And the comment on "randomization" might fit better in the Security Conside= rations section if you discuss privacy there (which is presumably what you mean?) Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram= shows only the NAT44 (presumably in the CPE) and not an ISP CGN. The same happens in 4.1.3; discussion of CGN and NAT44 interchangably, with= out the diagram showing there may (presumably) be mappings to establish at both= the user's CPE and the ISP's CGN. And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also about = a CGN allocating more ports; is that at the NAT44, or at the CGN? (These specific NAT44/CGN comments are examples of the general comment I ma= de earlier.) In Section 5, I found the format of the table with 0 and 0+ a little unintu= itive. -- Tim --_000_AMSPR07MB455AA9F3AF209ACB296D26BD6140AMSPR07MB455eurprd_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi,

I have reviewed this document as part of the Operational directorate's=  ongoing effort to review all IETF do= cuments being processed by the IESG. These comments were written with the intent of improving the operational aspects of the&n= bsp;IETF drafts. Comments that are = not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments = ;just like any other last call comm= ents. 

This draft defines three new RADIUS attributes to be used when&nb= sp;communicating with a RADIUS s= erver to facilitate the configuration or reporting of IP and port rang= es used with a network appliance, typically a CGN, where there is a need to constrain <= /span>the ports available per customer whe= re IP address sharing is in use.

The three RADIUS attributes are:
IP-Port-Limit-Info - defines the maximum number of ports available
IP-Port-Range - the specific range of port numbers available
IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN dev= ice

I would consider the document to be "Ready with Issues".

I have some general comments, followed by some specific comments. Note= that while I
am familiar with RADIUS (from an eduroam context) the draft is not one= I was 
familiar with or followed prior to this review. Thus these comments ma= y have already
been addressed.

General comments:

There are at least two areas in which this document has "creep&qu= ot;. One is that it is 
providing an alternative method to PCP to define port forwarding mappi= ngs on a device.
So there is an open question as to whether PCP should be the method of= choice for
this function, or whether we wish to create a new way to establish suc= h mappings.

Secondly, two of the new attributes support inclusion of a new TLV, IP= -Port-Local-Id,
which allows user/device-specific information to be transmitted via RA= DIUS, such as
MAC address or VLAN ID. While this is intended to allow differentiatio= n of users for
accounting/identification puposes, in doing so it adds an additional p= otential privacy
concern into a new RADIUS attribute, depending on specific use cases o= f the TLV.
This is not discussed in the Security Considerations section, but prob= ably should be.

I note the new attributes use a number of IPFIX information elements; = has the draft
considered its relationship to draft-ietf-behave-ipfix-nat-logging-09,= which says
the "lack of a consistent way to log the data makes it difficult = to write the 
collector applications that would receive this data and process it to = present useful 
information"? This draft is introducing a new method to log such = elements; is this
a concern at all?

The examples of use cases of the new attributes include both NAT44 dev= ices and CGNs. 
The dcoument could state more clearly the address sharing scenarios, p= erhaps with a
simplified network element diagram for each example, showing the user/= host, CPE/NAT44,
and NAT444/CGN? Some additional clarity here would be useful (see also= comments below).
Also, the term "the user" is used in many places in the docu= ment where in practice 
"the customer's CPE" would be more appropriate.


Specific comments:

NAT64 is mentioned as a use case at the start, but no example is given= later in the 
document. This might add useful value.

In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elem= ents in the 
TLV are 16 bit values, but 32 bits are reserved for the element. Simil= arly the 
NatEvent element is 8-bit, but has 32 bits reserved. It would be usefu= l if the
document stated why these elements are being padded out to 32 bits.&nb= sp;

In Section 4.1.1, I don't think NAT64 is specifically designed to mult= iplex users
over a smaller number of shared IPv4 addresses, rather its primary des= ign goal
is to facilitate access to legacy IPv4 content from IPv6-only networks= .  The
text should be clarified.

Also in 4.1.1, do users really have service agreements that state port= limits?
If they do, I doubt users are aware of them (or care...), and the issu= e is beyond
the scope of this document. 

In 4.1.2, I think you mean "block", not "bulk"? &n= bsp;
And the comment on "randomization" might fit better in the S= ecurity Considerations
section if you discuss privacy there (which is presumably what you mea= n?)

Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow di= agram shows
only the NAT44 (presumably in the CPE) and not an ISP CGN. 

The same happens in 4.1.3; discussion of CGN and NAT44 interchangably,= without
the diagram showing there may (presumably) be mappings to establish at= both the 
user's CPE and the ISP's CGN.

And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also a= bout a CGN
allocating more ports; is that at the NAT44, or at the CGN?

(These specific NAT44/CGN comments are examples of the general comment= I made earlier.)

In Section 5, I found the format of the table with 0 and 0+ a litt= le unintuitive.

--
Tim

--_000_AMSPR07MB455AA9F3AF209ACB296D26BD6140AMSPR07MB455eurprd_-- From nobody Wed Aug 17 03:22:55 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2FCB512D5FF; Wed, 17 Aug 2016 03:22:54 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0620F12B036 for ; Wed, 17 Aug 2016 03:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.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 fQ3tvj0DyP97 for ; Wed, 17 Aug 2016 03:22:51 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6256212D600 for ; Wed, 17 Aug 2016 03:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2q0HucprS4uYdc+WAi8tLdtJuvS+Y9d0x5lu0lbK+0M=; b=amrqQuXaDzCHg9UWECdL3/1ZTLPN9YI8creRIpC6cDIIIJjTmZBT8ErennQwPW+o1BKYJDZgknC3gIsiIpzS1HtFCLJ1n8gqlObtDlXd2b7L45sKvpymtEvZJsGNOkWJl+bg87EWqZ5Dps/05q2myiFfgrgkR5DSD6BUtiIl5vo= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0050.outbound.protection.outlook.com [213.199.154.50]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-47-jWKzTpgpP1WpUyIvONQDjA-1; Wed, 17 Aug 2016 11:22:47 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 17 Aug 2016 10:22:44 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0549.023; Wed, 17 Aug 2016 10:22:45 +0000 From: Tim Chown To: "ops-dir@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Thread-Index: AQHR+HEowS7Op1qTZUSXToLnElhR2Q== Date: Wed, 17 Aug 2016 10:22:45 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 48fa3172-a363-4440-1a53-08d3c6886e36 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:DsvC0poe53swNaKLNS6WXLe9Li5P67CaKq20bOGOXQ2pzoaFxfhHMFlc4mf/Vez/lltU/1clLn3RdbEQ+q71fdDBbiHpc4nkJBCQofpsgSIGP6FiyGeS5XgJNa0Ik4nYiGb8CB1sx9gccDLi5i/XZ55wrSQNR9kXzaY0PaUHt74= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(192374486261705)(131327999870524)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0037FD6480 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(97736004)(3660700001)(54356999)(5001770100001)(2900100001)(450100001)(105586002)(2501003)(2906002)(76576001)(6116002)(586003)(81156014)(68736007)(5002640100001)(107886002)(19625215002)(77096005)(50986999)(8936002)(74316002)(7696003)(106116001)(101416001)(3846002)(230783001)(74482002)(87936001)(229853001)(8676002)(86362001)(106356001)(189998001)(9686002)(102836003)(7846002)(16236675004)(66066001)(122556002)(10400500002)(81166006)(3280700002)(92566002)(7736002)(33656002)(19627405001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2016 10:22:45.4481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: jWKzTpgpP1WpUyIvONQDjA-1 Content-Type: multipart/alternative; boundary="_000_AMSPR07MB4557B288F324D4DAA4E0D4CD6140AMSPR07MB455eurprd_" Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160817102254.2FCB512D5FF@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 03:22:54 -0700 (PDT) Archived-At: Subject: [radext] OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:22:54 -0000 --_000_AMSPR07MB4557B288F324D4DAA4E0D4CD6140AMSPR07MB455eurprd_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. T= hese comments were written with the intent of improving the operational aspects = of the IETF drafts. Comments that are not addressed in last call may be included i= n AD reviews during the IESG review. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft defines three new RADIUS attributes to be used when communicatin= g with a RADIUS server to facilitate the configuration or reporting of IP and port r= anges used with a network appliance, typically a CGN, where there is a need to constra= in the ports available per customer where IP address sharing is in use. The three RADIUS attributes are: IP-Port-Limit-Info - defines the maximum number of ports available IP-Port-Range - the specific range of port numbers available IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device I would consider the document to be "Ready with Issues". I have some general comments, followed by some specific comments. Note that= while I am familiar with RADIUS (from an eduroam context) the draft is not one I wa= s familiar with or followed prior to this review. Thus these comments may hav= e already been addressed. General comments: There are at least two areas in which this document has "creep". One is tha= t it is providing an alternative method to PCP to define port forwarding mappings o= n a device. So there is an open question as to whether PCP should be the method of choi= ce for this function, or whether we wish to create a new way to establish such map= pings. Secondly, two of the new attributes support inclusion of a new TLV, IP-Port= -Local-Id, which allows user/device-specific information to be transmitted via RADIUS,= such as MAC address or VLAN ID. While this is intended to allow differentiation of = users for accounting/identification r, in doing so it adds an additional potential pr= ivacy concern into a new RADIUS attribute, depending on specific use cases of the= TLV. This is not discussed in the Security Considerations section, but probably = should be. I note the new attributes use a number of IPFIX information elements; has t= he draft considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, whic= h says the "lack of a consistent way to log the data makes it difficult to write t= he collector applications that would receive this data and process it to prese= nt useful information"? This draft is introducing a new method to log such elements; = is this a concern at all? The examples of use cases of the new attributes include both NAT44 devices = and CGNs. The document could state more clearly the address sharing scenarios, perhap= s with a simplified network element diagram for each example, showing the user/host,= CPE/NAT44, and NAT444/CGN? Some additional clarity here would be useful (see also comm= ents below). Also, the term "the user" is used in many places in the document where in p= ractice "the customer's CPE" would be more appropriate. Specific comments: NAT64 is mentioned as a use case at the start, but no example is given late= r in the document. This might add useful value. In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements = in the TLV are 16 bit values, but 32 bits are reserved for the element. Similarly = the NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if = the document stated why these elements are being padded out to 32 bits. In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex= users over a smaller number of shared IPv4 addresses, rather its primary design g= oal is to facilitate access to legacy IPv4 content from IPv6-only networks. Th= e text should be clarified. Also in 4.1.1, do users really have service agreements that state port limi= ts? If they do, I doubt users are aware of them (or care...), and the issue is = beyond the scope of this document. In 4.1.2, I think you mean "block", not "bulk"? And the comment on "randomization" might fit better in the Security Conside= rations section if you discuss privacy there (which is presumably what you mean?) Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram= shows only the NAT44 (presumably in the CPE) and not an ISP CGN. The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably, wit= hout the diagram showing there may (presumably) be mappings to establish at both= the user's CPE and the ISP's CGN. And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also about = a CGN allocating more ports; is that at the NAT44, or at the CGN? (These specific NAT44/CGN comments are examples of the general comment I ma= de earlier.) In Section 5, I found the format of the table with 0 and 0+ a little unintu= itive. -- Tim --_000_AMSPR07MB4557B288F324D4DAA4E0D4CD6140AMSPR07MB455eurprd_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi,

I have reviewed this document as part of the Operational directorate's=  
ongoing effort to review all IETF documents being processed by the IES= G.  These 
comments were written with the intent of improving the operational asp= ects of the 
IETF drafts. Comments that are not addressed in last call may be inclu= ded in AD reviews 
during the IESG review.  Document editors and WG chairs should tr= eat these comments 
just like any other last call comments. 

This draft defines three new RADIUS attributes to be used when communi= cating with a 
RADIUS server to facilitate the configuration or reporting of IP and p= ort ranges used 
with a network appliance, typically a CGN, where there is a need to co= nstrain 
the ports available per customer where IP address sharing is in use.

The three RADIUS attributes are:
IP-Port-Limit-Info - defines the maximum number of ports available
IP-Port-Range - the specific range of port numbers available
IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN dev= ice

I would consider the document to be "Ready with Issues".

I have some general comments, followed by some specific comments. Note= that while I
am familiar with RADIUS (from an eduroam context) the draft is not one= I was 
familiar with or followed prior to this review. Thus these comments ma= y have already
been addressed.

General comments:

There are at least two areas in which this document has "creep&qu= ot;. One is that it is 
providing an alternative method to PCP to define port forwarding mappi= ngs on a device.
So there is an open question as to whether PCP should be the method of= choice for
this function, or whether we wish to create a new way to establish suc= h mappings.

Secondly, two of the new attributes support inclusion of a new TLV, IP= -Port-Local-Id,
which allows user/device-specific information to be transmitted via RA= DIUS, such as
MAC address or VLAN ID. While this is intended to allow differentiatio= n of users for
accounting/identification r, in doing so it adds an additional potenti= al privacy
concern into a new RADIUS attribute, depending on specific use cases o= f the TLV.
This is not discussed in the Security Considerations section, but prob= ably should be.

I note the new attributes use a number of IPFIX information elements; = has the draft
considered its relationship to draft-ietf-behave-ipfix-nat-logging-09,= which says
the "lack of a consistent way to log the data makes it difficult = to write the 
collector applications that would receive this data and process it to = present useful 
information"? This draft is introducing a new method to log such = elements; is this
a concern at all?

The examples of use cases of the new attributes include both NAT44 dev= ices and CGNs. 
The document could state more clearly the address sharing scenarios, p= erhaps with a
simplified network element diagram for each example, showing the user/= host, CPE/NAT44,
and NAT444/CGN? Some additional clarity here would be useful (see also= comments below).
Also, the term "the user" is used in many places in the docu= ment where in practice 
"the customer's CPE" would be more appropriate.


Specific comments:

NAT64 is mentioned as a use case at the start, but no example is given= later in the 
document. This might add useful value.

In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elem= ents in the 
TLV are 16 bit values, but 32 bits are reserved for the element. Simil= arly the 
NatEvent element is 8-bit, but has 32 bits reserved. It would be usefu= l if the
document stated why these elements are being padded out to 32 bits.&nb= sp;

In Section 4.1.1, I don't think NAT64 is specifically designed to mult= iplex users
over a smaller number of shared IPv4 addresses, rather its primary des= ign goal
is to facilitate access to legacy IPv4 content from IPv6-only networks= .  The
text should be clarified.

Also in 4.1.1, do users really have service agreements that state port= limits?
If they do, I doubt users are aware of them (or care...), and the issu= e is beyond
the scope of this document. 

In 4.1.2, I think you mean "block", not "bulk"? &n= bsp;
And the comment on "randomization" might fit better in the S= ecurity Considerations
section if you discuss privacy there (which is presumably what you mea= n?)

Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow di= agram shows
only the NAT44 (presumably in the CPE) and not an ISP CGN. 

The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably= , without
the diagram showing there may (presumably) be mappings to establish at= both the 
user's CPE and the ISP's CGN.

And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also a= bout a CGN
allocating more ports; is that at the NAT44, or at the CGN?

(These specific NAT44/CGN comments are examples of the general comment= I made earlier.)

In Section 5, I found the format of the table with 0 and 0+ a litt= le unintuitive.

--

Tim

--_000_AMSPR07MB4557B288F324D4DAA4E0D4CD6140AMSPR07MB455eurprd_-- From nobody Wed Aug 17 03:33:12 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E53D912D5C9; Wed, 17 Aug 2016 03:33:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147142998489.12148.6490079841130815737.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 03:33:04 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Alexey Melnikov's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:33:07 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Maybe it is just me, but I found that the idea that most subattributes are the same size, but right aligned to be wasteful. Is this a common design pattern for Radius? I am agreeing with Alissa on privacy concerns. On page 12: IP-Port-Int-IPv6-Addr TLV This TLV contains an IPv4 address that is associated with the Typo: should be IPv6? internal IP port number contained in the IP-Port-Int-Port TLV. For IPv6 network, either this TLV or IP-Port-Local-Id TLV must be included as part of the IP-Port-Forwarding-Map Attribute. Refer to Section 3.2.5. From nobody Wed Aug 17 07:04:06 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D5612DB09; Wed, 17 Aug 2016 07:04:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 07:04:04 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:04:04 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I fully support Alissa's discussion points and have two more to add: 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very future-proof: there are other transport protocols that have ports or identifiers that may want to be supported in future. Also it is not clear to me from the document why this information is needed at all in the described use cases. Therefore I see two possible ways forward: Either remove the IP-Port-Type TLV or extend it to also cover other cases. Related to this point I would like to mention that RFC6887 is not restricted to UDP/TCP and therefore the following sentence in section 2 is not correct: "Note that the definitions of [...] "internal port", [...] "external port" [...] are the same as defined in Port Control Protocol (PCP) [RFC6887]" 2) The IE doctors have provide feedback to IANA that the Information Elements in this doc are underspecified (not confirm with rules in RFC 7013) and should therefore be not registered. Addressing this feedback could lead to a mayor rewrite of this doc, especially in the relation to the use and definition of transportType and receptively IP-Port-Type TLV, and should therefore be done before a final IESG decision. From nobody Wed Aug 17 07:54:05 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0947B12DA06; Wed, 17 Aug 2016 07:53:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147144563898.12274.12472874820930623736.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 07:53:58 -0700 Archived-At: Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Alexey Melnikov's Yes on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:53:59 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-radext-datatypes-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this is a very useful document, thank you for writing it. Some comments: In 3.4: ABNF needs an informative reference to RFC 5234. In 3.16: there is a reference to Section 2.13. There is no such section in the document. Did you mean 3.15? In 4.1: does the "value" even need to be in the IANA registry, considering that it never appears on the wire? In 4.2: I would recommend that you instruct RFC Editor to remove the CSV content, as it is not useful long term. So basically IANA can use the data, then the section can be shortened. From nobody Wed Aug 17 07:55:46 2016 Return-Path: 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 8E2BA12DF60; Wed, 17 Aug 2016 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 OWge4NBcCryU; Wed, 17 Aug 2016 07:55:44 -0700 (PDT) Received: from mail-ua0-x243.google.com (mail-ua0-x243.google.com [IPv6:2607:f8b0:400c:c08::243]) (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 C991512DF6B; Wed, 17 Aug 2016 07:55:35 -0700 (PDT) Received: by mail-ua0-x243.google.com with SMTP id 74so10489718uau.3; Wed, 17 Aug 2016 07:55:35 -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:content-transfer-encoding; bh=eoCqsvM4ZU7hM27TXvT3ZDAy8Nf3wgQwsNgKMBOFtug=; b=wWsHblfPXjAMhVYQBXsKUOX3SEiqWWN5MfKDHHRFBhePiPHLZvSQCkbk5xS8FiUXnx gXOa2wUCAOYcA43dvsLRgvL57KD5zPJWpgXyydWk7VlbscpIvaVUvDHdz8ABn9UjIS1O QIJEv0Fw6Tvgjc/wdl1JUMFXBTQ4PZTxeQO/Pn/Fxe2e/jcyZjQQzUSc4FLvDHJ/BeOq zeJVdTZ4Fxi28FdrDK22EJ4hQzxA+cQWiMba2sinQ6QHbeznh5f/zQ7QwRF/QqpZ5WPv cv56iFl08+Qysy4NZ/tXIssdkkhqJofsf+MPVFLwxZIxBMG6vkmKTNMPbiAUaneCpCip B0Sg== 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:content-transfer-encoding; bh=eoCqsvM4ZU7hM27TXvT3ZDAy8Nf3wgQwsNgKMBOFtug=; b=fSNOrEl7ZaZRpa6S4kOsy5OZg0XLaIqAdNZyqUKqiaBX4hAFSa+Nr6eP1yMuKAOax6 d2dNBMSJP5ZKux0TDLxTbf19UCTqa1JfB7oM2jhvUSuJc5D2OVNTSHwuTu5K7No90aWC fDcrJl5T8ny7y7LaEVP31Q/fUywR9kB0R/axoW8mKvfmP6wsYhh4ktAMlrRolCRTB06K 3924/Dvt0C5DBDxQnMrxkav9479N46OLKnfS3x3NC26j62Dy7+KapKCYs9yGevcpIUYI fDO2tRrTk/aSMcO1mL+RI58pDzPOR6zfnQs8tIk+RsKDAG6CYS0lxk5fqZYvsfIpkWQx T4dw== X-Gm-Message-State: AEkoouvnY7WUQ0zfTMhyP2j9Q+chzQWXO2kuc2kiFRPsjBkxMSgDjEQDC4RH7xYNJOjGsCTnIs0ehOA1a/M6Fw== X-Received: by 10.176.1.67 with SMTP id 61mr15868875uak.99.1471445734891; Wed, 17 Aug 2016 07:55:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 17 Aug 2016 07:55:34 -0700 (PDT) In-Reply-To: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 17 Aug 2016 10:55:34 -0400 Message-ID: To: Mirja Kuehlewind Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , The IESG , "" Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:55:45 -0000 Hi Mirja, Hopefully the editors will chime in soon. One question... On Wed, Aug 17, 2016 at 10:04 AM, Mirja Kuehlewind wr= ote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-radext-ip-port-radius-ext-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I fully support Alissa's discussion points and have two more to add: > > 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very > future-proof: there are other transport protocols that have ports or > identifiers that may want to be supported in future. Also it is not clear > to me from the document why this information is needed at all in the > described use cases. Therefore I see two possible ways forward: Either > remove the IP-Port-Type TLV or extend it to also cover other cases. I don't see why this needs to be future proofed as it is meeting a current need and the other protocols may not be using RADIUS. If they do, an update to this document could easily fix that, while keeping the document in line with current use cases. I'm fine with any of these 3 responses depending on what the working group thinks is best. > > Related to this point I would like to mention that RFC6887 is not > restricted to UDP/TCP and therefore the following sentence in section 2 > is not correct: > "Note that the definitions of [...] "internal port", [...] "external > port" [...] are the same as defined in Port Control Protocol (PCP) > [RFC6887]" > > 2) The IE doctors have provide feedback to IANA that the Information > Elements in this doc are underspecified (not confirm with rules in RFC > 7013) and should therefore be not registered. Addressing this feedback > could lead to a mayor rewrite of this doc, especially in the relation to > the use and definition of transportType and receptively IP-Port-Type TLV, > and should therefore be done before a final IESG decision. If you see the end of the message that went out from IANA, the WG might be a little confused on order here. I agree that the WG needs to address these questions from IANA and it should be done prior to tomorrow's telechat. The IANA state shows that an update was posted and a review is needed. It would be helpful for the IESG to see the full discussion if any more has happened outside of the emails from August 11th. Thanks, Kathleen > > > > --=20 Best regards, Kathleen From nobody Wed Aug 17 08:31:19 2016 Return-Path: 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 9B74C12DA09 for ; Wed, 17 Aug 2016 08:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Gtu4IsfQDKxO for ; Wed, 17 Aug 2016 08:31:11 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F223A12DA1F for ; Wed, 17 Aug 2016 08:31:10 -0700 (PDT) Received: (qmail 23836 invoked from network); 17 Aug 2016 17:24:28 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 17 Aug 2016 17:24:28 +0200 To: Kathleen Moriarty References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <57B4816E.3030807@kuehlewind.net> Date: Wed, 17 Aug 2016 17:23:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , The IESG , "" Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 15:31:12 -0000 Hi Kathleen, see below. On 17.08.2016 16:55, Kathleen Moriarty wrote: > Hi Mirja, > > Hopefully the editors will chime in soon. One question... > > On Wed, Aug 17, 2016 at 10:04 AM, Mirja Kuehlewind wrote: >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-radext-ip-port-radius-ext-11: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I fully support Alissa's discussion points and have two more to add: >> >> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very >> future-proof: there are other transport protocols that have ports or >> identifiers that may want to be supported in future. Also it is not clear >> to me from the document why this information is needed at all in the >> described use cases. Therefore I see two possible ways forward: Either >> remove the IP-Port-Type TLV or extend it to also cover other cases. > > I don't see why this needs to be future proofed as it is meeting a > current need and the other protocols may not be using RADIUS. If they > do, an update to this document could easily fix that, while keeping > the document in line with current use cases. I'm fine with any of > these 3 responses depending on what the working group thinks is best. I don't think RADIUS is specified in a way that would only allow it to be used for UDP and TCP transmissions. At least PCP is not; see my next paragraph in the discuss below. Further, I don't see a reason for any restrictions here. However, my other question is also why is this information needed at all. The use cases in this doc gives no explanation why this is needed and what this information is used for. If there is no concrete reason to have this information, it should be removed. > >> >> Related to this point I would like to mention that RFC6887 is not >> restricted to UDP/TCP and therefore the following sentence in section 2 >> is not correct: >> "Note that the definitions of [...] "internal port", [...] "external >> port" [...] are the same as defined in Port Control Protocol (PCP) >> [RFC6887]" >> >> 2) The IE doctors have provide feedback to IANA that the Information >> Elements in this doc are underspecified (not confirm with rules in RFC >> 7013) and should therefore be not registered. Addressing this feedback >> could lead to a mayor rewrite of this doc, especially in the relation to >> the use and definition of transportType and receptively IP-Port-Type TLV, >> and should therefore be done before a final IESG decision. > > If you see the end of the message that went out from IANA, the WG > might be a little confused on order here. I agree that the WG needs > to address these questions from IANA and it should be done prior to > tomorrow's telechat. The IANA state shows that an update was posted > and a review is needed. It would be helpful for the IESG to see the > full discussion if any more has happened outside of the emails from > August 11th. I replied to this on the other email. I was not talking about the IANA review but the expert review that IANA already requested. This review goes back to IANA (and Brian confirmed that they have send it) and IANA should forward it to the authors. My whole (other) emails was about the fact that this communication is not visible to anybody and I just know about it because I happen to talked to Brian. For this document this is actually important because the feedback says that the IEs in this doc are underspecified and cannot be registered as they are. There is more detailed feedback but my high level summary would be that the underspecification could lead to larger changes. I guess we could ask Brian or IANA to forward this feedback to the IESG list to have a more informed discussion here. Mirja > > Thanks, > Kathleen > >> >> >> >> > > > From nobody Wed Aug 17 08:39:34 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A012012D67B; Wed, 17 Aug 2016 08:39:25 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C53012D876; Wed, 17 Aug 2016 08:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 q9DQB4Wfa344; Wed, 17 Aug 2016 08:39:23 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 2A6D912D67B; Wed, 17 Aug 2016 08:39:23 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id k90so177505376uak.1; Wed, 17 Aug 2016 08:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=khKqjiun05EKiDg2vXogtJ3mQqfxgTiQiMIiHC1IZOg=; b=ozU6fZybucyPO26ECvorjWXDXXay4/AWVjXqIn8GEksCN2GrjwLA12gikm5lvnHTbJ D4I5FfsOBPkLB03u2ZIQIQqIn+EGb8IVAS7cuS+k7p0sXgU1IudqdbGIdCDqXg0n897l h0jIEprxl2V25nlfcpjp62HGq+yosebWXjX3nMXGhxLUNgm4VHAZIbEJX2lAA34eHrrb un40makhumFU0MIj/NcsyWbR/C5MyNGi8K/bkaMpGG+V06w6YoIrlyWzRIBYfVhFM6pn YN1NEkHZdpFoMY39SwyaF4QC83qiMKjNOY70/xGtKSw4JOc1XPMgXz+CodmwRLiMgMkI Tu1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=khKqjiun05EKiDg2vXogtJ3mQqfxgTiQiMIiHC1IZOg=; b=jJ4RTVLA61jauzaaGYiJvJSu3N9y9juyliGv2+veSaEjxn1H1Ky34kzT5F9Qifaefl TyLw9G8KXtJ/Y8tQfneTplCSQB+9yL/bcbW+c03FtZcSrrBfXACEwAMAgQStscA3JPS1 B70UdruHSSbERlgEM3w7MuvAat6RVdXLrFmYbQS2QEXkZkw4ORvwiFOtR0GNFKmR/9Le 72mAzi+SvSwqb1zcy1NuEciZpOGDCucC/3hIaekd7+c9AAeCpFuod85nodKt2NCvZz1S /+jNXqdzdGSLKTh40sYwNCFDuT1z2dfKCtH380yT6x3ofvvCJHn8svqCNT3rlid1tJmJ 1Hhw== X-Gm-Message-State: AEkoouvPGBYLBIYv9qMpjGqdhn8UlD3VsOFRNOJVp9cQ3hf5S7cj6bYQM9Ecgr5i/nUDj6mVmHmbG+83Zhlu7Q== X-Received: by 10.176.1.67 with SMTP id 61mr15985563uak.99.1471448362249; Wed, 17 Aug 2016 08:39:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 17 Aug 2016 08:39:21 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 17 Aug 2016 11:39:21 -0400 Message-ID: To: Dean cheng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160817153925.A012012D67B@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 08:39:25 -0700 (PDT) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" , "iesg@ietf.org" , "drafts-lastcall-comment@iana.org" , "lionel.morand@orange.com" Subject: Re: [radext] [IANA #920427] Last Call: (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 15:39:26 -0000 Hello Dean, Could you please assist with the response? IANA - Could you please send the IE doctors review so we have the full text? A question was raised by one of the ADs who spoke with one of the iE doctors and I'd like to make sure the WG addresses the full set of concerns. Thank you, Kathleen On Thu, Aug 11, 2016 at 10:21 AM, Dean cheng wrote: > Hi Lionel, > > > > Sorry but I wasn't aware of that. > > > > Regards > > Dean > > > > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Thursday, August 11, 2016 1:32 AM > To: Dean cheng; drafts-lastcall-comment@iana.org > Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org > Subject: RE : RE: [IANA #920427] Last Call: > (RADIUS Extensions for IP P= ort > Configuration and Reporting) to Proposed Standard > > > > Hi Dean, > > Thank you for the update. However, it is recommended to answer first to t= he > questions (form IANA or others) before updating the draft. It would avoid > too many iterations. And it will allow to check if the proposed answers a= re > correct/acceptable. > > Regards, > > Lionel > > Le 11 ao=C3=BBt 2016 03:43, Dean cheng a =C3=A9cr= it : > > Hi Sabrina, > > Thank you for the review and comments. > We've just uploaded a new revision (11.txt) > that intends to resolve IANA questions as > follows: > >> IANA Question --> for each of these three registrations, could the >> authors please supply the data type semantics and the units to be >> registered with these values? > > Regards > Dean > >> -----Original Message----- >> From: Sabrina Tanamal via RT [mailto:drafts-lastcall-comment@iana.org] >> Sent: Wednesday, August 10, 2016 3:01 PM >> Cc: iesg@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org >> Subject: [IANA #920427] Last Call: > ext-10.txt> (RADIUS Extensions for IP Port Configuration and Reporting) >> to Proposed Standard >> >> (BEGIN IANA COMMENTS) >> >> IESG/Authors/WG Chairs: >> >> IANA has completed its review of draft-ietf-radext-ip-port-radius-ext- >> 10.txt. If any part of this review is inaccurate, please let us know. >> >> IANA has a question about one of the actions requested in the IANA >> Considerations section of this document. >> >> IANA understands that, upon approval of this document, there are three >> actions which IANA must complete. >> >> First, in the IPFIX Information Elements subregistry of the IP Flow >> Information Export (IPFIX) Entities registry located at: >> >> https://www.iana.org/assignments/ipfix/ >> >> three new information elements are to be registered as follows: >> >> ElementID: [ TBD-at-registration ] >> Name: transportType >> Data Type: unsigned8 >> Data Type Semantics: >> Status: current >> Description: The value indicates TCP/UDP ports and ICMP Identifiers (1), >> TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5). >> Units: >> Range: >> References: [ RFC-to-be ] >> >> ElementID: [ TBD-at-registration ] >> Name: natTransportLimit >> Data Type: unsigned16 >> Data Type Semantics: >> Status: current >> Description: The value is the max number of IP transport ports to be >> assigned to an end user associated with one or more IPv4 addresses. >> Units: >> Range: >> References: [ RFC-to-be ] >> >> ElementID: [ TBD-at-registration ] >> Name: localID >> Data Type: string >> Data Type Semantics: >> Status: current >> Description: The value is an IPv4 or IPv6 address, a MAC address, a >> VLAN ID, etc. >> Units: >> Range: >> References: [ RFC-to-be ] >> >> IANA Question --> for each of these three registrations, could the >> authors please supply the data type semantics and the units to be >> registered with these values? >> >> As this document requests registrations in an Expert Review or >> Specification Required (see RFC 5226) registry, we will initiate the >> required Expert Review via a separate request. Expert review will need >> to be completed before your document can be approved for publication as >> an RFC. >> >> Second, in the Radius Attribute Types subregistry of the Radius Types >> registry located at: >> >> http://www.iana.org/assignments/ >> >> three new Radius attribute types are to be registered under the 241 >> Extended-Attribute-1 type as follows: >> >> Value: 241.[ TBD-at-registration ] >> Description: IP-Port-Limit-Info >> Reference: [ RFC-to-be ] >> >> Value: 241.[ TBD-at-registration ] >> Description: IP-Port-Range >> Reference: [ RFC-to-be ] >> >> Value: 241.[ TBD-at-registration ] >> Description: IP-Port-Forwarding-Map >> Reference: [ RFC-to-be ] >> >> Third, IANA notes that the authors request: >> >> This specification requests allocation of the following TLVs: >> Name Value Meaning >> ---- ----- ------- >> IP-Port-Type 1 see Section 3.2.1 >> IP-Port-Limit 2 see Section 3.2.2 >> IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 IP-Port-Int-IPv4-Addr 4 see >> Section 3.2.4 IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 IP-Port-Int- >> Port 6 see Section 3.2.6 IP-Port-Ext-Port 7 see Section 3.2.7 IP-Port- >> Alloc 8 see Section 3.2.8 IP-Port-Range-Start 9 see Section 3.2.9 IP- >> Port-Range-End 10 see Section 3.2.10 IP-Port-Local-Id 11 see Section >> 3.2.11 >> >> IANA Question --> Specifically, in what registry are these new TLVs to >> be registered? >> >> IANA understands that the three actions above are the only ones >> required to be completed upon approval of this document. >> >> Note: The actions requested in this document will not be completed >> until the document has been approved for publication as an RFC. This >> message is only to confirm what actions will be performed. >> >> >> Thank you, >> >> Sabrina Tanamal >> IANA Specialist >> ICANN >> >> (END IANA COMMENTS) > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > > Thank you. --=20 Best regards, Kathleen From nobody Wed Aug 17 08:42:57 2016 Return-Path: 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 4111712D56F; Wed, 17 Aug 2016 08:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 gaj45rvSCyLk; Wed, 17 Aug 2016 08:42:47 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 5DE4412B026; Wed, 17 Aug 2016 08:42:47 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id k90so177655523uak.1; Wed, 17 Aug 2016 08:42:47 -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:content-transfer-encoding; bh=h6B1bQIvn3or0kltkIo/DKu5Xo38XUaHTCF99UcwVp8=; b=rTw32H8uYddBFLO+tW0GDiBEJRRgtcfoAim0MKPz8SPWsduP06JVlU4Q2PlR8SNyn9 lVojasoNJbzFP8xI3lo7wY/OKFMZZI9ZcPVwE/41lzjnGjPVLhX1WC0L9wCQBYc5jVmp PNcKR5QtBuXS7Oxjgrp0FPzVPn7QjWa2MeNVm2+k9ElI4o+hdfusdV85vaPYQm+peIFZ 3FGoxtzsKBmiw/5Bwroaf8nGL6+YFUKL+7CXjVtKZHpjXIm/4LC9Fdt2SYgJUjmwB48g 2Z0yz6dUBMYZyGuc6OLQFfORUvTqcNcaZka9VTBhc4YJDFlmxpUEm3jp8wCRXWQCcGLL 3tQw== 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:content-transfer-encoding; bh=h6B1bQIvn3or0kltkIo/DKu5Xo38XUaHTCF99UcwVp8=; b=QPh6Hj4OeKezkDgZBtChsTJhnuMcHtHOJOqqZUXuWmaoC6Djgu6QAo4yD/UORnXLva PMWIYQ2z9+YpTIfrz/oHbQiZmWxHD4kmWHW52+Ah4mAUsDxVj/XSg3Ttqa2QNzoOkl3V JfATRcCTuYkL7uWLq1dA+NY7qbj/YWAOWWXO1fDACbOwQc6qk7Er+jHe1SEFmKgCwgsR Aoy9Wa7XPEmz+oyzAvM4/uKWI3Jn8ootK0hlB5TbrE9PQ4avCEZW+8yhpIbBad4OB/0O ZV/EiYa7PiVmvFqG/pbQ5qh6f26lhfMLYrsaMZheGNCy6thT+yxo5agf9qX8WG5pzZkg LwtQ== X-Gm-Message-State: AEkoouvXL+xsS4e/nsJzuF2MBnMFfZgKoS0tDUvxytJGCAEGQkeWQ+w2lamzDYUfN90bc5r/MwRtBMpHF2pWFA== X-Received: by 10.31.80.196 with SMTP id e187mr19513461vkb.29.1471448566391; Wed, 17 Aug 2016 08:42:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 17 Aug 2016 08:42:45 -0700 (PDT) In-Reply-To: <57B4816E.3030807@kuehlewind.net> References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <57B4816E.3030807@kuehlewind.net> From: Kathleen Moriarty Date: Wed, 17 Aug 2016 11:42:45 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , The IESG , "" Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 15:42:49 -0000 On Wed, Aug 17, 2016 at 11:23 AM, Mirja K=C3=BChlewind wrote: > Hi Kathleen, > > see below. > > > On 17.08.2016 16:55, Kathleen Moriarty wrote: >> >> Hi Mirja, >> >> Hopefully the editors will chime in soon. One question... >> >> On Wed, Aug 17, 2016 at 10:04 AM, Mirja Kuehlewind >> wrote: >>> >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I fully support Alissa's discussion points and have two more to add: >>> >>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very >>> future-proof: there are other transport protocols that have ports or >>> identifiers that may want to be supported in future. Also it is not cle= ar >>> to me from the document why this information is needed at all in the >>> described use cases. Therefore I see two possible ways forward: Either >>> remove the IP-Port-Type TLV or extend it to also cover other cases. >> >> >> I don't see why this needs to be future proofed as it is meeting a >> current need and the other protocols may not be using RADIUS. If they >> do, an update to this document could easily fix that, while keeping >> the document in line with current use cases. I'm fine with any of >> these 3 responses depending on what the working group thinks is best. > > > I don't think RADIUS is specified in a way that would only allow it to be > used for UDP and TCP transmissions. At least PCP is not; see my next > paragraph in the discuss below. > > Further, I don't see a reason for any restrictions here. However, my othe= r > question is also why is this information needed at all. The use cases in > this doc gives no explanation why this is needed and what this informatio= n > is used for. If there is no concrete reason to have this information, it > should be removed. > I understand your point, let's see what the WG responds with. >> >>> >>> Related to this point I would like to mention that RFC6887 is not >>> restricted to UDP/TCP and therefore the following sentence in section 2 >>> is not correct: >>> "Note that the definitions of [...] "internal port", [...] "external >>> port" [...] are the same as defined in Port Control Protocol (PCP) >>> [RFC6887]" >>> >>> 2) The IE doctors have provide feedback to IANA that the Information >>> Elements in this doc are underspecified (not confirm with rules in RFC >>> 7013) and should therefore be not registered. Addressing this feedback >>> could lead to a mayor rewrite of this doc, especially in the relation t= o >>> the use and definition of transportType and receptively IP-Port-Type TL= V, >>> and should therefore be done before a final IESG decision. >> >> >> If you see the end of the message that went out from IANA, the WG >> might be a little confused on order here. I agree that the WG needs >> to address these questions from IANA and it should be done prior to >> tomorrow's telechat. The IANA state shows that an update was posted >> and a review is needed. It would be helpful for the IESG to see the >> full discussion if any more has happened outside of the emails from >> August 11th. > > > I replied to this on the other email. I was not talking about the IANA > review but the expert review that IANA already requested. This review goe= s > back to IANA (and Brian confirmed that they have send it) and IANA should > forward it to the authors. My whole (other) emails was about the fact tha= t > this communication is not visible to anybody and I just know about it > because I happen to talked to Brian. > > For this document this is actually important because the feedback says th= at > the IEs in this doc are underspecified and cannot be registered as they a= re. > There is more detailed feedback but my high level summary would be that t= he > underspecification could lead to larger changes. > > I guess we could ask Brian or IANA to forward this feedback to the IESG l= ist > to have a more informed discussion here. I think they are normally sent to the draft editors as well, so IANA usually doesn't have to forward them. If Brian did the review and could send it to the draft distribution list (draft---.all@tools.ietf.org), that would be helpful. This is what happens for other reviews. Thank you, Kathleen > > Mirja > > >> >> Thanks, >> Kathleen >> >>> >>> >>> >>> >> >> >> > --=20 Best regards, Kathleen From nobody Wed Aug 17 10:13:48 2016 Return-Path: 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 7878D12D8CF; Wed, 17 Aug 2016 10:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 pjEQmwOBSX2m; Wed, 17 Aug 2016 10:13:39 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 C1A0912D6AF; Wed, 17 Aug 2016 10:13:39 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id i6so8419825pfe.0; Wed, 17 Aug 2016 10:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=e1YXmZLk+av6KmwCjCEjmG0q9zn6iNQgbQ5iSnQ+DwE=; b=AzyhXbof/vQLIBzzZqRfidW+cj0XDIoxrSZBjEZKG5WHS3nrBGnSzvSwEkhajvlsAh q/zmTBpwoG3yvHzCy5BoYHYuHiT8SUFs/0Gix3j/7n5jBzi2vcTvxc9ZsivpxWZkA5qT ZeKKIYS11mD3uyECduYb1S5vVAyQZmnDNc6sG2bThmckN7IGFCp90UKrOXBKl9Q1o/Iw NeWL8CR4KWwvJW3RggjhINldCV1Gvrs63zhTQ+yo4XIw8LxmMCZl6VZkHve7tvNUmlBz hi6OmAAo5F/KTk/sU8nhHLvi4O73ee2jwdOn7bvEVdzJUJTcELyRGxicvmWVGAEDvMF/ VfRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=e1YXmZLk+av6KmwCjCEjmG0q9zn6iNQgbQ5iSnQ+DwE=; b=c/9CDMSRh8ZpwTnV6YE1l9Pa02SE4mzvdSTyKBPzFzYANUzgMkMPAKDO95heORaNsk h0zXIx3qIBAgHYI3uypI/NocHj7rRVBmuGdcxuoCzvcWl/9/CkLI99FD+gZingNZSsFQ O16/52Hli7YTaJhSgryq2KUk/lC7UKdULfF1WS6GmZqLtZ9LbP4D+ZfcS4+f9EFrn84J 2LHZMAY1PcgNGbL+SSW3kFXQa4/a3aNvhvZ4GL+exToRw4/w5uDt7C4d1jZnQFe6Aynj gWgK5BunQYaoT9LD28BNEo9zGm9YGrbvDfhOYUydA9SxnxRETbj1WHwDy2oKEdj8qieh lLZw== X-Gm-Message-State: AEkoouvWTeO7a80+dRTU5X7NNzDTKkfH7gmXsbLGlN3NpUojuR2XF4XxKzdcGiJulTh4dA== X-Received: by 10.98.93.25 with SMTP id r25mr22784973pfb.122.1471454019376; Wed, 17 Aug 2016 10:13:39 -0700 (PDT) Received: from [10.16.66.0] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id i137sm15052376pfe.64.2016.08.17.10.13.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Aug 2016 10:13:38 -0700 (PDT) References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> To: Mirja Kuehlewind , The IESG From: Jouni Korhonen Message-ID: <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> Date: Wed, 17 Aug 2016 10:13:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:13:41 -0000 Hi, Would it be possible to see the IE doctor's feedback? The authors might find it useful as well. If it has been distributed already, my apologies if I missed it. regards, Jouni 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-radext-ip-port-radius-ext-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I fully support Alissa's discussion points and have two more to add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ > > 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very > future-proof: there are other transport protocols that have ports or > identifiers that may want to be supported in future. Also it is not clear > to me from the document why this information is needed at all in the > described use cases. Therefore I see two possible ways forward: Either > remove the IP-Port-Type TLV or extend it to also cover other cases. > > Related to this point I would like to mention that RFC6887 is not > restricted to UDP/TCP and therefore the following sentence in section 2 > is not correct: > "Note that the definitions of [...] "internal port", [...] "external > port" [...] are the same as defined in Port Control Protocol (PCP) > [RFC6887]" > > 2) The IE doctors have provide feedback to IANA that the Information > Elements in this doc are underspecified (not confirm with rules in RFC > 7013) and should therefore be not registered. Addressing this feedback > could lead to a mayor rewrite of this doc, especially in the relation to > the use and definition of transportType and receptively IP-Port-Type TLV, > and should therefore be done before a final IESG decision. > > > > From nobody Wed Aug 17 10:18:36 2016 Return-Path: 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 598E212DB46; Wed, 17 Aug 2016 10:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Omkn8y-4PT-0; Wed, 17 Aug 2016 10:18:32 -0700 (PDT) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 6410E12D505; Wed, 17 Aug 2016 10:18:32 -0700 (PDT) Received: by mail-ua0-x242.google.com with SMTP id d97so11337208uad.1; Wed, 17 Aug 2016 10:18:32 -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:content-transfer-encoding; bh=afoqwR5VxecC/5ESvtcIieZXTWRD46ZEtQIXhj/v1lM=; b=beNdXXsA9RbIyRhDw9X+f0RxH42upQMXYiUAACxNhhYAfWVvroOEV4DxTlq3Civl4z QYZctD6GnULnBTM2ngFFlxQu31u9ln9MWMAhwVyrczipsR9mne32+cgeGgegQuESXM3q BNCEKGpZY0LAyR6Td6r6nUtYnXaRRnOdyY1VHKACRqQMKaXLX2LRQTqaFeCIYPeq6D6X Hcuto9lrpewxjH3JZjsy9p99JQOSovs7hdnwYPZKtb3WD/t30kUhyEeZFFahODfQedKh ob2w3v1uiTgb3bmI8SZ11V6ABPbopdjxn61CTB4bu1PFVjtpN8KcgG5E8CrO3B2Uuudh wlTg== 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:content-transfer-encoding; bh=afoqwR5VxecC/5ESvtcIieZXTWRD46ZEtQIXhj/v1lM=; b=dlOt+hwL6vArnajIxN9XD0Yb2VGqImaFD5czjkRsP1BhI04NJTU003yYuTkMXK9yax NwWEBP+fEjfwEP/KkNVrlTE5RAVHz2K8YBPL/5YTR30f5uAR3vN233RWs1+Y6qLucS+G LjZ48xP7SsnQ1tKz1I4nj/QfB/+I7/IaXJF1yNUKdXB8V9B3GFXRVRJnVTHiHzuZWdp+ OL3U0luVL64qA28N5rc2qfUTmc817VLCySoPKjIxIlSjNX8luKIih9vJXpzcr6nLQeFN 5RC1zNn4ZfK2MPKwB4CmzlNcyYYZIoUO2pM9gR86Yf+OuDxquLdI4EhJpESMchMbnWZt nqPA== X-Gm-Message-State: AEkoousoe5nd9FnJFMR2j7wDNlBLH1Jhoced05BQ23SiWF3XYZx7Ru8r56oK5ClYfh91NG4Ks6qslCtmVkblDg== X-Received: by 10.176.1.67 with SMTP id 61mr16218241uak.99.1471454311515; Wed, 17 Aug 2016 10:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 17 Aug 2016 10:18:31 -0700 (PDT) In-Reply-To: <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> From: Kathleen Moriarty Date: Wed, 17 Aug 2016 13:18:31 -0400 Message-ID: To: Jouni Korhonen , Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, "radext@ietf.org" , "" , Mirja Kuehlewind , The IESG , radext-chairs@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:18:34 -0000 Apparently, Brian did the review. I'm adding him to this thread so he can send the review to the draft distribution list. Thank you, Kathleen On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen wr= ote: > Hi, > > Would it be possible to see the IE doctor's feedback? The authors might f= ind > it useful as well. If it has been distributed already, my apologies if I > missed it. > > regards, > Jouni > > 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti: >> >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-radext-ip-port-radius-ext-11: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I fully support Alissa's discussion points and have two more to >> add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ex= t/ >> >> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very >> future-proof: there are other transport protocols that have ports or >> identifiers that may want to be supported in future. Also it is not clea= r >> to me from the document why this information is needed at all in the >> described use cases. Therefore I see two possible ways forward: Either >> remove the IP-Port-Type TLV or extend it to also cover other cases. >> >> Related to this point I would like to mention that RFC6887 is not >> restricted to UDP/TCP and therefore the following sentence in section 2 >> is not correct: >> "Note that the definitions of [...] "internal port", [...] "external >> port" [...] are the same as defined in Port Control Protocol (PCP) >> [RFC6887]" >> >> 2) The IE doctors have provide feedback to IANA that the Information >> Elements in this doc are underspecified (not confirm with rules in RFC >> 7013) and should therefore be not registered. Addressing this feedback >> could lead to a mayor rewrite of this doc, especially in the relation to >> the use and definition of transportType and receptively IP-Port-Type TLV= , >> and should therefore be done before a final IESG decision. >> >> >> >> > --=20 Best regards, Kathleen From nobody Wed Aug 17 14:38:18 2016 Return-Path: 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 1FAF212D09A; Wed, 17 Aug 2016 14:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 qO4WvvLIUcvf; Wed, 17 Aug 2016 14:38:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270F712D7BB; Wed, 17 Aug 2016 14:38:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 06790B80C07; Wed, 17 Aug 2016 14:38:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160817213805.06790B80C07@rfc-editor.org> Date: Wed, 17 Aug 2016 14:38:05 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 7930 on Larger Packets for RADIUS over TCP X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:38:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7930 Title: Larger Packets for RADIUS over TCP Author: S. Hartman Status: Experimental Stream: IETF Date: August 2016 Mailbox: hartmans-ietf@mit.edu Pages: 10 Characters: 22676 Updates: RFC 6613 I-D Tag: draft-ietf-radext-bigger-packets-07.txt URL: https://www.rfc-editor.org/info/rfc7930 DOI: http://dx.doi.org/10.17487/RFC7930 The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval. This document is a product of the RADIUS EXTensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Aug 17 20:53:55 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43012B00D; Wed, 17 Aug 2016 20:53:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 20:53:51 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 03:53:51 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Why are the the uint8 and unit16 based types getting stuffed into 32 bit fields inside the TLVs? This feels like a complete waste. Is there any specific reason this is required? * Does the IP-Port-Limit include the count of ports already allocated through the IP-Port-Forwarding-Map or not? * I agree with Alissa's DISCUSS points about the lack of error handling and the privacy issues and Mirja's DISCUSS point about restricting transport protocols to TCP and UDP. From nobody Wed Aug 17 22:59:48 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 011F1124281; Wed, 17 Aug 2016 22:59:40 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE18B12D126; Wed, 17 Aug 2016 22:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.447 X-Spam-Level: X-Spam-Status: No, score=-4.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham 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 CFrSANIm90l2; Wed, 17 Aug 2016 22:59:39 -0700 (PDT) Received: from smtp02.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF10124281; Wed, 17 Aug 2016 22:59:39 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp02.icann.org (Postfix) with ESMTP id E883BE339D; Thu, 18 Aug 2016 05:59:38 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id ADB00C20564; Thu, 18 Aug 2016 05:59:38 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <147103594351.14007.4959423908669308356.idtracker@ietfa.amsl.com> References: <147103594351.14007.4959423908669308356.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #923000 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 18 Aug 2016 05:59:38 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160818055941.011F1124281@ietfa.amsl.com> Resent-Date: Wed, 17 Aug 2016 22:59:40 -0700 (PDT) Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org, iesg@ietf.org Subject: [radext] [IANA #923000] Evaluation: to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: drafts-eval@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 05:59:41 -0000 IESG: IANA NOT OK. Comments in tracker IANA Actions - YES Two issues: 1) The IPFIX experts have issues with the registrations in Section 7.1. 2) Section 7.3 requests RADIUS TLV registrations. Which registry does the term "RADIUS TLV" refer to? Is this a new registry being created by another document, or an existing registry that IANA lists under another name? Thank you, Amanda Baber IANA Lead Specialist ICANN From nobody Wed Aug 17 23:05:07 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA4E124281; Wed, 17 Aug 2016 23:05:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147150030562.20420.9450126729953216002.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 23:05:05 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 06:05:05 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Thu Aug 18 00:23:55 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A4F2412D752; Thu, 18 Aug 2016 00:23:47 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6412D74F; Thu, 18 Aug 2016 00:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 Y_0uvQWw2uGq; Thu, 18 Aug 2016 00:23:46 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 04F7F12D0E1; Thu, 18 Aug 2016 00:23:46 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id z190so8951611qkc.0; Thu, 18 Aug 2016 00:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RpjJKrWxs9aZ59AAUdawg26Pyui9ruIajKOIx1jCcDY=; b=K+Acr4uhUImumWIZxtKsK76tiw3PAKAoap025qh6lAzcu5iXqo1XNcpK7XorIVjFH5 rRdP+Rv5GFfju64us6WAudgcTfNi9OFqWecSGCcKsNj5srN9Q1iLOGAA6dpDWDRAju4h /w3BqQMtp0q0mgEyJy58Rg9zxPWAoDx4kZ1x8dOqpxLc/xP/sHvCYeyrHi43rQtHafIm hdWy6rTHtoe0Z7C0u714YgPMcvYqHqsoEj+tibPUeOaR+nbo2y9SEUjX7tfgi6fz1kfQ UglFDBI5diSdcLJyVnyMXDvc4QpZrViQ0WuWyxHAOPj2aZEPXS3hfrLcYEJf4ajcrEqK maCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RpjJKrWxs9aZ59AAUdawg26Pyui9ruIajKOIx1jCcDY=; b=IRfaJgr6G5mbcNb0goU2r4UDG+xw3fTXH7YJ0QnB9vCVNhF8P/tgnOXhvcAS9OxzNl bsy0akmF1e5HmGAYEI4Ou7ou9MnWVL/Ekaomsg4JW/IaUK0WQezh8XOTuRH+5zclTzUv b/FLC0WPjGw+Abm+2yAsGIBxg+DfbnTx5lNgRdY2xeM3sqdOXvrpEaQlc3MW6goSBolG bvaOMPaoeaNiQ/KQC+0ZwpeeZQWQiQTHi4azaFrpGh8efqfK5ja+Ok5tmV94kFn16+iE q+Fx871CicSJkD4LxJIhP+0c6a77g+Txa3rpnrHrq034Zpvd6XkPqV86tAo3TAvys1st ZzqQ== X-Gm-Message-State: AEkoouuprvSa0lmkd8J9JcZ1II1WG+HAV+PM0mXpUZgng+aZ9LIK7CDdypuVlW/m9FbRvg== X-Received: by 10.55.102.75 with SMTP id a72mr772116qkc.20.1471505025197; Thu, 18 Aug 2016 00:23:45 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id v126sm380809qkh.30.2016.08.18.00.23.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Aug 2016 00:23:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Thu, 18 Aug 2016 03:23:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6C84A4B0-AB4E-4BD6-A5F1-117C0ED77C4F@gmail.com> References: <147103594351.14007.4959423908669308356.idtracker@ietfa.amsl.com> To: drafts-eval@iana.org Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160818072347.A4F2412D752@ietfa.amsl.com> Resent-Date: Thu, 18 Aug 2016 00:23:47 -0700 (PDT) Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org, iesg@ietf.org Subject: Re: [radext] [IANA #923000] Evaluation: to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 07:23:48 -0000 Hello, Inline Sent from my iPhone > On Aug 18, 2016, at 1:59 AM, Amanda Baber via RT wr= ote: >=20 > IESG: >=20 > IANA NOT OK. Comments in tracker > IANA Actions - YES >=20 > Two issues: >=20 > 1) The IPFIX experts have issues with the registrations in Section 7.1. Could you please forward their report? It didn't get sent to the draft dist= ribution list, so we don't know what the issues are. Thank you, Kathleen=20 >=20 > 2) Section 7.3 requests RADIUS TLV registrations. Which registry does the t= erm "RADIUS TLV" refer to? Is this a new registry being created by another d= ocument, or an existing registry that IANA lists under another name? >=20 > Thank you, >=20 > Amanda Baber > IANA Lead Specialist > ICANN >=20 From nobody Thu Aug 18 00:34:00 2016 Return-Path: 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 1AA3E12D753; Thu, 18 Aug 2016 00:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 wwh0fA8orGsi; Thu, 18 Aug 2016 00:33:57 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C92BA12D6AE; Thu, 18 Aug 2016 00:33:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 218D5C15; Thu, 18 Aug 2016 07:33:56 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksDHOeQmQG72; Thu, 18 Aug 2016 07:33:56 +0000 (UTC) Received: from [10.192.3.201] (LStLambert-657-1-57-31.w80-13.abo.wanadoo.fr [80.13.34.31]) by mail.networkradius.com (Postfix) with ESMTPSA id AD34AA76; Thu, 18 Aug 2016 07:33:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 09:33:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B2C6F39-6BED-45F1-BEA7-1D099CDDA9D4@deployingradius.com> References: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: radext-chairs@ietf.org, draft-ietf-radext-ip-port-radius-ext@ietf.org, radext@ietf.org, The IESG , "lionel.morand@orange.com" Subject: Re: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 07:33:59 -0000 On Aug 18, 2016, at 5:53 AM, Suresh Krishnan = wrote: > * Why are the the uint8 and unit16 based types getting stuffed into 32 > bit fields inside the TLVs? This feels like a complete waste. Is there > any specific reason this is required? The limited nature of RADIUS data types. This behaviour is mandated = by RFC 6158 https://tools.ietf.org/html/rfc6158#appendix-A.2.1 From nobody Thu Aug 18 01:20:32 2016 Return-Path: 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 F36CF12D0B5; Thu, 18 Aug 2016 01:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 DzZNpHdcGT9U; Thu, 18 Aug 2016 01:20:29 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE0912D0AE; Thu, 18 Aug 2016 01:20:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 63048C0D; Thu, 18 Aug 2016 08:20:28 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYufWLNlSuIO; Thu, 18 Aug 2016 08:20:28 +0000 (UTC) Received: from [10.192.3.201] (LStLambert-657-1-56-254.w80-13.abo.wanadoo.fr [80.13.33.254]) by mail.networkradius.com (Postfix) with ESMTPSA id C35563A6; Thu, 18 Aug 2016 08:20:27 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E680AB02-6887-408C-8E5A-57BA3A9F28C2"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: <147144563898.12274.12472874820930623736.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 10:20:25 +0200 Message-Id: <84038841-D743-4861-85BA-337CEB24D805@freeradius.org> References: <147144563898.12274.12472874820930623736.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Winter Stefan , radext@ietf.org, draft-ietf-radext-datatypes@ietf.org, The IESG , radext-chairs@ietf.org Subject: Re: [radext] Alexey Melnikov's Yes on draft-ietf-radext-datatypes-06: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 08:20:31 -0000 --Apple-Mail=_E680AB02-6887-408C-8E5A-57BA3A9F28C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 17, 2016, at 4:53 PM, Alexey Melnikov = wrote: > In 3.4: ABNF needs an informative reference to RFC 5234. Added. > In 3.16: there is a reference to Section 2.13. There is no such = section > in the document. Did you mean 3.15? Yes, fixed. > In 4.1: does the "value" even need to be in the IANA registry, > considering that it never appears on the wire? The "value" field isn't entirely needed. However, we may need to use = it later, and it's a good way to track / guarantee uniqueness in the = data types. > In 4.2: I would recommend that you instruct RFC Editor to remove the = CSV > content, as it is not useful long term. So basically IANA can use the > data, then the section can be shortened. Done. --Apple-Mail=_E680AB02-6887-408C-8E5A-57BA3A9F28C2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXtW/JAAoJEH0Oec13Yh7N0osH/2dHVHG3AS5nVy+zWX+BO60T T/6apZqCjqU/8+p8pZOFCpNoJAHUeuaF8SZ9Y78L3nazy76XhSqqObZ8B43Qe+14 nnoLcN53EyDO2GdmhU5FTz7MKPEiLnJfTgXngR4Kq5fkaRxpt7AD6na8R1Maps6/ RHRV7N+kGF/7JnmxfMk9KMJ9FShS7s2OnaWT5p35fdNViq6hKdGdXm4VGH9qkLsO d8BEtte1SmT69ZwO3buqGAZAfS7rt6Zk2A3cn7c4C6lcSLwPccJrMckcSfrnIg5y QkAZlakeKVrOZ8ng8DFSna6ozLYS0rNsAc8y/6S713Eo3WspAr8DoQduxTllqnk= =rQu8 -----END PGP SIGNATURE----- --Apple-Mail=_E680AB02-6887-408C-8E5A-57BA3A9F28C2-- From nobody Thu Aug 18 01:42:42 2016 Return-Path: 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 6774112D862; Thu, 18 Aug 2016 01:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Jhm4bD9LZJwW; Thu, 18 Aug 2016 01:42:35 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CA84012B050; Thu, 18 Aug 2016 01:42:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E1613A76; Thu, 18 Aug 2016 08:42:30 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVx_mlDCdQGw; Thu, 18 Aug 2016 08:42:30 +0000 (UTC) Received: from [10.192.3.201] (LStLambert-657-1-56-254.w80-13.abo.wanadoo.fr [80.13.33.254]) by mail.networkradius.com (Postfix) with ESMTPSA id 28BD93A6; Thu, 18 Aug 2016 08:42:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <73dd3044-a877-2ce2-ac27-818abe0ccf0e@restena.lu> Date: Thu, 18 Aug 2016 10:42:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F2A600F-9EAA-44F6-A9AF-F6344A032D3C@deployingradius.com> References: <73dd3044-a877-2ce2-ac27-818abe0ccf0e@restena.lu> To: Winter Stefan , Benoit Claise , joel jaeggli , "lionel.morand@orange.com" , Kathleen.Moriarty.ietf@gmail.com, drafts-lastcall-comment@iana.org, radext@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-radext-datatypes.all@ietf.org, The IESG Subject: Re: [radext] [IANA #921536] Last Call: (Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)) to Proposed Standard X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 08:42:37 -0000 > First, IANA understands that it is to create a new registry called the > RADIUS Data Type registry. the registration procedure for the new > registry is to be Standards Action as defined in RFC5226. There are > three fields in the new registry: Value, Description and Reference. Yes. > IANA QUESTION -> Where should this new registry be located? Is it a = new > registry on the List of all IANA maintained protocol parameter > registries or is it a subregistry of an existing registry? If it is a > subregistry of an existing registry, in which registry will it be = contained? It should be a sub registry of "RADIUS Types". I will update the = draft accordingly. > Second, the RADIUS Attribute Type subregistry of the Radius Types > registry located at: >=20 > https://www.iana.org/assignments/radius-types/ >=20 > is to be updated. IANA understands that the registration rules for the > registry are to remain unchanged. A new column is to be inserted = between > the existing "Description" and "Reference" column and titled: "Data = Type." Yes to all. > Section 4.2 of the current draft provides a listing of a recent = version > of the registry with the Data Type field inserted. That listing is in > CSV format. >=20 > IANA Question --> How would the authors like to fill the Data Type > column for those registrations in the current RADIUS Attribute Type > registry that are not included in Section 4.2 of the current document? I will update this document with any new data types required. I hope = that there are only a small number of new RADIUS Attribute Types = registered... My suggestion is that I will update the document in AUTH48, and = coordinate with IANA to ensure that all RADIUS Attribute Types have a = defined data type, prior to publication of this document. Hmm... Section 2.1.1 notes that new definitions in the RADIUS = Attribute Type MUST specify a data type, but the IANA actions don't have = similar text. I'll fix that by adding some text: IANA is instructed to require that new allocations in the RADIUS Attribute Type registry specify a "Data Type" which references one of = the data types defined in the RADIUS Data Type registry. I think that should be sufficient. > IANA understands that the two actions above are the only ones required > to be completed upon approval of this document. >=20 > Note: The actions requested in this document will not be completed > until the document has been approved for publication as an RFC. This > message is only to confirm what actions will be performed. > Thank you, >=20 > Sabrina Tanamal > IANA Specialist > ICANN >=20 > (END IANA COMMENTS) >=20 > <0x8A39DC66.asc> From nobody Thu Aug 18 03:53:45 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3512D923; Thu, 18 Aug 2016 03:53:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147151762369.21981.3684586229888797054.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 03:53:43 -0700 Archived-At: Cc: radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com, radext-chairs@ietf.org, stefan.winter@restena.lu Subject: [radext] radext - New Meeting Session Request for IETF 97 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 10:53:44 -0000 A new meeting session request has just been submitted by Stefan Winter, a Chair of the radext working group. --------------------------------------------------------- Working Group Name: RADIUS EXTensions Area Name: Operations and Management Area Session Requester: Stefan Winter Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 20 Conflicts to Avoid: First Priority: dime 6man v6ops dmm abfab oauth saag Second Priority: spring sfc rtcweb 6lo ace httpauth mile ipsecme Special Requests: --------------------------------------------------------- From nobody Thu Aug 18 06:21:17 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5B12DE38; Thu, 18 Aug 2016 06:21:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , "The IESG" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147152647155.21989.3852158586365805720.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 06:21:11 -0700 From: IETF Secretariat Archived-At: Subject: [radext] Telechat update notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:21:12 -0000 Telechat date has been changed to 2016-09-15 from 2016-08-18 ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Thu Aug 18 06:49:02 2016 Return-Path: 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 3D85A12D776; Thu, 18 Aug 2016 06:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 yNL08dRUDJIy; Thu, 18 Aug 2016 06:48:52 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8820C12D893; Thu, 18 Aug 2016 06:48:45 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-19-57b5bdad08c7 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 97.D7.02568.DADB5B75; Thu, 18 Aug 2016 15:52:46 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 09:45:06 -0400 From: Suresh Krishnan To: Alan DeKok Thread-Topic: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) Thread-Index: AQHR+QQqdvcLhWKyI0SawtM1sGsq0Q== Date: Thu, 18 Aug 2016 13:45:06 +0000 Message-ID: References: <147149243113.23694.15020227285534665980.idtracker@ietfa.amsl.com> <1B2C6F39-6BED-45F1-BEA7-1D099CDDA9D4@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPrO66vVvDDR5d5LJo+tzEbjFvUqnF jD8TmS1ub8+0eNrxhcmi5dVMNgc2j5ajLSweS5b8ZPJoeXaSLYA5issmJTUnsyy1SN8ugStj yrtfTAXLWStmPv3D3MC4hKWLkZNDQsBEYunHBexdjFwcQgIbGCV+zvkG5SxnlFi67wZYFRtQ 1Yadn5lAbBEBLYkF6xexgBQxC0xikth7bCZYkbBAoUT7j1tsXYwcQEVFEpvbvCFMPYldbUIg FSwCqhItTy6xg9i8Ar4S769cZobY1c0osWXWCVaQBKOAmMT3U2vAdjELiEvcejKfCeJSAYkl e84zQ9iiEi8f/2OFsJUkPv6ezw5RryOxYPcnNghbW2LZwtfMEMsEJU7OfMIygVFkFpKxs5C0 zELSMgtJywJGllWMHKXFBTm56UYGmxiBUXJMgk13B+P96Z6HGAU4GJV4eBWWbQkXYk0sK67M PcQowcGsJMKrtHtruBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFesUeK4UIC6YklqdmpqQWpRTBZ Jg5OqQbG0K8ZDAzzGh4umPq7Lvb4rYW1f1s27X67yfDi7UqPs183l+wV2GNg6/+teuacwvt3 v0x/qst8wHS9kSPXfV6Bzux+i+9OD01jWb/vKthtI/PwSVrWast5EdvMpimFqurePbpK77Ap o3VEb2wcy7mHrJL/TJ3uKV2vmFx2TT43OCBcwvTtYoFoJZbijERDLeai4kQAhNoAcI4CAAA= Archived-At: Cc: "radext-chairs@ietf.org" , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , The IESG , "lionel.morand@orange.com" Subject: Re: [radext] Suresh Krishnan's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:48:54 -0000 Hi Alan,=0A= =0A= On 08/18/2016 03:33 AM, Alan DeKok wrote:=0A= > On Aug 18, 2016, at 5:53 AM, Suresh Krishnan wrote:=0A= >> * Why are the the uint8 and unit16 based types getting stuffed into 32= =0A= >> bit fields inside the TLVs? This feels like a complete waste. Is there= =0A= >> any specific reason this is required?=0A= >=0A= > The limited nature of RADIUS data types. This behaviour is mandated by= RFC 6158=0A= >=0A= > https://tools.ietf.org/html/rfc6158#appendix-A.2.1=0A= =0A= Thanks for the pointer. Good to know. Maybe a reference to this RFC would b= e =0A= in order?=0A= =0A= Regards=0A= Suresh=0A= =0A= From nobody Thu Aug 18 07:48:30 2016 Return-Path: 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 8C7F312D51F; Thu, 18 Aug 2016 07:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham 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 9hLGlxOTyChj; Thu, 18 Aug 2016 07:48:24 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44112D8FF; Thu, 18 Aug 2016 07:48:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E66AF2CCB3; Thu, 18 Aug 2016 17:48:22 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLQ9ZdcsEcIu; Thu, 18 Aug 2016 17:48:22 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 19C762CC9C; Thu, 18 Aug 2016 17:48:22 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_52E533D0-4086-4A8E-80A4-21E5D0780CCF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75267D0D@AZ-FFEXMB04.global.avaya.com> Date: Thu, 18 Aug 2016 16:48:21 +0200 Message-Id: <3DB0DCA2-4149-4B8C-A2DA-1DD2FCC69379@piuha.net> References: <9904FB1B0159DA42B0B887B7FA8119CA75267BC5@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA75267D0D@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , General Area Review Team , "draft-ietf-radext-datatypes.all@tools.ietf.org" Subject: Re: [radext] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 14:48:26 -0000 --Apple-Mail=_52E533D0-4086-4A8E-80A4-21E5D0780CCF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 Thanks for the review, Dan! And Alan for edits. Jari --Apple-Mail=_52E533D0-4086-4A8E-80A4-21E5D0780CCF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXtcq1AAoJEM80gCTQU46q96QQAIhSqjDOyOu4ZkGQwoSeaZoF IJ6az0D2ZCI7r4YbwoK3mUy8xuUUuHQEg9q2vKR5sC6diDlgngw2szh7Ua4uLzQ7 0mNExBy14iuhnRPlF9JE0ArUAQ7KRjTkBVxc31OfPMdfmNpmqLlelGh9fRWFqpxU 2FW3n5UoLyqgbCdVbVJz6IPSdsehUrinbwdKvUUtjWqi9sWx9zWLsez0Cy+NgxSt XSYk4LSh7cIWx8ROcjGnKns8xmZWnlAQHh99ZKO4C51mPbbDnuVvgkBvlTizY7Vz sM0x3nuntRN/igcVl+6lfPFIgW9ns9iCDPbRtQ7bw6aJLcZjkFGG9p0DLPiUPvmv p/GcQjCBQyoHMvI3kDYHpQ8uZMeDAbr/umP9CQ+HuAb5lBw58esiRHo0E49h+pjL gfidVFOeEBAVLL+CzFlrH6AYAOTcXWL6JDeNqvNTAlGa9l0jtRsm5Yi9iD6ZcdsG CLI8Ca5aQv22hDPNk85dnny9L0fYaHDsD6ZKk00b1KeFsk6YewQqwzV9S0VUYp75 BarrvDpP5VbfMZHdFd2JTRvQPmlJEF6BeLkAEYHfDQtuQwDCgC0KFTnFqmG1EyI/ NKXaMHRoYLXNifcCHBtPppwY3yrysslYoy2QKPT5u0Fnff3YiaIsppYDN7m+3o7O WGWaV3Q5sy+51IeFhW7N =nug1 -----END PGP SIGNATURE----- --Apple-Mail=_52E533D0-4086-4A8E-80A4-21E5D0780CCF-- From nobody Thu Aug 18 09:36:37 2016 Return-Path: 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 B622112D5D8; Thu, 18 Aug 2016 09:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 cNHoVgyt6qOU; Thu, 18 Aug 2016 09:36:29 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8A68312DC60; Thu, 18 Aug 2016 09:36:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 7B0E5C0D; Thu, 18 Aug 2016 16:36:23 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7ZjTmKFzXOv; Thu, 18 Aug 2016 16:36:23 +0000 (UTC) Received: from [10.192.3.201] (LStLambert-657-1-56-254.w80-13.abo.wanadoo.fr [80.13.33.254]) by mail.networkradius.com (Postfix) with ESMTPSA id 0A20C772; Thu, 18 Aug 2016 16:36:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 18:36:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Winter Stefan , radext@ietf.org, draft-ietf-radext-datatypes@ietf.org, The IESG , radext-chairs@ietf.org Subject: Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 16:36:32 -0000 On Aug 17, 2016, at 5:43 AM, Suresh Krishnan = wrote: > * Section 3.10 >=20 > It is not clear from this definition how exactly a sender needs to = encode > this attribute on the wire. e.g. =46rom the spec it looks like an IPv6 > prefix such 2001:db8:dead:beef::/64 can legally be encoded using = anywhere > between 8 octets and 16 octets. What exactly is the preferred = encoding? > If you intend to allow all of the encodings can you please add an > explicit statement to say so. The preferred encoding should be the shortest one. I'll put some text = together. > * I am not sure why this document uses Reserved fields in sections = 3.10 > and 3.11. Is it for alignment? Please clarify. I don't see exactly why > aligning a 4 octet or a 16 octet value to a 16 bit boundary would = provide > any value.=20 > (I personally think such padding related stuff should be in the > definition of the radius attribute that uses the datatype and not in = the > datatype itself but I will not block on this.) The data types in 3.10 and 3.11 are taken from previous = specifications. I'm not entirely sure why they have reserved fields, = either. We can't change the format of the data type, because implementations = use this format. The document just codifies existing practices. =20 > * Section 3.7 >=20 > I think this text is confusing because "octet string" and network byte > order do not seem to be compatible. Suggest rewording >=20 > OLD: > The "ifid" data type encodes an Interface-Id as an 8-octet string in > network byte order >=20 > NEW: > The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in > network byte order Sounds good. > * Section 3.10 and 3.11 >=20 > The separator between the Reserved field and the Prefix Length field = is > off by one position. Fixed.= From nobody Thu Aug 18 20:04:07 2016 Return-Path: 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 9B99112D53B; Thu, 18 Aug 2016 20:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hTwXDYOqNjK9; Thu, 18 Aug 2016 20:03:59 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF5412D09A; Thu, 18 Aug 2016 20:03:59 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-06-57b67814392f Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id F6.7B.02568.41876B75; Fri, 19 Aug 2016 05:08:05 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 23:02:00 -0400 From: Suresh Krishnan To: Alan DeKok Thread-Topic: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (with DISCUSS and COMMENT) Thread-Index: AQHR+Dl7FAHLmNalzUyGv0wDDZn0tQ== Date: Fri, 19 Aug 2016 03:01:59 +0000 Message-ID: References: <147140538762.19947.17983354603426554979.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPoK5oxbZwg+nbeC2aPjexW1zdN4PN YsaficwWTzu+MFm0vJrJZjGvoZHdgc2j5WgLi8eSJT+ZPJZ3+QQwR3HZpKTmZJalFunbJXBl 3P3SxlbQK1Sx/cMm1gbGTXxdjJwcEgImEp+27mfsYuTiEBLYwCixd8U1JghnOaPEqlvLWUGq 2ICqNuz8zARiiwhoSSxYv4gFxGYW+Mwo8WGGIogtLJAvsf7HAXaImgKJ5R2fGCFsPYlVXYfA 6lkEVCW29x9hBrF5BXwl9s56xQaxrJtR4n5TO9gyRgExie+n1jBBLBCXuPVkPhPEqQISS/ac Z4awRSVePv7HCmErScx5fY0Zol5HYsHuT2wQtrbEsoWvoZYJSpyc+YRlAqPILCRjZyFpmYWk ZRaSlgWMLKsYOUqLC3Jy040MNjECI+WYBJvuDsb70z0PMQpwMCrx8C74vjVciDWxrLgy9xCj BAezkgjvz+Jt4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5xR4phgsJpCeWpGanphakFsFkmTg4 pRoYp155Kji/9HDBC/NUaY8++0LlJyweNz/1RnI/jl1z+mzK7LlKS0OFM9tvLnBrea+48bfF 1QfaU784G82WVBf72HSQnctILU63xKZC9M7D5Ut9fmi0KUaduuDO1f3BxV73V+7zX7/XPNPe 3lQVePTS66lP+W/qfHBnKf6YtvauTJAdQ4T+VmNTJZbijERDLeai4kQAICyJIZACAAA= Archived-At: Cc: Winter Stefan , "radext@ietf.org" , "draft-ietf-radext-datatypes@ietf.org" , The IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Suresh Krishnan's Discuss on draft-ietf-radext-datatypes-06: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 03:04:01 -0000 Hi Alan,=0A= Thanks for your response. I will clear once you post a new version with = =0A= the changes.=0A= =0A= Thanks=0A= Suresh=0A= =0A= On 08/18/2016 12:36 PM, Alan DeKok wrote:=0A= > On Aug 17, 2016, at 5:43 AM, Suresh Krishnan wrote:=0A= >> * Section 3.10=0A= >>=0A= >> It is not clear from this definition how exactly a sender needs to encod= e=0A= >> this attribute on the wire. e.g. From the spec it looks like an IPv6=0A= >> prefix such 2001:db8:dead:beef::/64 can legally be encoded using anywher= e=0A= >> between 8 octets and 16 octets. What exactly is the preferred encoding?= =0A= >> If you intend to allow all of the encodings can you please add an=0A= >> explicit statement to say so.=0A= >=0A= > The preferred encoding should be the shortest one. I'll put some text = together.=0A= >=0A= >> * I am not sure why this document uses Reserved fields in sections 3.10= =0A= >> and 3.11. Is it for alignment? Please clarify. I don't see exactly why= =0A= >> aligning a 4 octet or a 16 octet value to a 16 bit boundary would provid= e=0A= >> any value.=0A= >> (I personally think such padding related stuff should be in the=0A= >> definition of the radius attribute that uses the datatype and not in the= =0A= >> datatype itself but I will not block on this.)=0A= >=0A= > The data types in 3.10 and 3.11 are taken from previous specifications.= I'm not entirely sure why they have reserved fields, either.=0A= >=0A= > We can't change the format of the data type, because implementations us= e this format. The document just codifies existing practices.=0A= >=0A= >> * Section 3.7=0A= >>=0A= >> I think this text is confusing because "octet string" and network byte= =0A= >> order do not seem to be compatible. Suggest rewording=0A= >>=0A= >> OLD:=0A= >> The "ifid" data type encodes an Interface-Id as an 8-octet string in=0A= >> network byte order=0A= >>=0A= >> NEW:=0A= >> The "ifid" data type encodes an 8 octet IPv6 Interface Identifier in=0A= >> network byte order=0A= >=0A= > Sounds good.=0A= >=0A= >> * Section 3.10 and 3.11=0A= >>=0A= >> The separator between the Reserved field and the Prefix Length field is= =0A= >> off by one position.=0A= >=0A= > Fixed.=0A= >=0A= =0A= From nobody Fri Aug 19 17:29:44 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 12FF912B074; Fri, 19 Aug 2016 17:29:41 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F91B12D0CF for ; Fri, 19 Aug 2016 17:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.427 X-Spam-Level: X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham 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 vbjgadnEiRfs for ; Fri, 19 Aug 2016 17:29:40 -0700 (PDT) Received: from smtp02.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3061E12B074 for ; Fri, 19 Aug 2016 17:29:40 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp02.icann.org (Postfix) with ESMTP id 25BC0E3263 for ; Sat, 20 Aug 2016 00:29:39 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id EB464C205C1; Sat, 20 Aug 2016 00:29:38 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Amanda Baber via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #922685 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Sat, 20 Aug 2016 00:29:38 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160820002942.12FF912B074@ietfa.amsl.com> Resent-Date: Fri, 19 Aug 2016 17:29:41 -0700 (PDT) Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org Subject: [radext] [IANA #922685] expert review for draft-ietf-radext-ip-port-radius-ext (IP Flow Information Export (IPFIX) Entities) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: drafts-expert-review-comment@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 00:29:42 -0000 Dear Authors, The experts for the IPFIX IE registry have returned the following review: In general, the Information Elements in draft-ietf-radext-ip-port-radius-ext are so underspecified as to be unimplementable. They should not be added to the registry in their present form. The authors are advised to read RFC 7013, especially Section 4, which provides useful information on defining Information Elements. Specifically: The Information Element transportType is underspecified: (a) I presume this is in reference to sourceTransportPort and destinationTransportPort, but the description must say this if it is the case; (b) It's not clear at all from the description in what context this distinction is useful; (c) What's an ICMP identifier? In addition, the description of transportType appears to create a table which should probably be handled as a subregistry. See See RFC7013 section 4.7. for advice on the creation of tables without subregistries (in short, "don't".) The Information Element natTransportLimit has an inappropriate name; it does not describe that which it (presumably) is supposed to represent (see RFC 7013 section 4.1). In addition, it is underspecified. It is impossible to implement from the description. Is the field IPv4 specific, or is IPv6 supported as well? (If not, why not?) The Information Element localID has an inappropriate name; it is far too general (see RFC 7013 section 4.1). It uses an inappropriate abstract data type (addresses should never be represented as UTF-8 strings in IPFIX, see RFC 7013 section 4.2). It is underspecified as well as poorly designed. Without the ability to disambiguate the type of information in the field, this is not a useful Information Element. Without a complete enumeration of possible types (n.b. 'etc.' in the description), it is not a useful Information Element. Its purpose is unclear from its description; further, it appears to violate the following guidance in RFC 7013 section 4: "The Information Element must be unique within the registry, and its description must represent a substantially different meaning from that of any existing Information Element. An existing Information Element that can be reused for a given purpose should be reused." Best regards, Amanda Baber IANA Lead Specialist ICANN From nobody Sat Aug 20 02:57:27 2016 Return-Path: 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 1693812B057; Sat, 20 Aug 2016 02:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 WUTBMuyNriHv; Sat, 20 Aug 2016 02:57:22 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CC0DD12B00C; Sat, 20 Aug 2016 02:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E9B13C15; Sat, 20 Aug 2016 09:57:20 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCMVyvTcAfHs; Sat, 20 Aug 2016 09:57:20 +0000 (UTC) Received: from [10.192.3.201] (LStLambert-657-1-56-254.w80-13.abo.wanadoo.fr [80.13.33.254]) by mail.networkradius.com (Postfix) with ESMTPSA id 6CDD948B; Sat, 20 Aug 2016 09:57:20 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6F0C68AD-A6AB-4861-9FAD-13EE96A44B51"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: Date: Sat, 20 Aug 2016 11:57:16 +0200 Message-Id: <4DF08288-084A-4AC0-968E-FA147C54B6F1@freeradius.org> References: To: "Liushucheng (Will)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: radext@ietf.org, "ops-dir@ietf.org" , "draft-ietf-radext-datatypes@ietf.org" Subject: Re: [radext] OPS-DIR review of draft-ietf-radext-datatypes-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 09:57:26 -0000 --Apple-Mail=_6F0C68AD-A6AB-4861-9FAD-13EE96A44B51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 20, 2016, at 9:35 AM, Liushucheng (Will) = wrote: > * Section 1, page 1: > > > > RADIUS specifications have historically defined attributes in terms = of > > name, type value, and data type. >=20 > The term "type value" sounds confusing, particularly when one is used = to terms such as "TLV" meaning "Type, Length, Value". Did you mean just = "type"? Something else? I'll remove "type" and clarify the resulting text. >=20 > * Section 1, page 1: > > There is no management of data type name or definition. >=20 > Same here. Not sure if you just meant data types, or what. But this is = confusing to me. I've reworded the paragraph to: RADIUS specifications have historically defined attributes in terms of name, value, and data type. Of these three pieces of information, the name is recorded by IANA in the RADIUS Attribute Type registry, but not otherwise managed or restricted, as discussed in [RFC6929] Section 2.7.1. The value is managed by IANA, and recorded in that registry. The data type is not managed or recorded in the RADIUS Attribute Type registry. Experience has shown that there is a need to create well known data types, and have them managed by IANA. > * Section 2.1.1, Page 7: > > For example, the data type "vsa" will contain a data field called > > "VSA-Data". >=20 > Not sure what this means. Is the data type "vsa" supposed to contain = multiple "fields" (a la "C-language structures"), or what? -- i.e., = it's not clear what you mean by "data type" and "data field". Given the = goal of this document, such definitions should be clearly spelled out. This text is intended to describe the naming convention, not define = the data types. The later text defines the data types. I've tried to clarify this by the following text: We consistently use "Value" to refer to the contents of a data type, where that data type is simple. For example, an "integer" can have a "Value". In contrast, a Vendor-Specific attribute carries complex information, and thus cannot have a "Value". For data types which carry complex information, we name the fields based on the data type. For example, a Vendor-Specific attribute is defined to carry a "vsa" data type, and the contents of that data type are described herein as "VSA-Data". >=20 > * Section 2.1.2, page 7: > > Attributes can usually be completely described via the Attribute = Type > > code, name, and data type. >=20 > The use of "type" here is confusing. Could "type" be omitted from this = sentence? Besides, it seems it's the first time you refer to the "code". > Is the reader expected to be familiar with what you're referring to by = "code", here? The Attribute Type refers to the IANA RADIUS Attribute Type registry. I'll change "code" to "value". >=20 > * Section 2.1.3, page 8: > > The Attribute Type code, given in the "dotted number" notation from > > [RFC6929]. >=20 > How about s/code/number/ or just remove the term "code"? I'll just use "value". > * Section 2.2, page 10: > > Instead, specifications which define new meaning for "reserved" > > fields SHOULD describe how older implementations process those = fields. >=20 > What's the point of specifying how an older implementation would = behave? i.e., if this spec is going to apply to older implementations, = such implementations are, by definition, no longer "older" (if they end = up employing with this spec) The intention is to describe how the new definition is compatible with = existing implementations. I'll update the text. i.e. defining new mandated behaviour for a "reserved" field means that = existing implementations won't follow that mandated behaviour. This is = bad. > * Section 3.11, page 21: > > If the address is all zeros (i.e. "0.0.0.0", then the Prefix-Length > > MUST be set to 32. >=20 > Would you clarify why? It's taken from previous specifications, which don't explain why. I'm = hesitant to give a new explanation here. https://tools.ietf.org/html/rfc6572#section-4.12 > * Section 3.15, page 25: > > > > Ext-Data > > > > The contents of this field MUST be a valid data type as defined in = the > > RADIUS Data Type registry. The Ext-Data field MUST NOT contain any = of > > the following data types: "concat", "vsa", "extended", > > "long-extended", or "evs". >=20 > How can you tell what's the data type stored in the Ext-Data field? Via the attribute definition. It defines a value / OID, name, and = data type for the contents. The data type is what goes into the = Ext-Data field, as discussed in the text. Remember, the "extended" type is a way to extend the Attribute Type = value from an 8 bit space to "dotted number" space. The real contents = of that type are attribute data, just like the Attr-Data data defined = earlier. But the "extended" type is defined *within* the "Attr-Data" = field, so we have to have a different and unique name for it. > * Section 3.16, page 26: > > The More field is one (1) bit in length, and indicates whether or = not > > the current attribute contains "more" than 251 octets of data. The > > More field MUST be clear (0) if the Length field has value less than > > 255. The More field MAY be set (1) if the Length field has value of > > 255. > > > > If the More field is set (1), it indicates that the Ext-Data field = has > > been fragmented across multiple RADIUS attributes. When the More = field > > is set (1), the attribute MUST have a Length field of value 255; = there > > MUST be an attribute following this one; and the next attribute MUST > > have both the same Type and Extended Type. >=20 > There seems to be conflicting RFC2119 for Length =3D=3D 255 && M=3D1 = -- one is a MAY, the other one is a MUST This is text dealing with fragments. A fragment of Length 255 is = allowed, and can have M=3D0. If Length=3D255 and M=3D1, then there MUST be a subsequent fragment. Both situations are allowed. The first one MAY have M=3D0, because = there are no subsequent fragments. If there are multiple fragments, it = MUST have M=3D1, and conversely, if M=3D1, there MUST be subsequent = fragments. > ** Editorial ** >=20 > * Abstract: > > updates the specifications to better follow established practice. = We > > do this by naming the data types defined in RFC 6158, which have = been > > used since at least RFC 2865. >=20 > Please change to "since at least the publication of RFC2865" or ... OK. >=20 > * Section 1.1, page 4: > > > > A number of data type names and definitions are given in [RFC2865] > > Section 5, at the bottom of page 25. >=20 > Please rephrase as "A number of data type names and definitions are = given in Section 5 of [RFC2865], at the bottom of page 25" Sure. > * Section 2.2, page 9: > > It is RECOMMENDED that such attributes be treated as "invalid > > attributes", as defined in [RFC6929] Section 2.8. >=20 > Throughout the document, please replace instances like this with = something like "...Section x.x of [RFCxxxx]", instead. I'm not sure this is necessary. A scan of previous specifications = show both uses with about equal weighting. > * Section 3.5, page 15: > > s, and TLVs cannot be used, the "string" data type MUST be used. > > This requirement include encapsulation of data structure >=20 > s/include/includes/ OK. > * Section 3.11, page 20: > > > > 0 1 2 3 0 1 2 = 3 > > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > Reserved | Prefix-Length | Prefix ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ... > > Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > There seems to be an alignment problem with the Prefix-Length field? Fixed. >=20 >=20 > * Section 3.16, page 26: > > > > Extended-Type > > > > This field is identical to the Extended-Type field defined above in > > Section 2.13. >=20 > There's no such Section. Updated. >=20 > * Section 4.1 and Section 4.2: >=20 > Shouldn't these two sections be part of the "IANA Considerations" = section? I"m Ok with it either way, and there hasn't been feedback from IANA = that it's required. Alan DeKok. --Apple-Mail=_6F0C68AD-A6AB-4861-9FAD-13EE96A44B51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXuCl8AAoJEH0Oec13Yh7N4OsH/ie6MBuCq/cHIcPvClR/P7zf MsKiiZd1G2N2tZgTTjWBTZ8xO8IVZQbIZeG9WfUKUhtjTDXXdZmT/aPGQvzAypFy xJRYv/QPVaRbVaA+mExgqeHqU9oHRZE1XwYDDh0YvyJZraNh4fq5SxAzzZfGIGlk tkl8TIFMAZ2l9N63wV8k2ZwVI77G/Xp+rDZmU3H4mRA6zqVHxWOUeWCgdCn0gEw7 O6OShVcIUQE4G8PVPP5DUe7bwtFz0VJ/efPfPR8vY8mhXJUF/qBhmqIEIbkG8lge XHN1/ntyihhw6iTn62QLwILcOvWSTef6ILs8HHpOVi3S7oCKgrWkmdZZvlNlvvs= =xBKt -----END PGP SIGNATURE----- --Apple-Mail=_6F0C68AD-A6AB-4861-9FAD-13EE96A44B51-- From nobody Wed Aug 24 13:06:27 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 749E512D69E; Wed, 24 Aug 2016 13:06:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147206918541.26600.6210450253617928757.idtracker@ietfa.amsl.com> Date: Wed, 24 Aug 2016 13:06:25 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-datatypes-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 20:06:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Author : Alan DeKok Filename : draft-ietf-radext-datatypes-07.txt Pages : 38 Date : 2016-08-24 Abstract: RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFC 2865, 3162, 6158, and 6572. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-datatypes-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-datatypes-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 29 08:57:58 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D2DE912D10B; Mon, 29 Aug 2016 08:57:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCF412D125; Mon, 29 Aug 2016 08:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.922 X-Spam-Level: X-Spam-Status: No, score=-101.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 hHEO5dNq8vjK; Mon, 29 Aug 2016 08:57:50 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0122.outbound.protection.outlook.com [104.47.36.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B8912D10B; Mon, 29 Aug 2016 08:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K0iTWpF0iDDMYGoP5268chkJF26THVMAE29prpzpgNk=; b=eZKC1vphEVQwkVFyhR6xbEJTc9NdUhSQ/ACCXQLV/sXIfTO362Moyq8dsK/f1JCnEiIZ0C7QQ/5GZw8wjGoig1IotJ2eWSxl26l/Rkl/ajQ3KM1Anxd42nx2vGITRWoJij+aIubmCOvyuDKDE1l6PHmQG2uh0YumPEwGAFSiFMk= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3; Mon, 29 Aug 2016 15:57:47 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0599.008; Mon, 29 Aug 2016 15:57:47 +0000 From: Ron Bonica To: IETF Gen-ART , "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" Thread-Topic: Gen-ART review of draft-ietf-radext-ip-port-radius-ext-09 Thread-Index: AdICDdvjBgP0ippHSIqIa/K5UKoh5A== Date: Mon, 29 Aug 2016 15:57:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 8b5355bc-8177-49be-923f-08d3d0253906 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 6:90E9k14DhnyKgAa6XswDA18JT5m3c1anZgcNC3y8kohSUiRaze7XSpRy5H2QC46nXVHefNIwu+svXpyVasyUlpFjyiRSJ1OzmGGgtnL1agf25TCQDCkvPrvqKtSIR3ipbY3vqtjHdOadfesu5BQ/0ZuWuDr6vNvn7xTOLjnJsl6v5gBSWgZfK9slYqjhtMokIKWbhgfDoWojFOkYW/Hduk5HuZFuC+w6nQ+jAn1XYH6GlRjUZ7Sgb+JKxQFFee9Ex2VZudRw0cYfOKZEw5RfFM70ywcj04KhSpApnoW0gs3Cbo6PYfPGDFH7hLj/DLPB1k9Zbw/oIp0ZDsTSOwYykQ==; 5:Odz9+PZcZdgH488oRQ3eb6DhP6NnZJ7BSrbanj2Aw0984hKpKhfOrA2e3nfPBodr0x2N2uu3SyjhL8ktyuBvCjtn9+EEjGxSbyLwHDKSIviLStR91qBLAPqvfEDvEBZ6cXIpLOd/H2GXBbR2j+ng8rRdvruFNbrAQ9wTOS2b5EY=; 24:aFL87kweUGj3xq+BdvWnXSSKGZJqJKF2zEAIRobHRnmTOqBO+qo6j2S11FhHDJUtzLpN2wSR6vyS9FdInTMUBTEJpoI70ADgmvCbIuf2xqg=; 7:Kv3i+rMpWun1U6yqIVQYzLYthx9r5PPvrBcFDeKsvgutPz97/RWdvRAIiFDtx3xFJ7ONmfkgiGDVjTpE+ZZhimEhjSOh1hssiBalcBoI7uzQr6DifxK3J9uTkLN2qi6Rc7FPLVv5Q9PxCclO4J2oOi4xSsZh1RAJexdiDIKQYm6zRBlMWltJmvsx7OoFc/glOYoAEntKVhF45m/8kiSMC4Oty4QEm1C9wjvcL3+qEbOVBmGWs+8TbM6U3hQidP4b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:(304825118); SRVR:BLUPR0501MB2052; x-forefront-prvs: 0049B3F387 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(199003)(189002)(101416001)(107886002)(5002640100001)(33656002)(5001770100001)(97736004)(19580395003)(2501003)(15975445007)(229853001)(77096005)(2900100001)(9686002)(92566002)(189998001)(81166006)(2906002)(8936002)(76576001)(8676002)(81156014)(10400500002)(122556002)(54356999)(50986999)(6116002)(102836003)(3846002)(5660300001)(3280700002)(11100500001)(586003)(3660700001)(7696003)(305945005)(7736002)(106356001)(7846002)(230783001)(105586002)(99286002)(74316002)(86362001)(87936001)(66066001)(68736007)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2016 15:57:47.8120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160829155752.D2DE912D10B@ietfa.amsl.com> Resent-Date: Mon, 29 Aug 2016 08:57:52 -0700 (PDT) Archived-At: Subject: [radext] Gen-ART review of draft-ietf-radext-ip-port-radius-ext-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 15:57:53 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at Document: draft-ietf-radext-ip-port-ra= dius-ext-09 Reviewer: Ron Bonica Review Date: 2016-09-29 IETF LC End Date: 2016-11-08 IETF Telechat Date: 2016-09-15 Summary: This document is ready for publication. =20 Major Issues: None Minor Issues: None Editorial Issues: None Ron