Re: assumption about number of octets encoding PENs

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:[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]  <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/ops-area
>   
>   
>

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