Re: [OPS-AREA] assumption about number of octets encoding PENs
Benoit Claise <bclaise@cisco.com> Wed, 23 May 2012 18:42 UTC
Return-Path: <bclaise@cisco.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 73E3B21F86C6 for <ops-area@ietfa.amsl.com>; 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 <ops-area@ietfa.amsl.com>; 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 <ops-area@ietf.org>; 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 <bclaise@cisco.com>
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)" <dromasca@avaya.com>
References: <EDC652A26FB23C4EB6384A4584434A04079D6FF0@307622ANEX5.global.avaya.com> <4FBCFFBB.6040300@cisco.com> <EDC652A26FB23C4EB6384A4584434A04079D703A@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04079D703A@307622ANEX5.global.avaya.com>
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 <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 18:42:59 -0000
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 <mailto: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