Subject: Lack of responses on WG Last Calls

From: Brian Haberman <[email-masked]>
Date: Thu, 16 Dec 2010 08:53:04 -0500

All,
    Working group last calls ended 10 days ago for the two RPL-related
drafts (draft-ietf-6man-rpl-option and
draft-ietf-6man-rpl-routing-header). By my count, each draft received
*1* comment.  The chairs cannot and will not advance a draft to the IESG
with so little feedback.  We request that WG participants review these
drafts and provide their feedback on them.

Regards,
Brian & Bob

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 16 Dec 2010 06:27:13 -0800

Hi Brian,

Don Sturek, chair for the ZigBee Alliance IPv6 standardization.

We are using both the drafts (draft-hui-6man-rpl-headers and
draft-ietf-6man-rpl-routing-header) for our interoperability testing.  Here
is some background:
1)  We have 9 implementing companies all doing non-storing ROLL RPL using
downward routing
2)  We started interop testing in January 2010, meet every month and have
been testing downward routing for around 4 months
3)  We have not run into any issues (we have contact with Jonathan Hui and
JP so may have let them  know of any issues but I don't recall them).  I can
send you one of our recent interop reports under our ZigBee-IETF liaison
agreement if you are interested.

We would be interested in seeing these drafts move forward in the WG.  We
think they are essential to implementing non-storing ROLL RPL.  By the way,
our target deployment is for Smart Metering applications in the home area
network.  I added Fred Baker who chairs the Smart Power group who is aware
of our work.

Sorry for not letting you know about this earlier.

Best,

Don Sturek
Chair, ZigBee Core Stack Working Group (responsible for standardization of
the "ZigBee IP")

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Thursday, December 16, 2010 5:53 AM
To: IPv6 WG Mailing List
Subject: Lack of responses on WG Last Calls

All,

Regards,
Brian & Bob
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Dec 2010 12:37:50 +1300

For my sins, I was the Gen-ART reviewer for the main RPL spec,
so I was able to have a quick glance at these without being
completely mystified.

On 2010-12-17 02:53, Brian Haberman wrote:
> drafts (draft-ietf-6man-rpl-option 

This looks basically OK to me. However:

> 9.  IANA Considerations
> 
>    The RPL option requires an IPv6 Option Number.

Shouldn't we have a "TBD" here, as used in the main text?
And an instruction to the RFC Editor to resolve the TBD
after IANA performs the assignment.

> 
>    HEX         act  chg  rest
>    ---         ---  ---  -----
>      1          01    1  01011
> 
> 
>    The first two bits indicate that the IPv6 node MUST discard the
>    packet if it doesn't recognize the option type, and the third bit
>    indicates that the Option Data may change en-route.
> 
>    This document also creates a new IANA registry for the sub-TLVs.  No
>    sub-TLVs are defined in this specification.  The policy for this
>    registry [RFC5226] is IETF Review.

I think the IANA will ask for a bit more guidance about the format
and name of this registry.

and
> draft-ietf-6man-rpl-routing-header). 

This defines a new routing header called RH4 (subject to
IANA confirming the "4"). One question that comes to mind
is whether this is going to cause more or fewer operational
difficulties than an instantiation of draft-ietf-6man-exthdr
would. Will legacy nodes treat RH4 as they should (discard the
packet), treat it like RH0 due to sloppy coding (which
amounts to the same thing under RFC5095) or what? Anyway,
it seems clear that RH4 will not successfully cross any
non-RPL-aware routers.

Now this may be deemed irrelevant because RH4 is "for use
strictly within a RPL domain." But it seems highly likely that
in practice, the odd non-RPL router will see one of these
headers. So at the least, I think the draft should discuss
what will happen in that case, even if only to point out that
the rules of RFC 2460 mean that the packet (not just the header)
will be dropped unless Segments Left is zero.

Then:

> 6.1.  Source Routing Attacks
> 
>    [RFC5095] deprecates the Type 0 Routing header due to a number of
>    significant attacks that are referenced in that document.  Such
>    attacks include network discovery, bypassing filtering devices,
>    denial-of-service, and defeating anycast.
> 
>    Because this document specifies that Type 4 Routing headers are only
>    for use within a RPL domain, such attacks cannot be mounted from
>    outside the RPL domain.  As described in Section 5, RPL Border
>    Routers MUST drop datagrams entering or exiting the RPL domain that
>    contain a Type 4 Routing header in the IPv6 Extension headers.

OK, but that implies that such attacks can still be mounted inside the
RPL domain. How is that OK, given that ROLL may be deployed in highly
dynamic scenarios where roaming nodes drop into a network at will?

   Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Dec 2010 15:55:40 -0800

Don - see 

http://www.ietf.org/rfc/rfc1246.txt
1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format:
     TXT=70441, PS=141924, PDF=84633 bytes) (Also RFC1247, RFC1245)
     (Status: INFORMATIONAL)

