From alexey.melnikov@isode.com Tue May 8 13:37:52 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116751F0C51 for ; Tue, 8 May 2012 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyAb9CWh-sac for ; Tue, 8 May 2012 13:37:51 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA451F0C60 for ; Tue, 8 May 2012 13:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1336509457; d=isode.com; s=selector; i=@isode.com; bh=llauByi41lNIlvg0poFnw1IUDIGJWx8mJQVz+qvkOmo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ufbNzvUwU63zuUoOa6m4cUn3H00A+upz472deBpnlRp+cA3e4UAYKX9Z9/EB7tx9oIMDpL iE1xRopG8PZLbRonz3u91GUt8cJbDQ0yQkGpqkgwAzsWY5cXgwLNWkzdWmXxKBjIU2J6N6 ykpWrfBIDQ3j125i6IjvTEuByVxKPn0=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 8 May 2012 21:37:37 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FA98384.8090805@isode.com> Date: Tue, 08 May 2012 21:35:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: ops-area@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 May 2012 03:43:57 -0700 Subject: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:37:52 -0000 Hi, Benoit suggested that I post this email message here. draft-liang-iana-pen is trying to formalize and document rules for the Private Enterprise Numbers registry . In particular the purpose of this document is to document a) what is allowed to be registered (what characters should be allowed in an Enterprise name, what is an Enterprise) b) under what conditions an entry can be changed and what kind of documentation is required. The document is being worked on by IANA (Pearl with some help from Michelle), I was asked to help out. While the document is mostly documenting existing practice, it is also trying to specify some rules about how the registry is to be operated, because certain (most?) things were never written down. Pearl and I will appreciate reviews and feedback on the document. One of the major issues is currently outstanding is "what is considered to be an Enterprise?". While Universities and non profit organizations are considered Enterprises, it is not very clear whether different departments of a University, or subsidiaries of the same bank in different countries are considered to be different enterprises or not. A more difficult case is whether to allow different products from the same vendor to be allocated different PENs. Yet another example is allocation of special PENs for RFCs (e.g. RFC 5103.html, section 6.1). Is this Ok? (All of these are examples of what people asked to register.) As currently there is no guidelines, there is no way for IANA to say "no". Somewhat related to this: another position might be that there are enough PENs for everyone and that there is really no need to be restrictive in the case of this registry. Any feedback would be appreciated. Thank you, Alexey From bertietf@bwijnen.net Wed May 9 08:03:17 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70DC11E8091 for ; Wed, 9 May 2012 08:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPey9Ey7vWmm for ; Wed, 9 May 2012 08:03:17 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id C05FF11E8072 for ; Wed, 9 May 2012 08:03:16 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SS8Q4-0007VM-4o; Wed, 09 May 2012 17:03:14 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SS8Q3-0002tg-Sk; Wed, 09 May 2012 17:03:12 +0200 Message-ID: <4FAA872F.9080007@bwijnen.net> Date: Wed, 09 May 2012 17:03:11 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov , pearl.liang@icann.org References: <4FA98384.8090805@isode.com> In-Reply-To: <4FA98384.8090805@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120509 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4059d54e1c671579c4b66a68e49964cf4 Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:03:17 -0000 Mmm.. In IANA considerations I see: o Removal of Private Enterprise Numbers: A Contact Name can request to remove the corresponding PEN allocation if the resource is no longer in used or the resource does not meet the needs. (In a case when the Contact Name is no longer with the Company/Organization, the Modification procedure described above MUST be used first.) Such request does not happen often and regularly. Requests can only be fulfilled upon verification by IANA and/or subject matter experts. If the removal request is honoured, the entry is marked as "Unassigned" and can be reallocated by IANA later unless specified otherwise, i.e. by marking the entry as "Reserved". How can we be assured that the once assigned PEN is not being used anywhere in the digital world? What is someone is still using it in some obsoleted/no-longer-supported product? Should he/she run the risk that it conflicts with a possible new assignment/allocation? I would rather see that it will be marked "returned on yyyy-mm-dd by xxxxxxx" and then that it not be re-used/allocated unless we run out of numbers far in the future (at that time we can decide if this makes sense, or possibly define another arc in iso.org.dod.internet.private.enterprise, for example: iso.org.dod.internet.private.enterprise.2^32-1.PEN where 2^32-1 is a special PEN that indicates that the PEN is longer than 32bits. Bert On 5/8/12 10:35 PM, Alexey Melnikov wrote: > Hi, > Benoit suggested that I post this email message here. > > draft-liang-iana-pen is trying to formalize and document rules for the Private Enterprise Numbers registry > . In particular the purpose of this document is to document > a) what is allowed to be registered (what characters should be allowed in an Enterprise name, what is an Enterprise) > b) under what conditions an entry can be changed and what kind of documentation is required. > > The document is being worked on by IANA (Pearl with some help from Michelle), I was asked to help out. While the document is mostly > documenting existing practice, it is also trying to specify some rules about how the registry is to be operated, because certain > (most?) things were never written down. > > Pearl and I will appreciate reviews and feedback on the document. One of the major issues is currently outstanding is "what is > considered to be an Enterprise?". While Universities and non profit organizations are considered Enterprises, it is not very clear > whether different departments of a University, or subsidiaries of the same bank in different countries are considered to be > different enterprises or not. A more difficult case is whether to allow different products from the same vendor to be allocated > different PENs. > Yet another example is allocation of special PENs for RFCs (e.g. RFC 5103.html, section 6.1). Is this Ok? > (All of these are examples of what people asked to register.) As currently there is no guidelines, there is no way for IANA to say > "no". > > Somewhat related to this: another position might be that there are enough PENs for everyone and that there is really no need to be > restrictive in the case of this registry. > > Any feedback would be appreciated. > > Thank you, > Alexey > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From randy_presuhn@mindspring.com Wed May 9 08:58:47 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D131E11E808A for ; Wed, 9 May 2012 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.131 X-Spam-Level: X-Spam-Status: No, score=-99.131 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z1R1mDPzJ-0 for ; Wed, 9 May 2012 08:58:47 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3632211E8080 for ; Wed, 9 May 2012 08:58:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YC2R8Wz4orGHXVN72CoIt7G8sETE8Z9wlrpsZ5MDE3KcTulYJvW656A0z1TVECaQ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.225.61] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SS9Hq-00006U-6T for ops-area@ietf.org; Wed, 09 May 2012 11:58:46 -0400 Message-ID: <001801cd2dfc$e52c32e0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4FA98384.8090805@isode.com> Date: Wed, 9 May 2012 09:00:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88992cdffa39784e0497a1c4f2374fd2b8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.225.61 Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:58:47 -0000 Hi - > From: "Alexey Melnikov" > To: > Sent: Tuesday, May 08, 2012 1:35 PM > Subject: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 ... > draft-liang-iana-pen is trying to formalize and document rules for the > Private Enterprise Numbers registry > . In particular the > purpose of this document is to document > a) what is allowed to be registered (what characters should be allowed > in an Enterprise name, what is an Enterprise) > b) under what conditions an entry can be changed and what kind of > documentation is required. I'm glad that it tries to cover the IANA side of merger / acquisition case. However, the language about "new owner" glosses over the realities of corporate takeovers. I honestly don't know *who* the "new owner" would be after some of the mergers I've experienced. (I do know *what* the "new owner" would be in most cases.) I think more guidance might also be needed on the handling of corporate splits and spin-offs, particularly ones splitting what had previously been considered a single group or product line. This may be more of a problem for the administrator of the number space than for IANA, but it probably should be addressed somewhere, particularly since it interracts with how some management systems classify devices they discover. Randy From randy_presuhn@mindspring.com Wed May 9 09:03:10 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9E411E8095 for ; Wed, 9 May 2012 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.976 X-Spam-Level: X-Spam-Status: No, score=-99.976 tagged_above=-999 required=5 tests=[AWL=1.134, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnUqrvQs3mQv for ; Wed, 9 May 2012 09:03:10 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2C11E8080 for ; Wed, 9 May 2012 09:03:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jGk5PxOU+v6MJsluC7YFpnwWydbFT6aiWkXUUNo4EJy36oD8OFPqMJWPex+Z9WTQ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.225.61] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SS9M5-0006tp-9I for ops-area@ietf.org; Wed, 09 May 2012 12:03:09 -0400 Message-ID: <001d01cd2dfd$8387bfe0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4FA98384.8090805@isode.com> <4FAA872F.9080007@bwijnen.net> Date: Wed, 9 May 2012 09:05:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f886d0576cc0059a26a149619e3ab018198350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.225.61 Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 16:03:10 -0000 Hi - > From: "Bert Wijnen (IETF)" > To: "Alexey Melnikov" ; > Cc: > Sent: Wednesday, May 09, 2012 8:03 AM > Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 ... > How can we be assured that the once assigned PEN is not being used > anywhere in the digital world? What is someone is still using it in > some obsoleted/no-longer-supported product? Should he/she run the > risk that it conflicts with a possible new assignment/allocation? Agreed. Even if the assignee never used the arc, we have no way of knowing whether someone else has built knowledge of that one-time assignment into a product. Randy From ietfdbh@comcast.net Wed May 9 09:51:47 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E9321F847D for ; Wed, 9 May 2012 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W71Jxyb-KItr for ; Wed, 9 May 2012 09:51:47 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by ietfa.amsl.com (Postfix) with ESMTP id 707EB21F847F for ; Wed, 9 May 2012 09:51:42 -0700 (PDT) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta06.emeryville.ca.mail.comcast.net with comcast id 7slX1j0041HpZEsA6sri2K; Wed, 09 May 2012 16:51:42 +0000 Received: from [192.168.0.64] ([174.17.154.21]) by omta14.emeryville.ca.mail.comcast.net with comcast id 7sr71j00Y0Txrq68asrEnf; Wed, 09 May 2012 16:51:37 +0000 User-Agent: Microsoft-MacOutlook/14.2.1.120420 Date: Wed, 09 May 2012 09:51:06 -0700 From: David Harrington To: Randy Presuhn , Message-ID: Thread-Topic: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 In-Reply-To: <001d01cd2dfd$8387bfe0$6b01a8c0@oemcomputer> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 16:51:48 -0000 +1 We should plan for reuse only when needed in the future. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 5/9/12 9:05 AM, "Randy Presuhn" wrote: >Hi - > >> From: "Bert Wijnen (IETF)" >> To: "Alexey Melnikov" ; >> >> Cc: >> Sent: Wednesday, May 09, 2012 8:03 AM >> Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise >>Numbers registry: draft-liang-iana-pen-00 >... >> How can we be assured that the once assigned PEN is not being used >> anywhere in the digital world? What is someone is still using it in >> some obsoleted/no-longer-supported product? Should he/she run the >> risk that it conflicts with a possible new assignment/allocation? > >Agreed. Even if the assignee never used the arc, we have no way of >knowing >whether someone else has built knowledge of that one-time assignment >into a product. > >Randy > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area From dromasca@avaya.com Thu May 10 01:44:11 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB1321F85D9 for ; Thu, 10 May 2012 01:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j20iLNwlsLgL for ; Thu, 10 May 2012 01:44:11 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0179821F85C6 for ; Thu, 10 May 2012 01:44:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHZ/q0+HCzI1/2dsb2JhbABBA7EfAYIWgQeCDAEBAQEDAQEBDx4KNBcEAgEIDQQEAQEBCgYMBwQBBgEmHwkIAQEEEwgah14DCwudZ5NICIlUBIsNgn4FgkNjBJwUiimCaw X-IronPort-AV: E=Sophos;i="4.75,564,1330923600"; d="scan'208";a="8508500" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 May 2012 04:44:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 May 2012 04:26:51 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 May 2012 10:44:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 Thread-Index: Ac0uBAqYQKR1HLDRQDWnOFvcJgH/9gAhPmdg References: <001d01cd2dfd$8387bfe0$6b01a8c0@oemcomputer> From: "Romascanu, Dan (Dan)" To: Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 08:44:12 -0000 +1 Dan > -----Original Message----- > From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On > Behalf Of David Harrington > Sent: Wednesday, May 09, 2012 7:51 PM > To: Randy Presuhn; ops-area@ietf.org > Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise > Numbers registry: draft-liang-iana-pen-00 >=20 > +1 >=20 > We should plan for reuse only when needed in the future. > -- > David Harrington > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 5/9/12 9:05 AM, "Randy Presuhn" > wrote: >=20 > >Hi - > > > >> From: "Bert Wijnen (IETF)" > >> To: "Alexey Melnikov" ; > >> > >> Cc: > >> Sent: Wednesday, May 09, 2012 8:03 AM > >> Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise > >>Numbers registry: draft-liang-iana-pen-00 > >... > >> How can we be assured that the once assigned PEN is not being used > >> anywhere in the digital world? What is someone is still using it in > >> some obsoleted/no-longer-supported product? Should he/she run the > >> risk that it conflicts with a possible new assignment/allocation? > > > >Agreed. Even if the assignee never used the arc, we have no way of > >knowing > >whether someone else has built knowledge of that one-time assignment > >into a product. > > > >Randy > > > >_______________________________________________ > >OPS-AREA mailing list > >OPS-AREA@ietf.org > >https://www.ietf.org/mailman/listinfo/ops-area >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From bclaise@cisco.com Fri May 11 03:31:01 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091FD21F85DD for ; Fri, 11 May 2012 03:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.806 X-Spam-Level: X-Spam-Status: No, score=-7.806 tagged_above=-999 required=5 tests=[AWL=2.793, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMEmrSW7C8vU for ; Fri, 11 May 2012 03:31:00 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEDA21F85A4 for ; Fri, 11 May 2012 03:31:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4BAUuV0009125; Fri, 11 May 2012 12:30:56 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4BAUtsq009352; Fri, 11 May 2012 12:30:56 +0200 (CEST) Message-ID: <4FACEA5F.9080609@cisco.com> Date: Fri, 11 May 2012 12:30:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <001d01cd2dfd$8387bfe0$6b01a8c0@oemcomputer> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 10:31:01 -0000 +1 Regards, Benoit. > +1 > > Dan > > > > >> -----Original Message----- >> From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On >> Behalf Of David Harrington >> Sent: Wednesday, May 09, 2012 7:51 PM >> To: Randy Presuhn; ops-area@ietf.org >> Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise >> Numbers registry: draft-liang-iana-pen-00 >> >> +1 >> >> We should plan for reuse only when needed in the future. >> -- >> David Harrington >> Internet Engineering Task Force (IETF) >> Ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> >> >> >> On 5/9/12 9:05 AM, "Randy Presuhn" >> wrote: >> >>> Hi - >>> >>>> From: "Bert Wijnen (IETF)" >>>> To: "Alexey Melnikov"; >>>> >>>> Cc: >>>> Sent: Wednesday, May 09, 2012 8:03 AM >>>> Subject: Re: [OPS-AREA] Documenting rules for the Private > Enterprise >>>> Numbers registry: draft-liang-iana-pen-00 >>> ... >>>> How can we be assured that the once assigned PEN is not being used >>>> anywhere in the digital world? What is someone is still using it in >>>> some obsoleted/no-longer-supported product? Should he/she run the >>>> risk that it conflicts with a possible new assignment/allocation? >>> Agreed. Even if the assignee never used the arc, we have no way of >>> knowing >>> whether someone else has built knowledge of that one-time assignment >>> into a product. >>> >>> Randy >>> >>> _______________________________________________ >>> OPS-AREA mailing list >>> OPS-AREA@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-area >> >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > From bclaise@cisco.com Fri May 11 03:34:29 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7140521F85A4 for ; Fri, 11 May 2012 03:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.87 X-Spam-Level: X-Spam-Status: No, score=-7.87 tagged_above=-999 required=5 tests=[AWL=2.728, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0bv1brBA8c2 for ; Fri, 11 May 2012 03:34:26 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C9DDA21F8469 for ; Fri, 11 May 2012 03:34:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4BAYOfc009552; Fri, 11 May 2012 12:34:24 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4BAYONA011793; Fri, 11 May 2012 12:34:24 +0200 (CEST) Message-ID: <4FACEB2F.70007@cisco.com> Date: Fri, 11 May 2012 12:34:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4FA98384.8090805@isode.com> In-Reply-To: <4FA98384.8090805@isode.com> Content-Type: multipart/alternative; boundary="------------020905020309030107090406" Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 10:34:29 -0000 This is a multi-part message in MIME format. --------------020905020309030107090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alexey, First of all, I appreciate your draft, which wants to formalize the PEN allocation process. One comment below. > Hi, > Benoit suggested that I post this email message here. > > draft-liang-iana-pen is trying to formalize and document rules for the > Private Enterprise Numbers registry > . In particular > the purpose of this document is to document > a) what is allowed to be registered (what characters should be allowed > in an Enterprise name, what is an Enterprise) > b) under what conditions an entry can be changed and what kind of > documentation is required. > > The document is being worked on by IANA (Pearl with some help from > Michelle), I was asked to help out. While the document is mostly > documenting existing practice, it is also trying to specify some rules > about how the registry is to be operated, because certain (most?) > things were never written down. > > Pearl and I will appreciate reviews and feedback on the document. One > of the major issues is currently outstanding is "what is considered to > be an Enterprise?". While Universities and non profit organizations > are considered Enterprises, it is not very clear whether different > departments of a University, or subsidiaries of the same bank in > different countries are considered to be different enterprises or not. > A more difficult case is whether to allow different products from the > same vendor to be allocated different PENs. > Yet another example is allocation of special PENs for RFCs (e.g. RFC > 5103.html, section 6.1). Is this Ok? Since you discuss PENs, that would great to have some more guidelines on how the PENs should and _should not_ be used. So this RFC5103 example should be discussed. Regards, Benoit. > (All of these are examples of what people asked to register.) As > currently there is no guidelines, there is no way for IANA to say "no". > > Somewhat related to this: another position might be that there are > enough PENs for everyone and that there is really no need to be > restrictive in the case of this registry. > > Any feedback would be appreciated. > > Thank you, > Alexey > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > --------------020905020309030107090406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alexey,

