Re: [Last-Call] Secdir last call review of draft-ietf-lisp-vendor-lcaf-10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tero,

 

Thanks a lot for your detailed review. Your expertise in IEEE standards is invaluable here!

 

We have tried to include all your feedback in version -11 of the draft [1]. Would you be so kind to take a look and let us know what you think? Just one comment regarding the new version.

 

Now the draft points to the IEEE standard using this format “IEEE Std 802 [IEEE.802_2014]”. It seems that the reference system doesn’t allow us to use “IEEE Std 802 [IEEE.802]”. Let us know if this is ok, or how we shall proceed.

 

Let us know any comment you might have in the new version.

 

Thanks!

Alberto

 

[1] https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vendor-lcaf-11

 

From: Tero Kivinen via Datatracker <noreply@xxxxxxxx>
Date: Thursday, May 19, 2022 at 8:47 PM
To: secdir@xxxxxxxx <secdir@xxxxxxxx>
Cc: draft-ietf-lisp-vendor-lcaf.all@xxxxxxxx <draft-ietf-lisp-vendor-lcaf.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, lisp@xxxxxxxx <lisp@xxxxxxxx>
Subject: Secdir last call review of draft-ietf-lisp-vendor-lcaf-10

Reviewer: Tero Kivinen
Review result: Has Nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. This is review is quite late, as this document was first assigned
to another reviewer, and was then withdrawn and assigned to me today.

This document describes how to generate Vendor Specific LCAFs. The
document seems to be otherwise fine, except it incorrectly uses IEEE
terminology and provides reference to very old IEEE document.

The references section include:

   [IEEE.802_2001]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks: Overview and Architecture", IEEE 802-2001,
              DOI 10.1109/ieeestd.2002.93395, 27 July 2002,
              <http://ieeexplore.ieee.org/servlet/opac?punumber=7732>.

This document is dated reference to IEEE document, and I see no reason
to use dated reference here. Using IEEE 802-2001 fixes the reference
to that specific document published in 2001. There is new revision
of this document IEEE Std 802-2014 which do contain significant changes
related to topic of this draft. It would be better to use undated
reference i.e "IEEE Std 802" instead of dated reference. That way
this document will always refer to the latest IEEE Standard.

(i.e. difference is same as using old obsoleted RFC numbers instead
latest RFC numbers or STD numbers).

Also the correct spelling of the IEEE Standards is to "Std" between
IEEE and number, i.e. "IEEE Std 802", or "IEEE Std 802-2014" (note, no
period after Std).

The major issue is the text using OUI:

      Organizationally Unique Identifier (OUI): This is a 24-bit field
      that carries the IEEE OUI [IEEE.802_2001] of the organization.

The IEEE Std 802-2014 defines multiple types of OUIs, and in addition to
them there is CID (Company ID). There are 4 different registries where
those can be allocated (CID, MA-L, MA-M, and MA-S). One of them uses CID,
another OUI, and one OUI-36.

CID is 24-bit number assigned by IEEE which shares the same registry as
MA-L, but is generated so that the X-bit (U/L address bit in mac address)
is set to one, thus it cannot be created to generate universal addresses.

24-bit OUI uses the same MA-L registry and as CID but has the X-bit set to
zero, so it can be used both to generate universal MAC addresses, and
to identify organization.

Here you want to allow both 24-bit OUI and CID. To fix this you want
to say something like this:

      Organizationally Unique Identifier (OUI): This is a 24-bit field
      that carries and OUI or CID assigned by the IEEE Registration
      Authority (RA) as define by the IEEE Std 802 [IEEE.802].

This text is adopted from IEEE Std 802.15.9-2021 section 8.2, which
uses OUI and CID in similar context.

Btw, the IEEE Std 802-2014 has following notes in section 8.2.2:

    NOTE 1—The terms OUI and OUI-36 were previously used by
    the IEEE RA to refer to what are now called MA–L and
    MA–S, respectively. The acronym OUI without modification
    was used to refer to the 24-bit field assigned by the IEEE
    RA. However, while not appropriate, the acronym OUI has
    been used to refer to generally to all IEEE RA assignments.
    As a result, the use of OUI is not always consistent within
    all IEEE standards.
    NOTE 2—The CID comes from the same 24-bit space as the MA-L/OUI.
    A CID assignment is used to identify a company or organization,
    but is not used to create universal addresses. A CID assignment
    has the X bit (the U/L address bit in a MAC address) set to one,
    which would place any address created with a CID in the locally
    administered address space.(13)

...

    (13) More information on CIDs can be found on the IEEE RA tutorial
    web page, http://standards.ieee.org/develop/regauth/tut/index.html.

IEEE Standards usually also put a footnote after first mention of RA
which says:

    (n) Interested applicants should contact the IEEE Registration Authority,  
        http://standards.ieee.org/develop/regauth/.


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux