I have verified that all of our comments are in the -13 vesion.
I have edited/removed text about Designated Experts, but I think that maybe
we should change FCFS -> Expert Review.

Luis Contreras via Datatracker <[email protected]> wrote:
    > /* Comments */
    > - Section 2.2. It is stated that "LinkType values 147 to 162 named
    > LINKTYPE_RESERVED_xx were originally reserved for Private Use. Their use 
is
    > Deprecated in favour of the values in the 65001-65535 range." It is not 
clear
    > to me if this implies that LinkType values 147 to 162 are then available 
for
    > new allocations or if it is recommended not being used because of their
    > previous usage as reserved values. In any case, a clarification statement 
for
    > this is advisable. Note that if those values are intended to be
    > allocatable,

Clarified.

    > compatibility. - No reference is provided for LINKTYPE_ETHERNET even 
though the
    > description refers to IEEE 802.3 Ethernet. Should not be added a 
reference to
    > the appropriate specification by IEEE?

okay, fixed, reference to: https://ieeexplore.ieee.org/document/9844436

    > - For a number of assigned values (e.g.,
    > 5, 7, 99, ...) the description says "Reserved for ...". This gives the
    > impression of a non definitive allocation, but something to happen in the
    > future. Since they are allocations for legacy link types, should we either
    > reconsider the description (i.e., remove "reserved for") or propose some
    > statement in that respect in terms of assessing if such reservation is
    > effective or not?

It seems that it's the "Reserved for.." which is the problem.
I have removed those two words.

    > something can be mentioned in this respect, as well. This apllies also to 
the
    > case of Number 208.

Marked as proprietary.

    > about why these numbers should not be used. Same for values 52 to 98. -
    > No

Used by NetBSD.

    > reference is provided for LINKTYPE_RAW even though the description refers 
to
    > IPv4 and IPv6.
    > Should not be added a reference to the appropriate specification
    > by IETF?

Seems to have RFC791 and 8200 referenced now, and 228/229 fixed already.

    > in line with current values, contains information about Name, Number,
    > Description and Reference. I wonder if for new allocations could be 
interesting
    > to register the date of allocation for the purpose of tracing the the 
aging of
    > the allocation in the future.

I don't know. I think that IANA has that info internally already.

    > - Section 2.2.2. It is mentioned the following:
    > "LinkTypes may be allocated for specifications not publicly available may 
be
    > made within the FCFS range.  This includes specifications that might be
    > classified.  The minimal requirement is to provide a contact person for 
that
    > link type." My quesiton is, should all the (new) registries contain the 
contact
    > person? I think it is advisable to describe in some section the structure 
of
    > the information required for the new allocations, so to avoid
    > confussion.

The hope is that the reference contains the contact info.
IANA otherwise  knows who asked.

    > /* Editorial */
    > - s/Their use is Deprecated in favour of.../Their use is deprecated in 
favour of
    > - Is there any reason for the indentation of the last paragraph in 
Section 2.2?
    > - Section 2.2.2. The following sentence does not read well to me (please, 
note
    > I'm not English native speaker): "LinkTypes may be allocated for 
specifications
    > not publicly available may be made within the FCFS range."

Reworded to say:
   It is acceptable to register LinkTypes for which specifications are not
   publicly available.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [






--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to