Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group.

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 18 Aug 2012 20:05:33 +0100

I don't think Discusses work like that.
You don't get to throw new revisions at the IESG and ask them to determine
whether the new revision addresses their concerns.

The way it works is first you Discuss. Then you agree what changes are going to
be made (if any). Then you update the document (if necessary). At this point the
AD with the Discuss will be happy to clear.

So to turn it around, the AD (who has been patiently holding this Discuss for so
long, and who inherited it from his predecessor) is waiting for the working
group  authors / shepherd to enter into discussion and propose updates.

I think I failed on this document when I agreed to the publication request: I
should have spotted exactly the issue that the Security ADs complained about.
Had I spotted it, I would have returned the I-D to the WG before IESG
evaluation.

But, look, where is this going?

The right thing to do is to publish documents with the right content. As Michael
said, the problem with the Security Framework document is that it does not
answer the *how* and *why* of what security to apply in what places. While it
does an *AWESOME* job of identify threats it doesn't tell us which protocol
mechanisms deal with what threats.

What we need to do is develop and publish text to address all of these things.
There were, thus, two options for this document:
1) Add substantial text to answer the how and why 
2) Re-shape it as just a Security Threat Analysis

Note that both of these options require the document to be returned to the
working group.
A third option was rejected in discussions between the WG chair, sponsoring AD,
and Discussing AD because both of the ADs agree with the Discuss.
3) Debate and reject the Discuss

The authors, chairs, and AD consider option 2) to be more productive. It will
result in this document being turned around quickly and re-submitted for
publication under a slightly different name with most of its text intact, but
with some sections pruned. It will require the new and substantive text to be
developed and published in new I-Ds.

In sanctioning this approach, the Discussing AD is committing to not re-enter
the same Discuss when the Threat Analysis comes before him for evaluation. And
he is trusting the WG to do the work on the new drafts.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Abdussalam Baryun
> Sent: 18 August 2012 07:42
> To: roll
> Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working
group.
> 
> For the progress of this work, I was waiting for a respond from IESG's
> discuss position members (two positions comments was on draft-05)
> regarding the new I-D version 07, but still no comments/discuss known.
> Also waiting for the respond to the return from the WG. The only
> respond to the IETF-WG's draft-07 is that the document is returned
> without a reply comments of IESG's discuss position members. However,
> I will respond to this, that I disagree to return the document until a
> respond to draft-07 can be tracked, so the WG can decide for progress.
> 
> AB
> -----
> 
> On 8/13/12, Adrian Farrel <[email-masked]> wrote:
> > Yeah, hi.
> >
> > I think the thing you are missing is that it had become "impossible" to
> > resolve
> > the final Discuss. Of course, as described in the references you cite,
> > Discusses
> > must be "resolvable", but the work to resolve this Discuss is considerable
> > and
> > results in a significant set of documents being produced.
> >
> > The issue was as follows:
> >
> > - During processing of draft-ietf-roll-rpl there was a Discuss that said
> >    (approximately) "You haven't done enough security work".
> >    The response was: "Don't worry, it will show up in the security
> >    framework"
> > - However, the security framework (this draft) simply passes the
> >    buck to other future drafts.
> > - The Discuss says "show me the security work"
> >
> > There was an option to keep this document hanging on while that security
> > work
> > was done, or to put in place the plan (as explained by Michael) to run a
> > series
> > of documents that will together comprise the security details for RPL. In
> > that
> > plan, this document is reworked to be a Threat Analysis simply be removing
> > some
> > of the text, and polishing a little. It will then be re-issued, run through
> > the
> > WG and completed.
> >
> > The I-D did not expire until I marked it "Dead" in the data tracker. That
> > action
> > was in agreement with the chairs and as part of the plan for the set of
> > security
> > documents.
> >
> > Thanks,
> > Adrian
> >
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 19 Aug 2012 11:37:38 +0100

Hi Adrian,

I thank you very  much, I will do my best in future so this return issue
will not happen again. I understand now *how* the discuss process works,
thanking you,

Best Regards

AB
------

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 19 Aug 2012 12:18:05 +0100

> mechanisms deal with what threats.

 I think the document did n't have to explain *how* and *why*, because this
document is an informational framework not a standard/Best-Practice
framework. The job of the document was intended to give information of
identifying threats. I don't like a documet that has pages more than 50, so
I think this document can change its title and scope to clarify its use
(threats identification informational I-D), and a future standard I-D of
security framwork can have the *how* and *why* related to
protocol/mechanism.

AB

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Aug 2012 14:54:36 -0400

<#part sign=pgpmime>

>>>>> "Abdussalam" == Abdussalam Baryun <[email-masked]> writes:
    Abdussalam>  I think the document did n't have to explain *how* and
    Abdussalam> *why*, because this document is an informational
    Abdussalam> framework not a standard/Best-Practice framework. The

Some document, somewhere has to specify.
This document was conceived of as going to do that.
That it was presented as Informational was perhaps a mistake.

-- 
Michael Richardson
-at the cottage-

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 20 Aug 2012 16:47:52 +0100

I do not know why the direction is to have a security framework draft in
our working-stage in the first place, while we still have some issues
related to RPL and applicability, but it was ok to have an informational of
LLN routing threats without *why* and *how* of securing, as the way the
authors focused on threats. Until we complete applicability and RPL
performance (obtain large scale evaluiation results), then we may look into
security techniques related to RPL (documents only need security
considerations section not details), because we do routings (security
functions is done in IETF Security Area).

>That it was presented as Informational was perhaps a mistake.
If not having an informational framework, then I suggest to make the new
produced document attached to a mechanim or protocol (as MANET WG do), for
example: RPL-SEC, RPL.P2P-SEC, etc. without having a new document for
threat analysis.

I ask the WG to discuss this issue,

Regards
AB
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I maybe wrong and maybe right but it does not matter if we work as a group.
IETF WGs are always right.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---------------------------
On Sun, Aug 19, 2012 at 7:54 PM, Michael Richardson

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 23 Aug 2012 09:53:01 +0200

The last comments on this return
========================
IESG Discuss> 20-01-2011> I think this is a really good document, and
support its publication. I am specifically concerned about punting the
details on public key
distribution, then finding they are not covered here either. Did I get
the wrong document?  Where are those issues going to be addressed?

I agree that it provide good information as long we don't relate it to
another document or another purpose, and happy that you support
publication. I agree that it has not covered that security technique
purpose, but I think this draft can be base for future
specification/standard that will cover the issue refered to. I
recommend thoes issues are going to be addressed in a RPL-Security
standard I-D. Please not that there is no harm in passing this draft,
but it will encourage progress/efforts. If there was a harm in passing
the draft please reply.

IESG Discuss>05-05-2011> I believe that the core of AD's discuss is
that there is no specification for how the authenticated mode of
roll-rpl is to
be done, and specifically using public key based mechanisms
for key distribution.

If there was a harm in passing the draft please inform. This draft is
an *informational* not a standard track that may be why it does not
specify RPL authentication. This draft is a good introduction to a
future standard I-D.

IESG Discuss> 05-05-2011> I'd be happy to clear were there to be a
good specification of how to do e.g. a signature based authenticated
mode, or
a public key based way to distribute keys for an
authenticated mode, or even a kerberos-like way to
distribute secret keys for an authenticated mode. While this
will all be optional to implement, its absence is really
not consistent with bcp107.

I recommend a work either to be doing above request in an I-D
(standard) within Security Area (not in Routing Area) or in an I-D
(standard) that relates totally to RPL as RPL-Sec (standard) in this
WG.

Best Regards
AB

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 Aug 2012 13:37:10 +0100

Hi again Abdussalam,

> The last comments on this return

That's good to hear :-)

I think you should be happy with the outcome.
This I-D will be re-born with a large amount of the text in place. Because this
will be a significant change in the content of the document, it will need
renewed working group consensus and so return to the WG is necessary. However, I
expect this I-D to go forward quite soon.

The other security work, which you appear to support, is currently planned and
being hatched in the RPL working group.

So everything is good, the flowers are blooming, and the bunnies are hopping
around happily.

Cheers,
Adrian