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
>
>