First of all, I appreciate your draft, which wants to formalize the PEN allocation process.
One comment below.
Hi,
Benoit suggested that I post this email message here.

draft-liang-iana-pen is trying to formalize and document rules for the Private Enterprise Numbers registry <http://www.iana.org/assignments/enterprise-numbers>. In particular the purpose of this document is to document
a) what is allowed to be registered (what characters should be allowed in an Enterprise name, what is an Enterprise)
b) under what conditions an entry can be changed and what kind of documentation is required.

The document is being worked on by IANA (Pearl with some help from Michelle), I was asked to help out. While the document is mostly documenting existing practice, it is also trying to specify some rules about how the registry is to be operated, because certain (most?) things were never written down.

Pearl and I will appreciate reviews and feedback on the document. One of the major issues is currently outstanding is "what is considered to be an Enterprise?". While Universities and non profit organizations are considered Enterprises, it is not very clear whether different departments of a University, or subsidiaries of the same bank in different countries are considered to be different enterprises or not. A more difficult case is whether to allow different products from the same vendor to be allocated different PENs.
Yet another example is allocation of special PENs for RFCs (e.g. RFC 5103.html, section  6.1). Is this Ok?
Since you discuss PENs, that would great to have some more guidelines on how the PENs should and should not be used. So this RFC5103 example should be discussed.

Regards, Benoit.
(All of these are examples of what people asked to register.) As currently there is no guidelines, there is no way for IANA to say "no".

Somewhat related to this: another position might be that there are enough PENs for everyone and that there is really no need to be restrictive in the case of this registry.

Any feedback would be appreciated.

Thank you,
Alexey


_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area



