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

From: [email-masked]
Date: Fri, 04 May 2012 15:22:47 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

	Title           : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks
	Author(s)       : Mukul Goyal
                          Emmanuel Baccelli
                          Matthias Philipp
                          Anders Brandt
                          Jerald Martocci
	Filename        : draft-ietf-roll-p2p-rpl-10.txt
	Pages           : 33
	Date            : 2012-05-04

   This document specifies a point-to-point route discovery mechanism,
   complementary to the RPL core functionality.  This mechanism allows
   an IPv6 router to discover "on demand" routes to one or more IPv6
   routers in the LLN such that the discovered routes meet specified
   metrics constraints.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-10.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 4 May 2012 17:26:09 -0500 (CDT)

Hi all

This version takes care of all the tickets created for last call comments. 

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

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

Thanks
Mukul

----- Original Message -----
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Sent: Friday, May 4, 2012 5:22:47 PM
Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 May 2012 15:18:10 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> 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[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 7 May 2012 04:35:58 -0500 (CDT)

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" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: [email-masked]
Sent: Sunday, May 6, 2012 2:18:10 PM
Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt

I reopened ticket #88.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 May 2012 09:40:35 -0400

<#part sign=pgpmime>

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> Does the following text meets your concerns?

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

I had suggested "standards action", but IETF Review is as strong or
stronger.  So I'm happy.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 7 May 2012 09:13:48 -0500 (CDT)

stronger.  So I'm happy.

I did not want to allow only standards track documents to allocate a code.

Thanks
Mukul

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: [email-masked]
Sent: Monday, May 7, 2012 8:40:35 AM
Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt

<#part sign=pgpmime>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 May 2012 10:30:30 -0400

>> I had suggested "standards action", but IETF Review is as strong
    Mukul> stronger.  So I'm happy.

    Mukul> I did not want to allow only standards track documents to
    Mukul> allocate a code.

Standards Track documents could in theory be individual submissions,
going straight to the RFC-EDITOR (IMAP was done this way), but in
practice they wind up being reviewed by the IESG anyway.