Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt

[Mukul Goyal <[e-mail]>]

Hi Michael

Does the following text meets your concerns?

Thanks
Mukul

Section 7.2 (Data Option)

"o  Upper: A 4-bit field that identifies the upper layer protocol
      header with which the information in the Data field starts.  A
      value 0x0 in this field identifies UDP as the upper layer protocol
      while the value 0xF is reserved for Private Use as defined in
      [RFC5226].  The other values are Unassigned [RFC5226] at present.

"

Section 14.  IANA Considerations

14.1.  Additions to Mode of Operation

   This document defines a new Mode of Operation, entitled "P2P Route
   Discovery Mode" (see Section 6), assigned a value of 4 from the "Mode
   of Operation" space [to be removed upon publication:
   http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550].

     +-------+---------------------------------------+---------------+
     | Value |              Description              |   Reference   |
     +-------+---------------------------------------+---------------+
     |   4   | P2P Route Discovery Mode of Operation | This document |
     +-------+---------------------------------------+---------------+

                             Mode of Operation

14.2.  Additions to RPL Control Message Options

   This document defines two new RPL options:

   o  "P2P Route Discovery Option" (see Section 7.1), assigned a value
      of 0x0A from the "RPL Control Message Options" space [to be
      removed upon publication: http://www.iana.org/assignments/rpl/
      rpl.xml#control-message-options] [RFC6550].

   o  "Data Option" (see Section 7.2), assigned a value of 0x0B from the
      "RPL Control Message Options" space [to be removed upon
      publication: http://www.iana.org/assignments/rpl/
      rpl.xml#control-message-options] [RFC6550].

              +-------+---------------------+---------------+
              | Value |       Meaning       |   Reference   |
              +-------+---------------------+---------------+
              |  0x0A | P2P Route Discovery | This document |
              |  0x0B |         Data        | This document |
              +-------+---------------------+---------------+

                        RPL Control Message Options

14.3.  Additions to RPL Control Codes

   This document defines the following new RPL messages:

   o  "Discovery Reply Object" (see Section 8), assigned a value of 0x04
      from the "RPL Control Codes" space [to be removed upon
      publication:
      http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
      [RFC6550].

   o  "Discovery Reply Object Acknowledgement" (see Section 10),
      assigned a value of 0x05 from the "RPL Control Codes" space [to be
      removed upon publication:
      http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
      [RFC6550].
   o  "Secure Discovery Reply Object" (see Section 8.1), assigned a
      value of 0x84 from the "RPL Control Codes" space [to be removed
      upon publication:
      http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
      [RFC6550].

   o  "Secure Discovery Reply Object Acknowledgement" (see Section 10),
      assigned a value of 0x85 from the "RPL Control Codes" space [to be
      removed upon publication:
      http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
      [RFC6550].

   +------+--------------------------------------------+---------------+
   | Code |                 Description                |   Reference   |
   +------+--------------------------------------------+---------------+
   | 0x04 |           Discovery Reply Object           | This document |
   | 0x05 |   Discovery Reply Object Acknowledgement   | This document |
   | 0x84 |        Secure Discovery Reply Object       | This document |
   | 0x85 |        Secure Discovery Reply Object       | This document |
   |      |               Acknowledgement              |               |
   +------+--------------------------------------------+---------------+

                             RPL Control Codes

14.4.  New Registry for Upper Layer Headers inside Data Option

   The Data Option (see Section 7.2) defines a 4-bit "Upper" field, for
   which IANA is requested to create and maintain a new registry titled
   "Upper Layer Header Type Inside RPL Data Option".  New codes may be
   allocated in this registry only by an IETF Review [RFC5226].  Each
   code is tracked with the following characteristics:

   o  Value

   o  Description

   o  Reference

   The following codes are currently defined:

                 +---------+-------------+---------------+
                 |  Value  | Description |   Reference   |
                 +---------+-------------+---------------+
                 |   0x0   |  UDP Header | This document |
                 | 0x1-0xE |  Unassigned |               |
                 |   0xF   | Private Use | This document |
                 +---------+-------------+---------------+

              Upper Layer Header Types Inside RPL Data Option




----- Original Message -----
From: "Michael Richardson" <[e-mail]>
To: "Mukul Goyal" <[e-mail]>
Cc: [e-mail]
Sent: Sunday, May 6, 2012 2:18:10 PM
Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt


>>>>> "Mukul" == Mukul Goyal <[e-mail]> writes:
    Mukul> This version takes care of all the tickets created for last
    Mukul> call comments.  

    Mukul> To see the text specific to a particular ticket "xx", search
    Mukul> for "\begin issue_xx" in: 

    Mukul> https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-rpl-10.txt 

Thank you that was helpful.

I reopened ticket #88.

http://trac.tools.ietf.org/wg/roll/trac/ticket/88

  The resolution in -10 is acceptable, but is not complete. "The other
  values are reserved at present." is not enough. We need an amending
  formula as part of the IANA instructions. I suggest Standards Action.
  http://tools.ietf.org/html/rfc5226 section 4.2 gives details. IANA also
  asks that you refer to the registry by URL that you want to allocate 
  for the other three code point allocations you have made.  You can
  suggest values as you have, but they are supposed to be suggestions..

Also, you might want reserve 0xf as Private Use.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [e-mail] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.