--------------020905020309030107090406-- From dromasca@avaya.com Wed May 23 08:05:20 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B02D21F8713 for ; Wed, 23 May 2012 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3W31jlT1bX8 for ; Wed, 23 May 2012 08:05:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 71FCD21F8704 for ; Wed, 23 May 2012 08:05:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKb7vE/GmAcF/2dsb2JhbABEtDWBB4IXAQEDEh4KPxIBFRUGDAwHVwEEGxqHbJ1RnQyLIwGCDYI8YgObDYl/gmyBVAE X-IronPort-AV: E=Sophos;i="4.75,645,1330923600"; d="scan'208";a="307791298" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 May 2012 11:03:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 May 2012 11:03:04 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 May 2012 17:05:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: assumption about number of octets encoding PENs Thread-Index: Ac049W+mrneTybIQTcm2ihG2USp/hg== From: "Romascanu, Dan (Dan)" To: Cc: Alexey Melnikov , Alan DeKok , pearl.liang@icann.org Subject: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:05:20 -0000 This is related to draft-liang-iana-pen-00 and draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest defines new Vendor-Id fields in a way consistent with RFC 2865, which used three octets. However, in draft-liang-iana-pen-00 we say that a PEN is a non-negative integer, which I think assumes (0..2**32-1) range.=20 Questions:=20 - is there any place where a limit is defined?=20 - should we advice new documents to cautiously define 32 bits (at least) for Vendor-Id fields?=20 - should we say something on this respect in draft-liang-iana-pen? What will happen to RFC 2865 implementations (and maybe other protocols) that assumed Vendor-Id is limited to three octets - this will probably need to be dealt by the RADEXT WG.=20 Regards, Dan From mark@ellisonsoftware.com Wed May 23 08:13:44 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4352521F873A for ; Wed, 23 May 2012 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.676 X-Spam-Level: X-Spam-Status: No, score=-100.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z1UNIR6X+VZ for ; Wed, 23 May 2012 08:13:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A39BC21F8715 for ; Wed, 23 May 2012 08:13:43 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so13808832obb.31 for ; Wed, 23 May 2012 08:13:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=eJi13VIbTDx9P99TewsosizOKlCel6BaQhoyYanVE08=; b=o7DSRDOreJtwwCFsDwqE6ihCzp+GRjEaK0hGDs3EzcFM0WUJxVZWHzX7r4gDAFq7+F EDJ+3/y6ObGzlZinMCi+JxPNBwctCHYUFpX51vHAy9j7VGL58ZotndrM3KA78pQl1LxE gb13a2kYKoDDxwMOjIPQPG5/Je/tiVO0QHJoGr5XwobbXaJ/F9UVEG+ULwNSnrf/5/xf GwH39WsKFim5izTemojrcTTt3JR4IaYNYsK1sVlMGkrLfFXK05ktpHbnBTRm1+Xfgt1N QnY0DNffQTKR5qRs1WJHZB00Ukxpwn2CjnTuKT6T+ieebLerSHdH5Sz7rZWxdduFMcRP gHug== MIME-Version: 1.0 Received: by 10.182.146.84 with SMTP id ta20mr17717966obb.19.1337786023042; Wed, 23 May 2012 08:13:43 -0700 (PDT) Sender: mark@ellisonsoftware.com Received: by 10.182.111.2 with HTTP; Wed, 23 May 2012 08:13:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 May 2012 11:13:43 -0400 X-Google-Sender-Auth: FnEHwWWBLiPG_Vlzw8SsDXK1byc Message-ID: From: Mark Ellison To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=f46d0444ed0bb05e9a04c0b5945f X-Gm-Message-State: ALoCoQlVKQ4qTwlPIiazSg5aIXE5NhVqrFJu3iwqxcepiDhhuPFTVWvHVKKeQdsEmjB7c/CJ+D+H Cc: Alexey Melnikov , pearl.liang@icann.org, Alan DeKok , ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:13:44 -0000 --f46d0444ed0bb05e9a04c0b5945f Content-Type: text/plain; charset=ISO-8859-1 Dan, Here is one reference point: The SnmpEngineID TC as defined in RFC3411 reserves 4 octets for the PEN, but then takes the high order bit for a different purpose. This essentially leaves 31 usable bits for a PEN within the SnmpEngineID. Regards, Mark On Wed, May 23, 2012 at 11:05 AM, Romascanu, Dan (Dan) wrote: > This is related to draft-liang-iana-pen-00 and > draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest > defines new Vendor-Id fields in a way consistent with RFC 2865, which > used three octets. However, in draft-liang-iana-pen-00 we say that a PEN > is a non-negative integer, which I think assumes (0..2**32-1) range. > > Questions: > > - is there any place where a limit is defined? > - should we advice new documents to cautiously define 32 bits (at least) > for Vendor-Id fields? > - should we say something on this respect in draft-liang-iana-pen? > > What will happen to RFC 2865 implementations (and maybe other protocols) > that assumed Vendor-Id is limited to three octets - this will probably > need to be dealt by the RADEXT WG. > > Regards, > > Dan > > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > --f46d0444ed0bb05e9a04c0b5945f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dan,

Here is one reference point:

The SnmpEngineID TC as defined in RFC3411 reserves 4 octets for the PEN,= but then takes the high order bit for a different purpose. =A0This essenti= ally leaves 31 usable bits for a PEN within the SnmpEngineID.

Regards,

Mark

On Wed, May 23, 2012 at 11:05 AM, Romascanu, Dan (Dan) <dromas= ca@avaya.com> wrote:
This is related to draft-liang-iana-pen-00 a= nd
draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest
defines new Vendor-Id fields in a way consistent with RFC 2865, which
used three octets. However, in draft-liang-iana-pen-00 we say that a PEN is a non-negative integer, which I think assumes (0..2**32-1) range.

Questions:

- is there any place where a limit is defined?
- should we advice new documents to cautiously define 32 bits (at least) for Vendor-Id fields?
- should we say something on this respect in draft-liang-iana-pen?

What will happen to RFC 2865 implementations (and maybe other protocols) that assumed Vendor-Id is limited to three octets - this will probably
need to be dealt by the RADEXT WG.

Regards,

Dan





_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area





--f46d0444ed0bb05e9a04c0b5945f-- From dromasca@avaya.com Wed May 23 08:15:40 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F15E21F8603 for ; Wed, 23 May 2012 08:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l8nctHhQ0sW for ; Wed, 23 May 2012 08:15:38 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC4621F8604 for ; Wed, 23 May 2012 08:15:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOb9vE/GmAcF/2dsb2JhbABEgkWxcYEHghUBAQEBAwEBAQ8KEQM+CxACAQgNBAQBAQsGDAsBBgEmHwkIAQEEEwgah2wLnUedCASLDxQBhEliA5sNiX+CbIFUAQ X-IronPort-AV: E=Sophos;i="4.75,645,1330923600"; d="scan'208,217";a="349127148" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 May 2012 11:13:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 May 2012 11:13:32 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD38F6.E67D85E2" Date: Wed, 23 May 2012 17:15:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs Thread-Index: Ac049qZZ2E8ogGwOSkmIS12/BWGv8AAABEZA References: From: "Romascanu, Dan (Dan)" To: "Mark Ellison" Cc: Alexey Melnikov , pearl.liang@icann.org, Alan DeKok , ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:15:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD38F6.E67D85E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, with all due respect to SNMP, it is yet another protocol using PENs, isn't it? J =20 =20 From: mark@ellisonsoftware.com [mailto:mark@ellisonsoftware.com] On Behalf Of Mark Ellison Sent: Wednesday, May 23, 2012 6:14 PM To: Romascanu, Dan (Dan) Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang@icann.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs =20 Dan, =20 Here is one reference point: =20 The SnmpEngineID TC as defined in RFC3411 reserves 4 octets for the PEN, but then takes the high order bit for a different purpose. This essentially leaves 31 usable bits for a PEN within the SnmpEngineID. Regards, =20 Mark =20 On Wed, May 23, 2012 at 11:05 AM, Romascanu, Dan (Dan) wrote: This is related to draft-liang-iana-pen-00 and draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest defines new Vendor-Id fields in a way consistent with RFC 2865, which used three octets. However, in draft-liang-iana-pen-00 we say that a PEN is a non-negative integer, which I think assumes (0..2**32-1) range. Questions: - is there any place where a limit is defined? - should we advice new documents to cautiously define 32 bits (at least) for Vendor-Id fields? - should we say something on this respect in draft-liang-iana-pen? What will happen to RFC 2865 implementations (and maybe other protocols) that assumed Vendor-Id is limited to three octets - this will probably need to be dealt by the RADEXT WG. Regards, Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area =20 =20 ------_=_NextPart_001_01CD38F6.E67D85E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, with all due respect to SNMP, it is yet another protocol using = PENs, isn’t it? J

 

 

From:= = mark@ellisonsoftware.com [mailto:mark@ellisonsoftware.com] On Behalf = Of Mark Ellison
Sent: Wednesday, May 23, 2012 6:14 = PM
To: Romascanu, Dan (Dan)
Cc: ops-area@ietf.org; = Alexey Melnikov; Alan DeKok; pearl.liang@icann.org
Subject: = Re: [OPS-AREA] assumption about number of octets encoding = PENs

 

Dan,

 

Here is one reference = point:

 

The SnmpEngineID TC as defined in RFC3411 reserves 4 = octets for the PEN, but then takes the high order bit for a different = purpose.  This essentially leaves 31 usable bits for a PEN within = the SnmpEngineID.

Regards,

 

Mark

 

On Wed, = May 23, 2012 at 11:05 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

This is related to draft-liang-iana-pen-00 = and
draft-ietf-radext-radius-extensions-05.txt now in WGLC. The = latest
defines new Vendor-Id fields in a way consistent with RFC = 2865, which
used three octets. However, in draft-liang-iana-pen-00 we = say that a PEN
is a non-negative integer, which I think assumes = (0..2**32-1) range.

Questions:

- is there any place where = a limit is defined?
- should we advice new documents to cautiously = define 32 bits (at least)
for Vendor-Id fields?
- should we say = something on this respect in draft-liang-iana-pen?

What will = happen to RFC 2865 implementations (and maybe other protocols)
that = assumed Vendor-Id is limited to three octets - this will = probably
need to be dealt by the RADEXT = WG.

Regards,

Dan





___________________= ____________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area=



 

 

------_=_NextPart_001_01CD38F6.E67D85E2-- From bclaise@cisco.com Wed May 23 08:18:52 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5D421F872A for ; Wed, 23 May 2012 08:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEpON8YwwjJ7 for ; Wed, 23 May 2012 08:18:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5C19521F85D7 for ; Wed, 23 May 2012 08:18:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4NFIKZp008067; Wed, 23 May 2012 17:18:20 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4NFIJAf021497; Wed, 23 May 2012 17:18:19 +0200 (CEST) Message-ID: <4FBCFFBB.6040300@cisco.com> Date: Wed, 23 May 2012 17:18:19 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020308000202080408060806" Cc: Alexey Melnikov , pearl.liang@icann.org, Alan DeKok , ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:18:52 -0000 This is a multi-part message in MIME format. --------------020308000202080408060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Since we're discussing PENs, I have another some more I would like to see addressed in draft-liang-iana-pen-00. - What about unassigned PENs? See the part in red in my DISCUSS on https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ (on the telechat this Thursday) - PEN are not always representing manufacturer ID -The term "vendor" is confusing Vendor ID The Vendor ID is the SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [SMI]. The example in figure 1 speaks about: "Operator-Id: provider2.example.com" Vendor Id, in the network management world is the manufacturer id, while you're after the Operator-Id I see what you want to do, but this is confusing. Also, do we expect that all operators will have Private Enterprise Number? Maybe you want to redefine this with something such as (I trust you on the right wording) Operator PEN ID SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [SMI] for the operator running ... [actually running what, that's another required clarification in the draft] ... the respective interface on mobile access gateway? In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by "Operator PEN ID" And also add a few sentences about - whether all operators should or must now register new PENs for this spec. I checked for a couple of my local ISPs, and not all of them had a PEN. -if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used if "SHOULD NOT", what should be default? Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0? You want to discuss with the authors of draft-liang-iana-pen-00, be in synch with them. Regards, Benoit. > This is related to draft-liang-iana-pen-00 and > draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest > defines new Vendor-Id fields in a way consistent with RFC 2865, which > used three octets. However, in draft-liang-iana-pen-00 we say that a PEN > is a non-negative integer, which I think assumes (0..2**32-1) range. > > Questions: > > - is there any place where a limit is defined? > - should we advice new documents to cautiously define 32 bits (at least) > for Vendor-Id fields? > - should we say something on this respect in draft-liang-iana-pen? > > What will happen to RFC 2865 implementations (and maybe other protocols) > that assumed Vendor-Id is limited to three octets - this will probably > need to be dealt by the RADEXT WG. > > Regards, > > Dan > > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > --------------020308000202080408060806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Since we're discussing PENs, I have another some more I would like to see addressed in draft-liang-iana-pen-00.
    - What about unassigned PENs? See the part in red in my DISCUSS on https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ (on the telechat this Thursday)
    - PEN are not always representing manufacturer ID

