Re: assumption about number of octets encoding PENs

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:[email protected]] 
Sent: Wednesday, May 23, 2012 6:18 PM
To: Romascanu, Dan (Dan)
Cc: [email protected]; Alexey Melnikov; Alan DeKok;
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area