Re: [6lo] #19 (paging-dispatch): Using page 15 for reserved for vendor special use and experiments

["6lo issue tracker" <[e-mail]>]

#19: Using page 15 for reserved for vendor special use and experiments


Comment (by [e-mail]):

 Proposed text and asked review from IANA


 From: Pascal Thubert (pthubert)
 Sent: mercredi 12 octobre 2016 15:30
 To: '[e-mail]' <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: RE: [IANA #929924] RE: Last Call: <draft-ietf-6lo-paging-
 dispatch-04.txt> (6LoWPAN Paging Dispatch) to Proposed Standard

 Hello Amanda:

 We followed up on that dichotomy, and as a result, I'm pushing an update
 whereby page 15 is now reserved for experimentation. I’m proposing to
 update the text as below.

 Is this clear enough?

 Take care,

 Pascal


 6.2.  New Column in Dispatch Type Registry

    This document extends the Dispatch type field registry that was
    created for [RFC4944] and updated by the [RFC6282], by adding a new
    column called "Page".

    This document defines 16 Pages, "Page 0" to "Page 15".

    The content of the incumbent registry is assigned to "Page 0".

    This document also places in the registry associated to Page 1 the
    Dispatch type field values that are allocated for LOWPAN_IPHC by
    [RFC6282].  These values range from 01 100000 through 01 111111 and
    have the same definition in Page 1 as they do in Page 0; as a result,
    the registry entries for Page 0 and Page 1 are an exact overlap in
    this range.

    Values ranging from 00000000 to 11101111 in Page 15 (that is all of
    Page 15 but the space used for Page switch) is reserved for
    experimentations and shall not be assigned.

    The resulting registry may be represented as a table as follow
    (partial):


 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Pattern    |    Page     | Header Type | defining document       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |     0       |  NALP       |      RFC 4944           |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  00xxxxxx     |   1..14     |  free       |                         |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+       N/A               |
 |               |    15       |  reserved   |                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |     0       |  ESC        |      RFC 6282           |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  01000000     |   1..14     |  free       |                         |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+       N/A               |
 |               |    15       |  reserved   |                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        ...                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |   0..1      | LOWPAN_IPHC |      RFC 6282           |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  011xxxxx     |   2..14     |  free       |                         |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+       N/A               |
 |               |    15       |  reserved   |                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        ...                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  1111xxxx     |   0..15     | Page switch |        This             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 2: Integrating the new Page column

    Future assignments in these registries are to be coordinated via IANA
    under the policy of "Specification Required" [RFC5226].  It is
    expected that this policy will allow for other (non-IETF)
    organizations to more easily obtain assignments.


 -----Original Message-----
 From: Amanda Baber via RT [mailto:[e-mail]]
 Sent: vendredi 30 septembre 2016 19:21
 Cc: [e-mail]; [e-mail]
 Subject: [IANA #929924] RE: Last Call: <draft-ietf-6lo-paging-
 dispatch-04.txt> (6LoWPAN Paging Dispatch) to Proposed Standard

 Hi Pascal,

 On Fri Sep 30 09:42:41 2016, [e-mail] wrote:
 > Looks good to me Amanda.
 >
 > I'm a bit confused by reserved vs. unassigned. Do we really need to
 > make a difference? If so, what is it really?

 These are defined in RFC 5226, Section 4:

       Unassigned: Unused and available for assignment via documented
             procedures.

       Reserved:  Not to be assigned.  Reserved values are held for
             special uses, such as to extend the namespace when it become
             exhausted.  Reserved values are not available for general
             assignment.

 If the ranges currently marked "Reserved for future use" are meant to be
 available for assignment through the Specification Required procedure,
 their descriptions should be changed to "Unassigned." Making assignments
 from a Reserved range would require an RFC.

 Best,
 Amanda

 > Take care,
 >
 > Pascal
 >
 > -----Original Message-----
 >  From: Amanda Baber via RT [mailto:[e-mail]]
 > Sent: jeudi 29 septembre 2016 07:30
 > Cc: [e-mail]; [e-mail]
 > Subject: [IANA #927699] Last Call: <draft-ietf-6lo-paging-dispatch-
 > 04.txt> (6LoWPAN Paging Dispatch) to Proposed Standard
 >
 > (BEGIN IANA COMMENTS)
 >
 > IESG/Authors/WG Chairs:
 >
 > IANA has completed its review of draft-ietf-6lo-paging-dispatch-04. If
 > any part of this review is inaccurate, please let us know.
 >
 > We understand that this document is adding a column called "Page" and
 > a new Header Type ("Page switch") to the Dispatch Type Field registry
 > at http://www.iana.org/assignments/_6lowpan-parameters. This document
 > will also be listed as an additional registration for the registry
 > itself.
 >
 > Because this is a Specification Required registry, IANA must request
 > that the IESG designate an expert to review the new registration.
 >
 > The updated registry will read as follows (note: in the registry, the
 > Page column will be placed between the Bit Patter and Header Type
 > columns):
 >
 > Bit Pattern    Header Type    Page    Reference
 > 00 xxxxxx       NALP - Not a LoWPAN frame       0    [RFC4944]
 > 00 xxxxxx       Unassigned    1-15
 > 01 000000       Reserved as a replacement value for ESC    0
 > [RFC6282]
 > 01 000000       Unassigned    1-15
 > 01 000001       IPv6 - uncompressed IPv6 Addresses    0    [RFC4944]
 > 01 000001       Unassigned    1-15
 > 01 000010       LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6    0 [RFC4944]
 > 01 000010       Unassigned    1-15
 > 01 000011       LOWPAN_DFF    0    [RFC6971]
 > 01 000011       Unassigned    1-15
 >  01 000100 through 01 001111     reserved for future use
 > 01 010000       LOWPAN_BC0 - LOWPAN_BC0 broadcast    0    [RFC4944]
 > 01 010000       Unassigned 1-15
 >  01 010001 through 01 011111     reserved for future use
 > 01 1xxxxx               LOWPAN_IPHC    0-1    [RFC6282]
 > 01 1xxxxx       Unassigned    2-15
 > 10 xxxxxx       MESH - Mesh header    0    [RFC4944]
 > 10 xxxxxx       Unassigned    1-15
 > 11 000xxx       FRAG1 -- Fragmentation Header (first)    0
 > [RFC4944]
 > 11 000xxx       Unassigned    1-15
 >  11 001000 through 11 011111     reserved for future use
 > 11 100xxx               FRAGN -- Fragmentation Header (subsequent)
 > 0    [RFC4944]
 > 11 100xxx               Unassigned    1-15
 >  11 101000 through 11 101111     reserved for future use
 > 11 11xxxx        Page switch    0-15    [this document]
 >
 > Note:  The actions requested in this document will not be completed
 > until the document has been approved for publication as an RFC. This
 > message is only to confirm what actions will be performed.
 >
 > Thank you,
 >
 > Amanda Baber
 > IANA Lead Specialist
 > ICANN
 >
 > (END IANA COMMENTS)
 >
 > On Thu Sep 15 13:08:59 2016, [e-mail] wrote:
 > >
 > > The IESG has received a request from the IPv6 over Networks of
 > > Resource-constrained Nodes WG (6lo) to consider the following
 > > document:
 > > - '6LoWPAN Paging Dispatch'
 > >  <draft-ietf-6lo-paging-dispatch-04.txt> as Proposed Standard
 > >
 > > The IESG plans to make a decision in the next few weeks, and
 > > solicits final comments on this action. Please send substantive
 > > comments to the [e-mail] mailing lists by 2016-09-29.
 > > Exceptionally, comments may be sent to [e-mail] instead. In
 > > either case, please retain the beginning of the Subject line to
 > > allow automated sorting.
 > >
 > > Abstract
 > >
 > >
 > > This specification updates RFC 4944 to introduce a new context
 > > switch mechanism for 6LoWPAN compression, expressed in terms of
 > > Pages and signaled by a new Paging Dispatch.
 > >
 > >
 > >
 > >
 > > The file can be obtained via
 > > https://datatracker.ietf.org/doc/draft-ietf-6lo-paging-dispatch/
 > >
 > > IESG discussion can be tracked via
 > > https://datatracker.ietf.org/doc/draft-ietf-6lo-paging-
 > > dispatch/ballot
 > > /
 > >
 > >
 > > No IPR declarations have been submitted directly on this I-D.
 > >
 > >
 > >
 > >
 >
 >
 >

-- 
-----------------------------------+---------------------------------
 Reporter:  [e-mail]     |       Owner:  [e-mail]
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:  milestone1
Component:  paging-dispatch        |     Version:  2.0
 Severity:  Submitted WG Document  |  Resolution:
 Keywords:                         |
-----------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/19#comment:1>
6lo <https://tools.ietf.org/6lo/>