-The term "vendor" is confusing

   Vendor ID

      The Vendor ID is the SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI].

The example in figure 1 speaks about: "Operator-Id: provider2.example.com"
Vendor Id, in the network management world is the manufacturer id, while you're
after the Operator-Id
I see what you want to do, but this is confusing. Also, do
we expect that all operators will have Private Enterprise Number?

Maybe you want to redefine this with something such as (I trust you on the right
wording)

   Operator PEN ID

      SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI] for the operator running ... [actually running what, that's another 
      required clarification in the draft] ... the respective interface on mobile access gateway?

In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by
"Operator PEN ID"

And also add a few sentences about
- whether all operators should or must now register new PENs for this spec.
  I checked for a couple of my local ISPs, and
not all of them had a PEN.
- if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used
    if "SHOULD NOT", what should be default?
Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
You want to discuss with the authors of draft-liang-iana-pen-00, be in synch
with them.
Regards, Benoit.

This is related to draft-liang-iana-pen-00 and
draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest
defines new Vendor-Id fields in a way consistent with RFC 2865, which
used three octets. However, in draft-liang-iana-pen-00 we say that a PEN
is a non-negative integer, which I think assumes (0..2**32-1) range. 

Questions: 

- is there any place where a limit is defined? 
- should we advice new documents to cautiously define 32 bits (at least)
for Vendor-Id fields? 
- should we say something on this respect in draft-liang-iana-pen?

What will happen to RFC 2865 implementations (and maybe other protocols)
that assumed Vendor-Id is limited to three octets - this will probably
need to be dealt by the RADEXT WG. 

Regards,

Dan





_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

--------------020308000202080408060806-- From dromasca@avaya.com Wed May 23 09:18:31 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26AE21F873D for ; Wed, 23 May 2012 09:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPyPshfk0pHJ for ; Wed, 23 May 2012 09:18:29 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7590821F872E for ; Wed, 23 May 2012 09:18:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABsNvU+HCzI1/2dsb2JhbABDgkWxcYEHghUBAQEBAwEBAQ8KEQM+CxACAQgNAQMEAQELBgwLAQYBJh8JCAEBBBMIGodsC51nnQWLDxQBhEliA5YrhGKJf4JsgVQB X-IronPort-AV: E=Sophos;i="4.75,645,1330923600"; d="scan'208,217";a="349140822" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 May 2012 12:16:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 May 2012 12:00:36 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD38FF.ABD60DA6" Date: Wed, 23 May 2012 18:18:20 +0200 Message-ID: In-Reply-To: <4FBCFFBB.6040300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs Thread-Index: Ac0490vNXDUpiPi9QnegZDt3YXpMFgACBGuw References: <4FBCFFBB.6040300@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: pearl.liang@icann.org, ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 16:18:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD38FF.ABD60DA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does this change anything in draft-liang-iana-pen? I do not see the I-D assuming the Enterprise is a Vendor - this is rather something that some protocol documents using PENs did.=20 =20 Dan =20 =20 =20 From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Wednesday, May 23, 2012 6:18 PM To: Romascanu, Dan (Dan) Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang@icann.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs =20 Hi, Since we're discussing PENs, I have another some more I would like to see addressed in draft-liang-iana-pen-00. - What about unassigned PENs? See the part in red in my DISCUSS on https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option / (on the telechat this Thursday) - PEN are not always representing manufacturer ID -The term "vendor" is confusing =20 Vendor ID =20 The Vendor ID is the SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [SMI]. =20 The example in figure 1 speaks about: "Operator-Id: provider2.example.com" Vendor Id, in the network management world is the manufacturer id, while you're after the Operator-Id I see what you want to do, but this is confusing. Also, do we expect that all operators will have Private Enterprise Number? =20 Maybe you want to redefine this with something such as (I trust you on the right wording) =20 Operator PEN ID =20 SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [SMI] for the operator running ... [actually running what, that's another=20 required clarification in the draft] ... the respective interface on mobile access gateway? =20 In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by "Operator PEN ID" =20 And also add a few sentences about - whether all operators should or must now register new PENs for this spec. I checked for a couple of my local ISPs, and not all of them had a PEN. - if there is no PEN Operator ID, then ANI type=3D 3, Op-ID=3D2 MUST NOT/SHOULD NOT be used if "SHOULD NOT", what should be default? Operator PEN ID=3D8653? (not even sure if this is the right thing to do) or 0? You want to discuss with the authors of draft-liang-iana-pen-00, be in synch with them. Regards, Benoit. This is related to draft-liang-iana-pen-00 and draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest defines new Vendor-Id fields in a way consistent with RFC 2865, which used three octets. However, in draft-liang-iana-pen-00 we say that a PEN is a non-negative integer, which I think assumes (0..2**32-1) range.=20 =20 Questions:=20 =20 - is there any place where a limit is defined?=20 - should we advice new documents to cautiously define 32 bits (at least) for Vendor-Id fields?=20 - should we say something on this respect in draft-liang-iana-pen? =20 What will happen to RFC 2865 implementations (and maybe other protocols) that assumed Vendor-Id is limited to three octets - this will probably need to be dealt by the RADEXT WG.=20 =20 Regards, =20 Dan =20 =20 =20 =20 =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area =20 =20 =20 ------_=_NextPart_001_01CD38FF.ABD60DA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does this change anything in draft-liang-iana-pen? I do not = see the I-D assuming the Enterprise is a Vendor – this is rather = something that some protocol documents using PENs did.

 

Dan

 

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: = Wednesday, May 23, 2012 6:18 PM
To: Romascanu, Dan = (Dan)
Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok; = pearl.liang@icann.org
Subject: Re: [OPS-AREA] assumption about = number of octets encoding PENs

 

Hi,

Since we're discussing PENs, I = have another some more I would like to see addressed in = draft-liang-iana-pen-00.
    - What about unassigned = PENs? See the part in red in my DISCUSS on https://datatracker.ietf.org/doc/draft-ietf-netext-access-netwo= rk-option/ (on the telechat this Thursday)
    - = PEN are not always representing manufacturer ID

-The =
term "vendor" is =
confusing
 
   =
Vendor =
ID
 
   &nb=
sp;  The Vendor ID is the SMI Network Management Private =
Enterprise
      Code of =
the IANA-maintained Private Enterprise Numbers =
registry
      =
[SMI].
 
The example in =
figure 1 speaks about: "Operator-Id: =
provider2.example.com"
Vendor Id, in the =
network management world is the manufacturer id, while =
you're
after the Operator-Id
I =
see what you want to do, but this is confusing. Also, =
do
we expect that all operators will have Private =
Enterprise =
Number?
 
Maybe you want =
to redefine this with something such as (I trust you on the =
right
wording)
 
   Operator PEN =
ID
 
   &nb=
sp;  SMI Network Management Private =
Enterprise
      Code of =
the IANA-maintained Private Enterprise Numbers =
registry
      [SMI] for =
the operator running ... [actually running what, that's another =

      required =
clarification in the draft] ... the respective interface on mobile =
access gateway?
 
In =
section 3.1.3 (and some other places such as IANA), change "Vendor =
ID" by
"Operator PEN =
ID"
 
And also add a =
few sentences about
- whether all operators should =
or must now register new PENs for this spec.
  =
I checked for a couple of my local ISPs, and
not =
all of them had a PEN.
- if there is no PEN Operator ID, then ANI type=3D 3, =
Op-ID=3D2 MUST NOT/SHOULD NOT be used
    if "SHOULD NOT", what =
should be default?
Operator PEN ID=3D8653? (not even sure if this is =
the right thing to do) or 0?
You want to discuss with the authors of =
draft-liang-iana-pen-00, be in synch
with them.

Regards, Benoit.


This =
is related to draft-liang-iana-pen-00 =
and
draft-ietf-radext-radius-extensions-05.txt now =
in WGLC. The latest
defines new Vendor-Id fields in =
a way consistent with RFC 2865, which
used three =
octets. However, in draft-liang-iana-pen-00 we say that a =
PEN
is a non-negative integer, which I think =
assumes (0..2**32-1) range. =

 
Questions: =

 
- is there any place =
where a limit is defined? 
- should we advice new =
documents to cautiously define 32 bits (at =
least)
for Vendor-Id fields? =

- should we say something on this respect in =
draft-liang-iana-pen?
 
Wh=
at will happen to RFC 2865 implementations (and maybe other =
protocols)
that assumed Vendor-Id is limited to =
three octets - this will probably
need to be dealt =
by the RADEXT WG. =

 
Regards,
 
Dan
 
 
 
 
 
___________________=
____________________________
OPS-AREA mailing =
list
OPS-AREA@ietf.org
<=
pre>https://www.ietf.=
org/mailman/listinfo/ops-area
 <=