When we advance a routing protocol to Proposed Standard, for reasons related to ancient IESG history related to routing, we generally require a test report that shows interoperable implementations of the standard in question. As you can imagine, there was an NDA around the various events RFC 1246 reports - you won't find comments on the fact that Cisco's initial implementation of OSPF was a demon's delight, but you will find comments on who tested, and what the outcome of the testing was after we (yes, I was there, while working at ACC) all fixed our bugs.

It would be very helpful if you could, with the implementors in question, filed a report on the testing.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 16 Dec 2010 16:48:58 -0800

Hi Fred,

Thanks for the note.  We (the ZigBee team) will create a test report for
what we have tested.  Should have a draft soon (we will try to have
something by the end of next week since we already have the test reports and
just need to recast them as a draft and highlight the v6man draft tests)

Don

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 3:56 PM
To: [email-masked]
Cc: 'Brian Haberman'; 'IPv6 WG Mailing List'; 'JP Vasseur'
Subject: Re: Lack of responses on WG Last Calls

Don - see 

When we advance a routing protocol to Proposed Standard, for reasons related
to ancient IESG history related to routing, we generally require a test
report that shows interoperable implementations of the standard in question.
As you can imagine, there was an NDA around the various events RFC 1246
reports - you won't find comments on the fact that Cisco's initial
implementation of OSPF was a demon's delight, but you will find comments on
who tested, and what the outcome of the testing was after we (yes, I was
there, while working at ACC) all fixed our bugs.

It would be very helpful if you could, with the implementors in question,
filed a report on the testing.

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Dec 2010 16:53:38 -0800

Cool

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Dec 2010 07:41:43 -0500

Fred Baker <[email-masked]> writes:

> When we advance a routing protocol to Proposed Standard, for reasons
>  related to ancient IESG history related to routing, we generally
>  require a test report that shows interoperable implementations of
>  the standard in question.

And FWIW, I think that requirement expired and has long been OBE.

See RFC 4794 "RFC 1264 Is Obsolete"

While getting a routing/interoperability report is a fine thing to do,
it is not and should not be a requirement to advance this (or any)
draft to PS.

This draft should advance on its own merits (on which I have not
opinion).

Thomas

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Dec 2010 05:36:28 -0800

> This draft should advance on its own merits (on which I have not

The fact is that the working group is trying to decide n something and Zigbee has relevant data. I'm simply asking for an appropriately-redacted version of the report to be made public.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Dec 2010 09:01:22 -0500

> The fact is that the working group is trying to decide n something
>  and Zigbee has relevant data. I'm simply asking for an
>  appropriately-redacted version of the report to be made public.

Works for me. I just didn't want anyone to think this was a IETF
*requirement*.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Dec 2010 08:35:59 -0800

Thomas,

> See RFC 4794 "RFC 1264 Is Obsolete"

I am the author of RFC1264 and was the Routing AD when it was written.  I completely agree with making it Historic.   The abstract of RFC4794 says it well:

   RFC 1264 was written during what was effectively a completely
   different time in the life of the Internet.  It prescribed rules to
   protect the Internet against new routing protocols that may have
   various undesirable properties.  In today's Internet, there are so
   many other pressures against deploying unreasonable protocols that we
   believe that existing controls suffice, and the RFC 1264 rules just
   get in the way.

RFC1264 was useful when it was written in 1991, but the world has changed many ways and it is no longer necessary.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Dec 2010 08:43:43 -0800

Fred,

> The fact is that the working group is trying to decide n something and Zigbee has relevant data. I'm simply asking for an appropriately-redacted version of the report to be made public.

Sharing implementation experience is always good thing to assist a w.g. to make a decision on advancing a document.  I look forward to it.

While we may not have kings in the IETF, a bit more running code would be a good thing!

Thanks,
Bob