Hi Tom, though I'd not say "quasi-proprietary" but "well-known", you're correct. My proposal allows the same innovation as in the current proposal for the new registry but makes that innovation trackable, non-conflicting.
Regards, Greg On Wed, Oct 23, 2019 at 10:46 AM Tom Herbert <[email protected]> wrote: > On Wed, Oct 23, 2019 at 6:44 AM Greg Mirsky <[email protected]> wrote: > > > > Dear Authors, et al., > > I have a rather benign question the new registry requested in Section > 8.3. The draft states that the whole 1-127 range is "RFC required" per RFC > 5226. Firstly, a nit - RFC 5226 has been obsoleted by RFC 8126. My question > is Would you agree to split the 128-255 range and set First Come First > Served sub-range. For example: > > > > +----------------+------------------+---------------+ > > | Control type | Description | Reference | > > +----------------+------------------+---------------+ > > | 0 | Control payload | This document | > > | | needs more | | > > | | context for | | > > | | interpretation | | > > | | | | > > | 1..127 | Unassigned | | > > | | | | > > | 128..250 | First Come | RFC 8126 | > > | | First Served | | > > | 251..254 | Experimental | This document | > > | | | | > > | 255 | Reserved | This document | > > | | | | > > +----------------+------------------+---------------+ > > > > Also, you may consider updating 0 as Reserved and assigning 1 as Control > payload ... > > Much appreciate your consideration. > > Greg, > > My immediate question is would this encourage people to develop quasi > proprietary control types? (which they would probably do anyway in > using experimental values but wouldn't acknowledged by IANA). > > Tom > > > > Regards, > > Greg > > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