/pre>
 
 
------_=_NextPart_001_01CD38FF.ABD60DA6-- From alexey.melnikov@isode.com Wed May 23 09:48:45 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3FF21F862B for ; Wed, 23 May 2012 09:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.196 X-Spam-Level: X-Spam-Status: No, score=-100.196 tagged_above=-999 required=5 tests=[AWL=-1.293, BAYES_00=-2.599, MANGLED_PENIS=2.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJPUK0j2xkc9 for ; Wed, 23 May 2012 09:48:44 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E68821F863F for ; Wed, 23 May 2012 09:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337791723; d=isode.com; s=selector; i=@isode.com; bh=wEdWvcnQztPpBijb2XVJtiHXc7erkiKK2ktSMuk0Fow=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=DRH0UEXJHuQ1Ffr2idZBu0taAhG/6edEKOlkreRD25wyCyLnl+9CvmfB6UBS69ET6NWIqW HFWkda5/orFU3FtALLMDF/59vPYerV9q7sX1p4i0ynBoD/rwo1upTb0JZLlMxsfgU2CmDY 8gvkssc4fsmohNDA3IMLJEt49Q9hsTE=; Received: from [188.29.106.235] (188.29.106.235.threembb.co.uk [188.29.106.235]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 23 May 2012 17:48:43 +0100 References: In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Wed, 23 May 2012 17:48:42 +0100 To: "Romascanu, Dan (Dan)" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "" , Alan DeKok , "" Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 16:48:45 -0000 Hi Dan, On 23 May 2012, at 16:05, "Romascanu, Dan (Dan)" wrote:= > This is related to draft-liang-iana-pen-00 and > draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest > defines new Vendor-Id fields in a way consistent with RFC 2865, which > used three octets. However, in draft-liang-iana-pen-00 we say that a PEN > is a non-negative integer, which I think assumes (0..2**32-1) range.=20 Not necessarily, see below. >=20 > Questions:=20 >=20 > - is there any place where a limit is defined?=20 I believe that OID definition explicitly don't have an upper boundary on int= egers. I don't know if any IETF RFC specifies additional constraints. > - should we advice new documents to cautiously define 32 bits (at least) > for Vendor-Id fields?=20 I think that would be a good idea, yes. > - should we say something on this respect in draft-liang-iana-pen? I think so. > What will happen to RFC 2865 implementations (and maybe other protocols) > that assumed Vendor-Id is limited to three octets Probably sufficient in medium term. > - this will probably > need to be dealt by the RADEXT WG.=20 >=20 > Regards, >=20 > Dan From randy_presuhn@mindspring.com Wed May 23 10:46:48 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB021F871E for ; Wed, 23 May 2012 10:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdzefV7d4mrl for ; Wed, 23 May 2012 10:46:47 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49C21F86EC for ; Wed, 23 May 2012 10:46:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iske0kZwkT8BwO1F7mcgJh8MdICKeS1ZJ1OhC8zdj2FY2aih180Me8sJikxOpspn; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.146.105] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXFdN-0001OX-Q8; Wed, 23 May 2012 13:46:06 -0400 Message-ID: <003501cd390c$4747efe0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Alexey Melnikov" , "Romascanu, Dan \(Dan\)" References: Date: Wed, 23 May 2012 10:48:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f883eed0c89b46d67f7fb32bf6c7dfbc75a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.146.105 Cc: pearl.liang@icann.org, ops-area@ietf.org, Alan DeKok Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 17:46:48 -0000 Hi - > From: "Alexey Melnikov" > To: "Romascanu, Dan (Dan)" > Cc: ; "Alan DeKok" ; > Sent: Wednesday, May 23, 2012 9:48 AM > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs ... > I believe that OID definition explicitly don't have an upper boundary on integers. > I don't know if any IETF RFC specifies additional constraints. RFC 2578 (SMIv2) imposes additional constraints beyond those in ASN.1: | 3.5. OBJECT IDENTIFIER values | | An OBJECT IDENTIFIER value is an ordered list of non-negative | numbers. For the SMIv2, each number in the list is referred to as a | sub-identifier, there are at most 128 sub-identifiers in a value, and | each sub-identifier has a maximum value of 2^32-1 (4294967295 | decimal). Randy From dromasca@avaya.com Wed May 23 10:50:49 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DA721F86EB for ; Wed, 23 May 2012 10:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMJ8mR0TQga7 for ; Wed, 23 May 2012 10:50:47 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1D93821F86DD for ; Wed, 23 May 2012 10:50:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO0ivU+HCzI1/2dsb2JhbABDtCyBB4IVAQEBAQMSHgo/DAQCAQgNBAQBAQsGDAsBBgFFCQgBAQQBEggah2ueAZx6in0VhCtgA5sJiX+CbIFV X-IronPort-AV: E=Sophos;i="4.75,645,1330923600"; d="scan'208";a="10697416" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 May 2012 13:48:47 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 May 2012 13:32:41 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 May 2012 19:50:25 +0200 Message-ID: In-Reply-To: <003501cd390c$4747efe0$6b01a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs Thread-Index: Ac05DBgyeIfR2czdRlKWIK+O/+iP/QAACKZg References: <003501cd390c$4747efe0$6b01a8c0@oemcomputer> From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Alexey Melnikov" Cc: pearl.liang@icann.org, ops-area@ietf.org, Alan DeKok Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 17:50:50 -0000 So this is an indirect answer. As PENs where originally designed to be part of an OID, what results is that the upper limit is 2**32-1. Should we say this explicitly in the future RFC?=20 Dan > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, May 23, 2012 8:49 PM > To: Alexey Melnikov; Romascanu, Dan (Dan) > Cc: pearl.liang@icann.org; Alan DeKok; ops-area@ietf.org > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs >=20 > Hi - >=20 > > From: "Alexey Melnikov" > > To: "Romascanu, Dan (Dan)" > > Cc: ; "Alan DeKok" > ; > > Sent: Wednesday, May 23, 2012 9:48 AM > > Subject: Re: [OPS-AREA] assumption about number of octets encoding > PENs > ... > > I believe that OID definition explicitly don't have an upper boundary > on integers. > > I don't know if any IETF RFC specifies additional constraints. >=20 > RFC 2578 (SMIv2) imposes additional constraints beyond those in ASN.1: >=20 > | 3.5. OBJECT IDENTIFIER values > | > | An OBJECT IDENTIFIER value is an ordered list of non-negative > | numbers. For the SMIv2, each number in the list is referred to as > a > | sub-identifier, there are at most 128 sub-identifiers in a value, > and > | each sub-identifier has a maximum value of 2^32-1 (4294967295 > | decimal). >=20 > Randy From randy_presuhn@mindspring.com Wed May 23 10:58:12 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CAA21F8762 for ; Wed, 23 May 2012 10:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPSxtWdopt3Z for ; Wed, 23 May 2012 10:58:11 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id B903521F875E for ; Wed, 23 May 2012 10:58:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DsN5QnEI/vCn2FKXrPWZbDphlAO5EEMyNgTFlePklnr0S7ep3P+5/tQzKp1LOYOR; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:x-mimeole:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.146.105] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXFp1-0007zD-Rp; Wed, 23 May 2012 13:58:08 -0400 Message-ID: <005f01cd390d$f7b05920$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Romascanu, Dan \(Dan\)" , "Alexey Melnikov" References: <003501cd390c$4747efe0$6b01a8c0@oemcomputer> Date: Wed, 23 May 2012 11:00:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f882f732949d012f39bc0a733296ced972c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.146.105 Cc: pearl.liang@icann.org, ops-area@ietf.org, Alan DeKok Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 17:58:12 -0000 Hi - If those OIDs will ever need to be carried around by SNMP, I think the answer is yes. If they won't, then the question remains open, I think. Randy ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" ; "Alexey Melnikov" Cc: ; "Alan DeKok" ; Sent: Wednesday, May 23, 2012 10:50 AM Subject: RE: [OPS-AREA] assumption about number of octets encoding PENs So this is an indirect answer. As PENs where originally designed to be part of an OID, what results is that the upper limit is 2**32-1. Should we say this explicitly in the future RFC? Dan > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, May 23, 2012 8:49 PM > To: Alexey Melnikov; Romascanu, Dan (Dan) > Cc: pearl.liang@icann.org; Alan DeKok; ops-area@ietf.org > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs > > Hi - > > > From: "Alexey Melnikov" > > To: "Romascanu, Dan (Dan)" > > Cc: ; "Alan DeKok" > ; > > Sent: Wednesday, May 23, 2012 9:48 AM > > Subject: Re: [OPS-AREA] assumption about number of octets encoding > PENs > ... > > I believe that OID definition explicitly don't have an upper boundary > on integers. > > I don't know if any IETF RFC specifies additional constraints. > > RFC 2578 (SMIv2) imposes additional constraints beyond those in ASN.1: > > | 3.5. OBJECT IDENTIFIER values > | > | An OBJECT IDENTIFIER value is an ordered list of non-negative > | numbers. For the SMIv2, each number in the list is referred to as > a > | sub-identifier, there are at most 128 sub-identifiers in a value, > and > | each sub-identifier has a maximum value of 2^32-1 (4294967295 > | decimal). > > Randy From bclaise@cisco.com Wed May 23 11:42:59 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E3B21F86C6 for ; Wed, 23 May 2012 11:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.349 X-Spam-Level: X-Spam-Status: No, score=-9.349 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PENIS=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-cHP5rlquFW for ; Wed, 23 May 2012 11:42:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3990E21F86B0 for ; Wed, 23 May 2012 11:42:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4NIgSBL028261; Wed, 23 May 2012 20:42:28 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4NIgRuh019230; Wed, 23 May 2012 20:42:27 +0200 (CEST) Message-ID: <4FBD2F93.6040602@cisco.com> Date: Wed, 23 May 2012 20:42:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4FBCFFBB.6040300@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010601060106070500030605" Cc: pearl.liang@icann.org, ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 18:42:59 -0000 This is a multi-part message in MIME format. --------------010601060106070500030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, > > Does this change anything in draft-liang-iana-pen? I do not see the > I-D assuming the Enterprise is a Vendor > Correct. By "PEN are not always representing manufacturer ID", I wanted to express that draft-liang-iana-pen could also cover a section on "PEN applicability". After all, the title says "Private Enterprise Number (PEN) _practices_ and registration procedures" Regards, Benoit. > > -- this is rather something that some protocol documents using PENs did. > > Dan > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Wednesday, May 23, 2012 6:18 PM > *To:* Romascanu, Dan (Dan) > *Cc:* ops-area@ietf.org; Alexey Melnikov; Alan DeKok; > pearl.liang@icann.org > *Subject:* Re: [OPS-AREA] assumption about number of octets encoding PENs > > Hi, > > Since we're discussing PENs, I have another some more I would like to > see addressed in draft-liang-iana-pen-00. > - What about unassigned PENs? See the part in red in my DISCUSS on > https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ > (on the telechat this Thursday) > - PEN are not always representing manufacturer ID > > -The term "vendor" is confusing > > Vendor ID > > The Vendor ID is the SMI Network Management Private Enterprise > Code of the IANA-maintained Private Enterprise Numbers registry > [SMI]. > > The example in figure 1 speaks about: "Operator-Id: provider2.example.com" > Vendor Id, in the network management world is the manufacturer id, while you're > after the Operator-Id > I see what you want to do, but this is confusing. Also, do > we expect that all operators will have Private Enterprise Number? > > Maybe you want to redefine this with something such as (I trust you on the right > wording) > > Operator PEN ID > > SMI Network Management Private Enterprise > Code of the IANA-maintained Private Enterprise Numbers registry > [SMI] for the operator running ... [actually running what, that's another > required clarification in the draft] ... the respective interface on mobile access gateway? > > In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by > "Operator PEN ID" > > And also add a few sentences about > - whether all operators should or must now register new PENs for this spec. > I checked for a couple of my local ISPs, and > not all of them had a PEN. > -if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used > if "SHOULD NOT", what should be default? > Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0? > You want to discuss with the authors of draft-liang-iana-pen-00, be in synch > with them. > > Regards, Benoit. > > > This is related to draft-liang-iana-pen-00 and > draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest > defines new Vendor-Id fields in a way consistent with RFC 2865, which > used three octets. However, in draft-liang-iana-pen-00 we say that a PEN > is a non-negative integer, which I think assumes (0..2**32-1) range. > > Questions: > > - is there any place where a limit is defined? > - should we advice new documents to cautiously define 32 bits (at least) > for Vendor-Id fields? > - should we say something on this respect in draft-liang-iana-pen? > > What will happen to RFC 2865 implementations (and maybe other protocols) > that assumed Vendor-Id is limited to three octets - this will probably > need to be dealt by the RADEXT WG. > > Regards, > > Dan > > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > > --------------010601060106070500030605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dan,

Does this change anything in draft-liang-iana-pen? I do not see the I-D assuming the Enterprise is a Vendor

Correct. By "PEN are not always representing manufacturer ID", I wanted to express that draft-liang-iana-pen could also cover a section on "PEN applicability". After all, the title says "Private Enterprise Number (PEN) practices and registration procedures"

Regards, Benoit.

– this is rather something that some protocol documents using PENs did.

 

Dan

 

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, May 23, 2012 6:18 PM
To: Romascanu, Dan (Dan)
Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang@icann.org
Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs

 

Hi,

Since we're discussing PENs, I have another some more I would like to see addressed in draft-liang-iana-pen-00.
    - What about unassigned PENs? See the part in red in my DISCUSS on https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ (on the telechat this Thursday)
    - PEN are not always representing manufacturer ID

-The term "vendor" is confusing
 
   Vendor ID
 
      The Vendor ID is the SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI].
 
The example in figure 1 speaks about: "Operator-Id: provider2.example.com"
Vendor Id, in the network management world is the manufacturer id, while you're
after the Operator-Id
I see what you want to do, but this is confusing. Also, do
we expect that all operators will have Private Enterprise Number?
 
Maybe you want to redefine this with something such as (I trust you on the right
wording)
 
   Operator PEN ID
 
      SMI Network Management Private Enterprise
      Code of the IANA-maintained Private Enterprise Numbers registry
      [SMI] for the operator running ... [actually running what, that's another 
      required clarification in the draft] ... the respective interface on mobile access gateway?
 
In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by
"Operator PEN ID"
 
And also add a few sentences about
- whether all operators should or must now register new PENs for this spec.
  I checked for a couple of my local ISPs, and
not all of them had a PEN.
- if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used
    if "SHOULD NOT", what should be default?
Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
You want to discuss with the authors of draft-liang-iana-pen-00, be in synch
with them.

Regards, Benoit.


This is related to draft-liang-iana-pen-00 and
draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest
defines new Vendor-Id fields in a way consistent with RFC 2865, which
used three octets. However, in draft-liang-iana-pen-00 we say that a PEN
is a non-negative integer, which I think assumes (0..2**32-1) range. 
 
Questions: 
 
- is there any place where a limit is defined? 
- should we advice new documents to cautiously define 32 bits (at least)
for Vendor-Id fields? 
- should we say something on this respect in draft-liang-iana-pen?
 
What will happen to RFC 2865 implementations (and maybe other protocols)
that assumed Vendor-Id is limited to three octets - this will probably
need to be dealt by the RADEXT WG. 
 
Regards,
 
Dan
 
 
 
 
 
_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
 
 

 


--------------010601060106070500030605-- From ietfdbh@comcast.net Wed May 23 20:06:07 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EA921F85A4 for ; Wed, 23 May 2012 20:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.699 X-Spam-Level: X-Spam-Status: No, score=-99.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MANGLED_PENIS=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qTo5bdXuGtY for ; Wed, 23 May 2012 20:06:06 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AC21F85A2 for ; Wed, 23 May 2012 20:06:06 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id Ddz61j0011uE5Es59f669i; Thu, 24 May 2012 03:06:06 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id Df621j00h3Ecudz3cf630L; Thu, 24 May 2012 03:06:06 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Wed, 23 May 2012 23:06:01 -0400 From: David Harrington To: "Romascanu, Dan (Dan)" , Mark Ellison Message-ID: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Alan DeKok , ops-area@ietf.org, pearl.liang@icann.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 03:06:07 -0000 Hi, The IANA application for an enterprise number (http://pen.iana.org/pen/PenApplication.page) refers to the IANA PEN registry. At www.iana,org, private enterprise numbers (PENs) are defined as being based on RFC2578. RFC1155 (SMIv1) and RFC2578 (SMIv2) define enterprises as a particular subtree (1.3.6.1.4.1) of the Internet subtree (1.3.6.1), approved by the IAB back in 1990. So if we're talking about IANA PENs, then it appears we are talking about the {iso.org.dod.internet.private.enterprises} subtree. We could start ANOTHER registry for PENs, but a large number of enterprises have already registered under the IANA PEN registry; it seems counter productive (especially for the IETF) to have multiple standard registries for the same purpose, and to make enterprises register multiple times. A PEN is defined as being an OBJECT IDENTIFIER (a sub-oid if I read RFC1157 correctly). I think that means the number range is constrained by the adapted subset of 1988 ASN.1 that defines an INTEGER sub-oid. But I don't have time right now to research that limit. Juergen, do you know this limit? -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 5/23/12 11:15 AM, "Romascanu, Dan (Dan)" wrote: >Well, with all due respect to SNMP, it is yet another protocol using >PENs, isn=B9t it? J >=20 >=20 >From: mark@ellisonsoftware.com [mailto:mark@ellisonsoftware.com] On >Behalf Of Mark Ellison >Sent: Wednesday, May 23, 2012 6:14 PM >To: Romascanu, Dan (Dan) >Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang@icann.org >Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs > > >=20 >Dan, >=20 > >Here is one reference point: > >=20 > >The SnmpEngineID TC as defined in RFC3411 reserves 4 octets for the PEN, >but then takes the high order bit for a different purpose. This >essentially leaves 31 usable bits for a PEN within the SnmpEngineID. > >Regards, > >=20 > >Mark > >=20 >On Wed, May 23, 2012 at 11:05 AM, Romascanu, Dan (Dan) > wrote: >This is related to draft-liang-iana-pen-00 and >draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest >defines new Vendor-Id fields in a way consistent with RFC 2865, which >used three octets. However, in draft-liang-iana-pen-00 we say that a PEN >is a non-negative integer, which I think assumes (0..2**32-1) range. > >Questions: > >- is there any place where a limit is defined? >- should we advice new documents to cautiously define 32 bits (at least) >for Vendor-Id fields? >- should we say something on this respect in draft-liang-iana-pen? > >What will happen to RFC 2865 implementations (and maybe other protocols) >that assumed Vendor-Id is limited to three octets - this will probably >need to be dealt by the RADEXT WG. > >Regards, > >Dan > > > > > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area > > > > >=20 > >=20 > > > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area From randy_presuhn@mindspring.com Wed May 23 21:35:31 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C0421F84D9 for ; Wed, 23 May 2012 21:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoITypkHznRI for ; Wed, 23 May 2012 21:35:29 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 697E021F84D0 for ; Wed, 23 May 2012 21:35:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Nm8pyQpscoly+tFZAzV3rTp8mzFX7wA5OKRs5tmgxD14nUH9IW05U5ei0WCtYQYu; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.51.49] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SXPlI-0005k8-7A; Thu, 24 May 2012 00:34:56 -0400 Message-ID: <000c01cd3966$ee5e0940$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "David Harrington" , "Romascanu, Dan \(Dan\)" , "Mark Ellison" References: Date: Wed, 23 May 2012 21:37:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88f16813936bf922548a914f8b49f097f1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.51.49 Cc: pearl.liang@icann.org, ops-area@ietf.org, Alan DeKok Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 04:35:31 -0000 Hi - > From: "David Harrington" > To: "Romascanu, Dan (Dan)" ; "Mark Ellison" > Cc: "Alan DeKok" ; ; > Sent: Wednesday, May 23, 2012 8:06 PM > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs ... > A PEN is defined as being an OBJECT IDENTIFIER (a sub-oid if I read > RFC1157 correctly). > I think that means the number range is constrained by the adapted subset > of 1988 ASN.1 that defines an INTEGER sub-oid. > But I don't have time right now to research that limit. In ASN.1 the range for sub-oids isn't tied to the definition of the INTEGER type. In ASN.1 no upper bound is mandated for sub-ids, other than in the first position and in the second position if the first is a 0 or 1, due to the way BER mashes them together. RFC 1157 also didn't specify limits for sub-identifiers. Some early SNMP implementers responded to this by writing their code to handle well-formed subidentifiers larger than 0xFFFFFFFF. I ran into one very early SNMP implementation that had problems handling subidenfiers greater than a measly 0xFFFF. Randy From j.schoenwaelder@jacobs-university.de Wed May 23 23:25:25 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A8411E8083 for ; Wed, 23 May 2012 23:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxV1C9+3vm0k for ; Wed, 23 May 2012 23:25:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CB9E011E8076 for ; Wed, 23 May 2012 23:25:24 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4106120C62; Thu, 24 May 2012 08:25:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UXA1CJnlYjo4; Thu, 24 May 2012 08:25:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 219CA20C43; Thu, 24 May 2012 08:25:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4CDF01F26E16; Thu, 24 May 2012 08:25:17 +0200 (CEST) Date: Thu, 24 May 2012 08:25:16 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20120524062516.GA5397@elstar.local> References: <000c01cd3966$ee5e0940$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cd3966$ee5e0940$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pearl.liang@icann.org, Alan DeKok , ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 06:25:25 -0000 On Wed, May 23, 2012 at 09:37:29PM -0700, Randy Presuhn wrote: > Hi - > > > From: "David Harrington" > > To: "Romascanu, Dan (Dan)" ; "Mark Ellison" > > Cc: "Alan DeKok" ; ; > > Sent: Wednesday, May 23, 2012 8:06 PM > > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs > ... > > A PEN is defined as being an OBJECT IDENTIFIER (a sub-oid if I read > > RFC1157 correctly). > > I think that means the number range is constrained by the adapted subset > > of 1988 ASN.1 that defines an INTEGER sub-oid. > > But I don't have time right now to research that limit. > > In ASN.1 the range for sub-oids isn't tied to the definition of the > INTEGER type. In ASN.1 no upper bound is mandated for sub-ids, other > than in the first position and in the second position if the first is a 0 or 1, > due to the way BER mashes them together. > > RFC 1157 also didn't specify limits for sub-identifiers. Some early > SNMP implementers responded to this by writing their code to > handle well-formed subidentifiers larger than 0xFFFFFFFF. > I ran into one very early SNMP implementation that had problems > handling subidenfiers greater than a measly 0xFFFF. And because of this, sub-identifiers were restricted to 32 bits in SMIv2. In other words, assuming PENs can be larger than 32 bits will surely not work with SNMP. And as has been pointed out before, the SnmpEngineID format kind of restricts this further to 31 bits. I think documenting that the number space is de facto limited to 32 bits is a good idea. Are we anywhere close to this limit? If not, I suggest to postpone the discussion what to do if we run out of numbers. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Wed May 23 23:47:58 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C478B21F85A7 for ; Wed, 23 May 2012 23:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.521 X-Spam-Level: X-Spam-Status: No, score=-98.521 tagged_above=-999 required=5 tests=[AWL=-1.178, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, SARE_ADULT2=1.42, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5am2PCWUzk8U for ; Wed, 23 May 2012 23:47:58 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id BEC2F21F85A5 for ; Wed, 23 May 2012 23:47:57 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta06.westchester.pa.mail.comcast.net with comcast id Dinw1j0030bG4ec56inwo4; Thu, 24 May 2012 06:47:56 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta03.westchester.pa.mail.comcast.net with comcast id Dint1j00Z3Ecudz3Pinvis; Thu, 24 May 2012 06:47:56 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 24 May 2012 02:47:53 -0400 From: David Harrington To: "Romascanu, Dan (Dan)" , Benoit Claise Message-ID: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: pearl.liang@icann.org, ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 06:47:58 -0000 Hi, Does this change anything in draft-liang-iana-pen? I do not see the I-D assuming the Enterprise is a Vendor =AD this is rather something that some protocol documents using PENs did. I think the usage of PENs to represent equipment vendors was described in RFC1065 as one possible usage, not the only usage. [Note that a PEN is an SMI Private Enterprise Code (RFC1065) used in the MIB (RFC1066). It is not defined as part of SNMP (RFC1067). SNMP (RFC1067) references MIB objects that incorporate the PEN (sysObjectID). It would help to keep that distinction between the SMI, the MIB, and protocols.] >From RCC1065: "The private(4) subtree is used to identify objects defined unilaterally. Administration of the private(4) subtree is delegated by the IAB to the Assigned Numbers authority for the Internet. Initially, this subtree has at least one child: enterprises OBJECT IDENTIFIER ::=3D { private 1 } The enterprises(1) subtree is used, among other things, to permit parties providing networking subsystems to register models of their products. Upon receiving a subtree, the enterprise may, for example, define new MIB objects in this subtree. In addition, it is strongly recommended that the enterprise will also register its networking subsystems under this subtree, in order to provide an unambiguous identification mechanism for use in management protocols. For example, if the "Flintstones, Inc." enterprise produced networking subsystems, then they could request a node under the enterprises subtree from the Assigned Numbers authority. Such a node might be numbered: 1.3.6.1.4.1.42 The "Flintstones, Inc." enterprise might then register their "Fred Router" under the name of: 1.3.6.1.4.1.42.1.1 " RFC1065 specifies how the Internet subtree of the {iso org dod} subtree should be organized: "Under the iso(1) node, the ISO has designated one subtree for use by other (inter)national organizations, org(3). Of the children nodes present, two have been assigned to the U.S. National Bureau of Standards. One of these subtrees has been transferred by the NBS to the U.S. Department of Defense, dod(6). As of this writing, the DoD has not indicated how it will manage its subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will allocate a node to the Internet community, to be administered by the Internet Activities Board (IAB) as follows: internet OBJECT IDENTIFIER ::=3D { iso org(3) dod(6) 1 } That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1. This memo, as an RFC approved by the IAB, now specifies the policy under which this subtree of OBJECT IDENTIFIERs is administered. Initially, four nodes are present: directory OBJECT IDENTIFIER ::=3D { internet 1 } mgmt OBJECT IDENTIFIER ::=3D { internet 2 } experimental OBJECT IDENTIFIER ::=3D { internet 3 } private OBJECT IDENTIFIER ::=3D { internet 4 } " RFC1065 provides the earliest definition of "private enterprise number" I have found so far. It was represented in ASN.1 for use across multiple standards organizations, as described in RFC1052 and RFC1021 >From 1052: "It is the intention of the IAB that the MIB definitions be applied both to the SNMP system in the short term and CMIS/CMIP for TCP/IP in the longer term. The three working groups will have to coordinate their efforts carefully to achieve these objectives: 1. Rapid convergence and definition for SNMP. 2. Rapid convergence and definition for the TCP/IP MIB. 3. Provision for transitioning from SNMP to CMIP/CMIS. 4. Early demonstration of the CMIP/CMIS capability using the TCP/IP MIB." So {private enterprises} (1.3.6.1.4.1) was developed as part of the SMI to be usable by multiple protocols, not just SNMP. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 5/23/12 12:18 PM, "Romascanu, Dan (Dan)" wrote: >Does this change anything in draft-liang-iana-pen? I do not see the I-D >assuming the Enterprise is a Vendor =AD this is rather something that some >protocol documents using PENs did. >=20 >Dan >=20 >=20 >=20 >From: Benoit Claise [mailto:bclaise@cisco.com] >Sent: Wednesday, May 23, 2012 6:18 PM >To: Romascanu, Dan (Dan) >Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok; pearl.liang@icann.org >Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs > > >=20 >Hi, > >Since we're discussing PENs, I have another some more I would like to see >addressed in draft-liang-iana-pen-00. > - What about unassigned PENs? See the part in red in my DISCUSS on >https://datatracker.ietf.org/doc/draft-ietf-netext-access-network-option/ >(on the telechat this Thursday) > - PEN are not always representing manufacturer ID >-The term "vendor" is confusing Vendor ID The Vendor ID is the >SMI Network Management Private Enterprise Code of the >IANA-maintained Private Enterprise Numbers registry [SMI]. The >example in figure 1 speaks about: "Operator-Id: >provider2.example.com"Vendor Id, in the network management world is the >manufacturer id, while you'reafter the Operator-IdI see what you want to >do, but this is confusing. Also, dowe expect that all operators will have >Private Enterprise Number? Maybe you want to redefine this with something >such as (I trust you on the rightwording) Operator PEN ID SMI >Network Management Private Enterprise Code of the IANA-maintained >Private Enterprise Numbers registry [SMI] for the operator running >... [actually running what, that's another required clarification >in the draft] ... the respective interface on mobile access gateway? In >section 3.1.3 (and some other places such as IANA), change "Vendor ID" >by"Operator PEN ID" And also add a few sentences about- whether all >operators should or must now register new PENs for this spec. I checked >for a couple of my local ISPs, andnot all of them had a PEN.- if there is >no PEN Operator ID, then ANI type=3D 3, Op-ID=3D2 MUST NOT/SHOULD NOT be used > if "SHOULD NOT", what should be default?Operator PEN ID=3D8653? (not >even sure if this is the right thing to do) or 0?You want to discuss with >the authors of draft-liang-iana-pen-00, be in synchwith them.Regards, >Benoit. > > > >This is related to draft-liang-iana-pen-00 >anddraft-ietf-radext-radius-extensions-05.txt now in WGLC. The >latestdefines new Vendor-Id fields in a way consistent with RFC 2865, >whichused three octets. However, in draft-liang-iana-pen-00 we say that a >PENis a non-negative integer, which I think assumes (0..2**32-1) range. >Questions: - is there any place where a limit is defined? - should we >advice new documents to cautiously define 32 bits (at least)for Vendor-Id >fields? - should we say something on this respect in >draft-liang-iana-pen? What will happen to RFC 2865 implementations (and >maybe other protocols)that assumed Vendor-Id is limited to three octets - >this will probablyneed to be dealt by the RADEXT WG. Regards, Dan >_______________________________________________OPS-AREA mailing >listOPS-AREA@ietf.orghttps://www.ietf.org/mailman/listinfo/ops-area > > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area From ietfdbh@comcast.net Thu May 24 00:16:56 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9111E80A4 for ; Thu, 24 May 2012 00:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.56 X-Spam-Level: X-Spam-Status: No, score=-100.56 tagged_above=-999 required=5 tests=[AWL=2.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0LUy9-eX20m for ; Thu, 24 May 2012 00:16:55 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id AEE1411E8076 for ; Thu, 24 May 2012 00:16:55 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id DjGv1j0011uE5Es54jGvEh; Thu, 24 May 2012 07:16:55 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id DjGr1j0053Ecudz3cjGs3j; Thu, 24 May 2012 07:16:55 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 24 May 2012 03:16:51 -0400 From: David Harrington To: Juergen Schoenwaelder , Randy Presuhn Message-ID: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs In-Reply-To: <20120524062516.GA5397@elstar.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Alan DeKok , ops-area@ietf.org, pearl.liang@icann.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:16:56 -0000 Currently at 39965. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 5/24/12 2:25 AM, "Juergen Schoenwaelder" wrote: > I think >documenting that the number space is de facto limited to 32 bits is a >good idea. Are we anywhere close to this limit? If not, I suggest to >postpone the discussion what to do if we run out of numbers. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu May 24 00:30:50 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0721521F84B2 for ; Thu, 24 May 2012 00:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[AWL=1.359, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6md2Waz4c8LM for ; Thu, 24 May 2012 00:30:49 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id E996721F84A7 for ; Thu, 24 May 2012 00:30:48 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id DjWo1j0030EZKEL51jWo08; Thu, 24 May 2012 07:30:48 +0000 Received: from [192.168.1.34] ([71.233.85.150]) by omta01.westchester.pa.mail.comcast.net with comcast id DjWl1j0013Ecudz3MjWmAi; Thu, 24 May 2012 07:30:48 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 24 May 2012 03:30:44 -0400 From: David Harrington To: Juergen Schoenwaelder , Randy Presuhn Message-ID: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs In-Reply-To: <20120524062516.GA5397@elstar.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Alan DeKok , ops-area@ietf.org, pearl.liang@icann.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:30:50 -0000 On 5/24/12 2:25 AM, "Juergen Schoenwaelder" wrote: > >And because of this, sub-identifiers were restricted to 32 bits in >SMIv2. In other words, assuming PENs can be larger than 32 bits will >surely not work with SNMP. >/js Notes: 1) sysObjectID includes SMI PENs, and many SNMP network monitoring systems use sysObjectID to identify devices, as suggested by RFC1065. Auto-discovery is especially reliant on these values. 2) syslog (RFC5424) uses the SMI PEN registry. 3) ipfix (RFC5101) uses the SMI PEN registry. 4) sipclf IDs use the SMI PEN registry. 5) middisc ID does not use the SMI PEN registry because it is too large for its intended use, and requests a smaller (8-bit) vendor code registry. I am not sure how these uses would be impacted by a PEN larger than 32 bits. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 > From dromasca@avaya.com Thu May 24 00:53:54 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1184321F862B for ; Thu, 24 May 2012 00:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcpV8SDQHcfC for ; Thu, 24 May 2012 00:53:53 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id AD9A521F85DF for ; Thu, 24 May 2012 00:53:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADLovU/GmAcF/2dsb2JhbABAA7RHgQeCFQEBAQEDEh4KPwwCAgIBCA0BAgEEAQEBCgYMCwEGARorCQgBAQQBEggah10DC54okyYIiVMEinsUAYFwgjtgA5sJiX+CbIFUAQ X-IronPort-AV: E=Sophos;i="4.75,650,1330923600"; d="scan'208";a="349237473" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 May 2012 03:52:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 May 2012 03:51:45 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2012 09:53:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs Thread-Index: Ac05fT02tqsTtj9pQEmxfjEg6iH8MwABDccQ References: <20120524062516.GA5397@elstar.local> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Juergen Schoenwaelder" , "Randy Presuhn" Cc: pearl.liang@icann.org, Alan DeKok , ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:53:54 -0000 It looks that we are far away from the 2**32-1 or 2**31-1 limit.=20 My opinion is that we can postpone the discussion about how to extend the space beyond 31 or 32 bits for the moment in time when we get closer.=20 In the meantime I would suggest that we document in draft-liang:=20 1. The assumed limit and its reasons 2. The fact that although one of the popular uses is SMI, the PENs are designed to be used by multiple protocols and DMLs 3. The recommendation for future protocols to allocate at least 31 bits in fields derived from PEN 4. That Enterprise is not always Vendor Regards, Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, May 24, 2012 10:17 AM > To: Juergen Schoenwaelder; Randy Presuhn > Cc: Romascanu, Dan (Dan); Mark Ellison; pearl.liang@icann.org; ops- > area@ietf.org; Alan DeKok > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs >=20 > Currently at 39965. >=20 > -- > David Harrington > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 5/24/12 2:25 AM, "Juergen Schoenwaelder" > wrote: >=20 > > I think > >documenting that the number space is de facto limited to 32 bits is a > >good idea. Are we anywhere close to this limit? If not, I suggest to > >postpone the discussion what to do if we run out of numbers. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >Fax: +49 421 200 3103 >=20 From j.schoenwaelder@jacobs-university.de Thu May 24 01:19:34 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8CC21F854D for ; Thu, 24 May 2012 01:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LFOjOK4jWmX for ; Thu, 24 May 2012 01:19:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 527E721F84B6 for ; Thu, 24 May 2012 01:19:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98D0120C2B; Thu, 24 May 2012 10:19:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z0nRpzxaVV2v; Thu, 24 May 2012 10:19:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30F5020C25; Thu, 24 May 2012 10:19:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 161181F2725F; Thu, 24 May 2012 10:19:30 +0200 (CEST) Date: Thu, 24 May 2012 10:19:29 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120524081929.GB5926@elstar.local> References: <20120524062516.GA5397@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: pearl.liang@icann.org, Alan DeKok , ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 08:19:35 -0000 On Thu, May 24, 2012 at 09:53:48AM +0200, Romascanu, Dan (Dan) wrote: > It looks that we are far away from the 2**32-1 or 2**31-1 limit. > > My opinion is that we can postpone the discussion about how to extend > the space beyond 31 or 32 bits for the moment in time when we get > closer. > > In the meantime I would suggest that we document in draft-liang: > > 1. The assumed limit and its reasons > 2. The fact that although one of the popular uses is SMI, the PENs are > designed to be used by multiple protocols and DMLs > 3. The recommendation for future protocols to allocate at least 31 bits > in fields derived from PEN My preference would be to suggest that future protocols allocate at least 32 bits. The SnmpEngineID use case is kind of wired and should be mentioned in the document but perhaps a solution is simply to update the SnmpEngineID TC so that 32 bit enterprise IDs can be used should we ever get close to 2^31 bits. This gives us 2^31 more PENs should we need them. > 4. That Enterprise is not always Vendor /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu May 24 02:40:25 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5021F85E5 for ; Thu, 24 May 2012 02:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.978 X-Spam-Level: X-Spam-Status: No, score=-102.978 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+bDWlKLFcLa for ; Thu, 24 May 2012 02:40:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2542E21F85E1 for ; Thu, 24 May 2012 02:40:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJMBvk+HCzI1/2dsb2JhbAA5BwO0RIEHghUBAQEBAgESHgo/BQcEAgEIDQECAQQBAQEKBgwLAQYBRQkIAQEEARIIGoddAwYFnjeTJwiJU4p/EIF1gjtgA5sJiX+CbA X-IronPort-AV: E=Sophos;i="4.75,650,1330923600"; d="scan'208";a="10783797" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 May 2012 05:38:40 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 May 2012 05:22:35 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2012 11:39:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] assumption about number of octets encoding PENs Thread-Index: Ac05fyrwB05+c1xWSL6G0oGEC31XqwAET9ng References: <20120524062516.GA5397@elstar.local> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Juergen Schoenwaelder" , "Randy Presuhn" Cc: pearl.liang@icann.org, Alan DeKok , ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 09:40:25 -0000 Yes. And worse. This discussion started from the fact that RADIUS (RFC 2865) assumes 24 bits, and draft-radext-radius-extensions prepared to do the same. Actually Vendor-ID field in the Vendor-Specific attribute in RFC 2865 is defined like this:=20 > The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order.=20 So I there may be a way in the protocol to extend from 24 to 32 bits, but implementations need to change. Beyond 32 bits the problem is the same as with the other protocols listed below, but that moment in time seems very remote.=20 Regards, Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, May 24, 2012 10:31 AM > To: Juergen Schoenwaelder; Randy Presuhn > Cc: Romascanu, Dan (Dan); Mark Ellison; pearl.liang@icann.org; ops- > area@ietf.org; Alan DeKok > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs >=20 >=20 >=20 >=20 >=20 > On 5/24/12 2:25 AM, "Juergen Schoenwaelder" > wrote: >=20 > > > >And because of this, sub-identifiers were restricted to 32 bits in > >SMIv2. In other words, assuming PENs can be larger than 32 bits will > >surely not work with SNMP. > >/js >=20 > Notes: > 1) sysObjectID includes SMI PENs, and many SNMP network monitoring > systems > use sysObjectID to identify devices, as suggested by RFC1065. > Auto-discovery is especially reliant on these values. > 2) syslog (RFC5424) uses the SMI PEN registry. > 3) ipfix (RFC5101) uses the SMI PEN registry. > 4) sipclf IDs use the SMI PEN registry. > 5) middisc ID does not use the SMI PEN registry because it is too large > for its intended use, and requests a smaller (8-bit) vendor code > registry. >=20 > I am not sure how these uses would be impacted by a PEN larger than 32 > bits. >=20 >=20 > -- > David Harrington > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > > >=20 From alexey.melnikov@isode.com Thu May 24 05:09:28 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE13E21F8672 for ; Thu, 24 May 2012 05:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_PENIS=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhB-xZnv0b8M for ; Thu, 24 May 2012 05:09:28 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id F180021F8648 for ; Thu, 24 May 2012 05:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337861367; d=isode.com; s=selector; i=@isode.com; bh=lj33HZPnTK7IB91oWLyojo2rlaK7Jv5n1gIfL6b6dsI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=taQEXGpVIarKDK/m8t9N8vnimzrLX83De/cRYHri1isg5nQAtyY2zG1kx0/LDZGCcgUIN4 QZCdFX28zWshwqFXJ+CWU6/IkWwLCFg2KYDo0Mhla/M6NR5M8foPzVEXkQ7cTU+z7jwvWt FiA19TJaq/sJMHUj0Mb+0WK5SfwobEM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 24 May 2012 13:09:27 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FBE250D.3030301@isode.com> Date: Thu, 24 May 2012 13:09:49 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Bert Wijnen (IETF)" References: <4FA98384.8090805@isode.com> <4FAA872F.9080007@bwijnen.net> In-Reply-To: <4FAA872F.9080007@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pearl.liang@icann.org, ops-area@ietf.org Subject: Re: [OPS-AREA] Documenting rules for the Private Enterprise Numbers registry: draft-liang-iana-pen-00 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 12:09:28 -0000 Hi Bert, On 09/05/2012 16:03, Bert Wijnen (IETF) wrote: > Mmm.. In IANA considerations I see: > > > o Removal of Private Enterprise Numbers: > > A Contact Name can request to remove the corresponding PEN allocation > if the resource is no longer in used or the resource does not meet > the needs. (In a case when the Contact Name is no longer with the > Company/Organization, the Modification procedure described above MUST > be used first.) Such request does not happen often and regularly. > > Requests can only be fulfilled upon verification by IANA and/or > subject matter experts. > > If the removal request is honoured, the entry is marked as > "Unassigned" and can be reallocated by IANA later unless specified > otherwise, i.e. by marking the entry as "Reserved". > > How can we be assured that the once assigned PEN is not being used > anywhere in the digital world? What is someone is still using it in > some obsoleted/no-longer-supported product? Should he/she run the > risk that it conflicts with a possible new assignment/allocation? Yes, good points. > I would rather see that it will be marked "returned on yyyy-mm-dd > by xxxxxxx" and then that it not be re-used/allocated unless we > run out of numbers far in the future (at that time we can decide > if this makes sense, or possibly define another arc in > iso.org.dod.internet.private.enterprise, for example: > iso.org.dod.internet.private.enterprise.2^32-1.PEN > where 2^32-1 is a special PEN that indicates that the PEN > is longer than 32bits. I've changed this in my copy of -01. From aland@deployingradius.com Wed May 23 08:13:29 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED1E21F873A for ; Wed, 23 May 2012 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, MANGLED_PENIS=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwANyVYS6peo for ; Wed, 23 May 2012 08:13:29 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5185621F8726 for ; Wed, 23 May 2012 08:13:29 -0700 (PDT) Message-ID: <4FBCFE7E.6080904@deployingradius.com> Date: Wed, 23 May 2012 17:13:02 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 May 2012 08:52:06 -0700 Cc: pearl.liang@icann.org, ops-area@ietf.org Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 15:13:29 -0000 Romascanu, Dan (Dan) wrote: > This is related to draft-liang-iana-pen-00 and > draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest > defines new Vendor-Id fields in a way consistent with RFC 2865, which > used three octets. However, in draft-liang-iana-pen-00 we say that a PEN > is a non-negative integer, which I think assumes (0..2**32-1) range. I'm the author of draft-ietf-radext-radius-extensions-05.txt > Questions: I have little input to those questions. > What will happen to RFC 2865 implementations (and maybe other protocols) > that assumed Vendor-Id is limited to three octets - this will probably > need to be dealt by the RADEXT WG. I'm aware of a number of widely-used RADIUS implementations which have a 16-bit limit on PECs. These implementations won't be able to handle a larger PEC. They require substantial re-engineering of their internals. The current maximum PEN is ~40K. At the current rate, we have a few years left before 2^16 is reached. We should recommend that implementations be fixed before then. My $0.02 is that we should require protocols to support 32-bit PENs. That should be enough for quite a while. Alan DeKok.