Re: [OPS-AREA] assumption about number of octets encoding PENs
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 23 May 2012 16:18 UTC
Return-Path: <dromasca@avaya.com>
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 <ops-area@ietfa.amsl.com>; 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 <ops-area@ietfa.amsl.com>; 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 <ops-area@ietf.org>; 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: <EDC652A26FB23C4EB6384A4584434A04079D703A@307622ANEX5.global.avaya.com>
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: <EDC652A26FB23C4EB6384A4584434A04079D6FF0@307622ANEX5.global.avaya.com> <4FBCFFBB.6040300@cisco.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Benoit Claise <bclaise@cisco.com>
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 <ops-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ops-area>, <mailto:ops-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ops-area>
List-Post: <mailto:ops-area@ietf.org>
List-Help: <mailto:ops-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ops-area>, <mailto:ops-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2012 16:18:32 -0000
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-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
- [OPS-AREA] assumption about number of octets enco… Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Mark Ellison
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Benoit Claise
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Alexey Melnikov
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Benoit Claise
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … Randy Presuhn
- Re: [OPS-AREA] assumption about number of octets … Juergen Schoenwaelder
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … David Harrington
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Juergen Schoenwaelder
- Re: [OPS-AREA] assumption about number of octets … Romascanu, Dan (Dan)
- Re: [OPS-AREA] assumption about number of octets … Alan DeKok