Subject: [Ace] ACE Charter Proposal v0.5

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Mar 2014 08:50:59 +0100

Hi all,

I have taken the feedback from the meeting and the recent discussions on
the mailing list and produced a new strawman proposal.

The changes include:
 * Added the focus on DTLS/CoAP with an indication that we will check a
candidate solution for suitability with HTTP/TLS.
 * Added text to indicate that we will also verify the suitability of
the solution for use with protocol translation proxies.
 * Simplified the task list by removing solution specific items.
 * Merged several items on the task list (use cases, requirements, and
protocol design guidelines). Followed the suggestion to use of a Wiki
for capturing those.

What do you think?

-----

Draft Charter V0.5 - Authentication and Authorization for Constrained
Environment (ACE)

The IETF has recently developed protocols for use in environments where
network nodes are limited in CPU, memory, and power. It was observed
that Internet protocols can be applied to these constrained
environments, often only requiring minor tweaking and profiling. In
other cases, new protocols have been defined to address the specific
requirements of constrained devices and networks. An example of such a
protocol is the Constrained Application Protocol (CoAP).
components
As in other environments, authentication and authorization question also
arise in environments with constrained nodes and networks. For example,
a door lock has to authorize the person seeking access using a "digital
key". Where are the authorization decisions stored? How does the digital
key communicate with the lock? Does the lock interact with an
authorization server to obtain authorization information? How can access
be granted to other persons temporarily? How can access be revoked?
These types of questions have been answered by existing protocols for
use cases outside the constrained environment. But in constrained
environment, additional requirements pose challenges for the use of
various security protocols.

The IETF has a long history in developing three party authentication and
authorization protocols for distributed environments. Examples include
Kerberos, the Public Key Infrastructure (PKI), the Authentication,
Authorization, and Accounting (AAA) infrastructure, and the Web
Authorization Protocol (OAuth). All these protocols enjoy widespread
deployment on the Internet. Although they all aim to solve a similar
goal, at an abstract level, they offer quite different functions and
utilize different message exchanges. These differences are motivated by
the main deployment use cases they were designed for.

Requirements derived from use cases indicate the suitability of already
existing work, such as OAuth, as a solution for constrained
environments. These protocols were, however, not optimized for
constrained environments. Additional requirements that need to be taken
into account are the lack of a suitable user-interface for obtaining the
consent of the user and the inability of embedded devices to contact an
authorization server in real-time with every access request due to
intermittent connectivity, etc.

This working group therefore aims for a standardized solution for
authentication and authorization to enable authorized access to
resources in constrained environments. As a starting point, the working
group will assume that access to resources offered by a resource server
by a client devices takes place using CoAP and is protected by DTLS.
Both resource server and client may be resource constraint. This access
will be mediated by an authorization server, which does not suffer from
the same resource limitations.

Existing authentication and authorization protocols are used and
re-applied for use with constrained devices, where applicable. This
requires relevant specifications to be reviewed for suitability,
selecting a subset of them, restricting the options within each of the
specifications. Some functionalities may, however, not be available in
existing protocols and for those cases new functionality has to be
standardized. Thus, existing work can be leveraged and the group
benefits from available security analysis, implementation, and
deployment experience. Moreover, a standardized solution for federated
authentication and authorization will help to stimulate the deployment
of IoT devices offering increased security.

Once progress in identifying suitable candidate solutions has been made
the working group will verify whether the same mechanism are also
applicable beyond the use of CoAP and DTLS. In particular, the ability
to use the developed solution over HTTP and TLS will be investigated.
Furthermore, to guarantee smooth transition the integration with
existing deployment will be studied. This particularly concerns the use
of protocol translation proxies.

To be successful this working group requires expertise in security,
privacy, and a good understanding of usability in the constrained
environment space. This work does not make the assumption that the party
offering application layer services is always the same party offering
network access services.

The working group has the following tasks (in this order):

1) The working group Wiki pages will be used to document use cases,
requirements, and protocol design criteria. This work will guide the
identification of suitable protocol mechanisms.

2) Selection of an authentication and authorization protocol for
constrained environments.

3) Evaluation of the candidate solution for use with HTTP/TLS and proxy
deployments.

-----

Ciao
Hannes

---

From: Zach Shelby <[email-masked]>
Date: Tue, 11 Mar 2014 08:49:19 -0700

Hannes,

I am happy with this charter with one exception. The proxy item here seems to be more of a distraction than anything else, and will probably result in increased complexity. Was proxy support maybe just a misunderstanding? Do we really see the need for a proxy in the middle of I or III?

I think what we really want here is to make sure that e.g. even through I is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In other words, some interfaces can be constrained while others are not. I think the charter already covers this fine.

So my proposal would be to remove the mention of protocol translation proxies. If we really see the need for this some day in the future, it could be tackled then.

Zach

On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig <[email-masked]> wrote:

> <signature.asc>_______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 11 Mar 2014 17:37:29 -0400

Hi Zach,

Don't we need to consider Proxies even for the CoAP/DTLS case?  As you
know, the base CoAP spec has extensive support for Proxies (both forward
and reverse).  So I for one think that we should support Proxy even for
the CoAP/DTLS scenario.

Best Regards,

Akbar

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Tuesday, March 11, 2014 11:49 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ace] ACE Charter Proposal v0.5

Hannes,

I am happy with this charter with one exception. The proxy item here
seems to be more of a distraction than anything else, and will probably
result in increased complexity. Was proxy support maybe just a
misunderstanding? Do we really see the need for a proxy in the middle of
I or III?

I think what we really want here is to make sure that e.g. even through
I is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In
other words, some interfaces can be constrained while others are not. I
think the charter already covers this fine.

So my proposal would be to remove the mention of protocol translation
proxies. If we really see the need for this some day in the future, it
could be tackled then.

Zach

On Mar 11, 2014, at 12:50 AM, Hannes Tschofenig
<[email-masked]> wrote:

> Hi all,
>
> I have taken the feedback from the meeting and the recent discussions 
> on the mailing list and produced a new strawman proposal.
>
> The changes include:

> The IETF has recently developed protocols for use in environments 
> where network nodes are limited in CPU, memory, and power. It was 
> observed that Internet protocols can be applied to these constrained 

> As in other environments, authentication and authorization question 
> also arise in environments with constrained nodes and networks. For 
> example, a door lock has to authorize the person seeking access using 
> a "digital key". Where are the authorization decisions stored? How 
> does the digital key communicate with the lock? Does the lock interact

> with an authorization server to obtain authorization information? How 
> can access be granted to other persons temporarily? How can access be
revoked?
> The IETF has a long history in developing three party authentication 
> and authorization protocols for distributed environments. Examples 
> include Kerberos, the Public Key Infrastructure (PKI), the 
> Authentication, Authorization, and Accounting (AAA) infrastructure, 
> and the Web Authorization Protocol (OAuth). All these protocols enjoy 
> widespread deployment on the Internet. Although they all aim to solve 
> a similar goal, at an abstract level, they offer quite different 
> functions and utilize different message exchanges. These differences 
> are motivated by the main deployment use cases they were designed for.
>
> Requirements derived from use cases indicate the suitability of 
> already existing work, such as OAuth, as a solution for constrained 
> constrained environments. Additional requirements that need to be 
> taken into account are the lack of a suitable user-interface for 
> obtaining the consent of the user and the inability of embedded 
> devices to contact an authorization server in real-time with every 
> access request due to intermittent connectivity, etc.
>
> resources in constrained environments. As a starting point, the 
> working group will assume that access to resources offered by a 
> resource server by a client devices takes place using CoAP and is
protected by DTLS.
> Both resource server and client may be resource constraint. This 
> access will be mediated by an authorization server, which does not 
> suffer from the same resource limitations.
>

> Once progress in identifying suitable candidate solutions has been 
> made the working group will verify whether the same mechanism are also

> existing deployment will be studied. This particularly concerns the 
> use of protocol translation proxies.
>
> environment space. This work does not make the assumption that the 
> party offering application layer services is always the same party 
> offering network access services.
>
> 3) Evaluation of the candidate solution for use with HTTP/TLS and 
> proxy deployments.
>
> -----
>
> Ciao
> Hannes
>

Zach Shelby
Director of Technology

-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No:  2557590 ARM Holdings plc,
Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
England & Wales, Company No:  2548782

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 Mar 2014 16:58:27 -0500

Hi Hannes,

Is there an architecture for the proposed work?

I think that it could help to come up with a simple architecture.

Regards,

Behcet

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Mar 2014 20:46:30 +0100

Yes. The architecture is part of the solution description.

The question you are asking is whether it should be in a separate
document or combined with the actual solution.

My experience from other working groups is that there will be all sorts
of arguments for having various different profiles for use case X and
use case Y. In that case it makes sense to come up with a separate
architecture document that gives the reader the overview.

Luckily, we are not yet at that point. So, let's worry about the
document management later.

Ciao
Hannes

On 03/11/2014 10:58 PM, Behcet Sarikaya wrote:
> On Tue, Mar 11, 2014 at 2:50 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Mar 2014 20:51:05 +0100

Interesting question and I let Zach and other CoAP experts respond to it.

In the BOF, however, we have only spoken about protocol translation
proxies in the context of allowing protocols other than CoAP to be
supported.

So, you are bringing up another topic in the charter discussion, which
is almost a question to the CORE working group about their ideas for
using DTLS with proxies in general.

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Wed, 12 Mar 2014 09:32:36 +0000

Hannes, Zach and all,

I must say I don¹t find the task list of the current charter very helpful:

³The working group has the following tasks (in this order):

deployments.²

This list does not give much more details about the work to be conducted
than is already given by the title of the WG. To a person not having
followed the discussion, the impression is that the work starts from
scratch and there is no clear understanding of what to do.

If we can¹t formulate the problem statement and first step towards a
solution in some degree of detail before starting the WG that will anyway
be the first task to do, so let¹s try to get something in writing.

"1) The working group Wiki pages will be used to document use cases,
requirements, and protocol design criteria. This work will guide the
identification of suitable protocol mechanisms."

This is hiding the fact that there has been 6 months of work on the use
case and requirements draft (the first version of this draft was submitted
to CoRE in IETF88), which no one has disagreed is setting the stage for
this work. Look at parallel threads on this mailing list where people ask
whether their particular security-for-IoT draft fits into ACE. The answer
Hannes is giving is correctly: the scope of this work is what is outlined
by the use case and requirements draft. I don¹t mind using the Wiki as a
working tool but this does not give traceability a year later. And I don¹t
see the point if copying the use case document into a Wiki page - read the
draft and provide your comments!

When it comes to protocol design criteria, I agree that more work is
needed, for which the Wiki may be suitable. Nevertheless I insist on
documenting the design criteria and its rationale since that provides a
means for traceability. Make it a milestone to have a draft with
assumptions and design criteria  (you may include ³architecture² in this
document). This work is anyway a pre-requisite for coming to a solution,
and once you have this content, the candidate solutions are much easier
evaluated.

So, change 1) to state something like

"1¹ )
a) complete the work on use case and requirements
b) use Wiki pages for listing assumptions and protocol design criteria,
document the result in a draft"

Proxy deployment aspects fits well into 1b)  [more in separate upcoming
mail]

Here I¹m missing among other things the specific problem statement. The
preliminary conclusions from the use case and requirements draft formed
the basis for the problem statement as presented in the BOF: We lack a
mechanism for dynamic and fine grained access control for constrained
environments. 

The process here should be to:
"2¹) identify suitable protocol mechanisms and match candidate
authentication and authorization protocols against requirements and design
criteria, in particular addressing dynamic and fine grained access control
suitable for CoAP resource access requests in constrained environments."

deployments.²

As mentioned above, proxy deployments could be considered as part of 1¹b).
In 2¹) it is already stated that in particular we should consider CoAP on
interface (II). As for use of other protocols besides CoAP that issue is
orthogonal to this so I leave that out from this discussion.

Göran

On 11/03/14 16:49, "Zach Shelby" <[email-masked]> wrote:

>I think what we really want here is to make sure that e.g. even through I
>is based on HTTP/TLS, II and III for example can run CoAP/DTLS. In other
>words, some interfaces can be constrained while others are not. I think
>the charter already covers this fine.
>
>Registered in England & Wales, Company No:  2557590
>ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No:  2548782
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Mar 2014 21:33:04 +0100

Hi Goeran,

I read a little bit between the lines of your mail and your main concern
is that you want to have an RFC published with your name on it.
A wiki page to document the requirements, and use cases is not good
enough for you.

For you putting the draft text on a WG wiki feels like wasted time.
It is just a different form of documenting the work.

My experience with use cases and requirements has not been great in the
IETF. In essence everyone quickly moves on once the group decides about
a particular solution direction. It then becomes very hard (for the
chairs) to finish the requirements work since nobody wants to review or
look at them anymore.

Use cases and requirements are great during the initial part of the work
to get an understanding of the main challenges.

Having said that I will leave it to the group to decide what they want
to do: RFCs or Wiki page

Ciao
Hannes

PS: Regarding your other comment about pointing to the constraint nature
to every item. We can do that if you feel better but the entire charter
page already says 10 times that we are focusing on the constraint space.
I am sure that the reader will have understood that when they get to the
task list.

---

From: Likepeng <[email-masked]>
Date: Thu, 13 Mar 2014 08:28:54 +0000

My personal opinion is that the use case and requirements document can help people to understand what kind of issues we are trying to resolve.

I can see some values to publish it into RFCs. If it is a wiki page, we will have less people to review it or improve it. 

Especially the use case and requirement document is already in a good shape and it is referenced several times in the mailing list to introduce our work to outside.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Hannes Tschofenig
> 发送时间: 2014年3月13日 4:33
> 收件人: Göran Selander; Zach Shelby
> 抄送: [email-masked]
> 主题: Re: [Ace] ACE Charter Proposal v0.5
> 
> Hi Goeran,
> 
> I read a little bit between the lines of your mail and your main concern is that
> you want to have an RFC published with your name on it.
> A wiki page to document the requirements, and use cases is not good enough
> for you.
> 
> My experience with use cases and requirements has not been great in the IETF.
> In essence everyone quickly moves on once the group decides about a
> particular solution direction. It then becomes very hard (for the
> chairs) to finish the requirements work since nobody wants to review or look
> at them anymore.
> 
> Use cases and requirements are great during the initial part of the work to get
> an understanding of the main challenges.
> 
> Having said that I will leave it to the group to decide what they want to do:
> RFCs or Wiki page
> 
> Ciao
> Hannes
> 
> PS: Regarding your other comment about pointing to the constraint nature to
> every item. We can do that if you feel better but the entire charter page
> already says 10 times that we are focusing on the constraint space.
> I am sure that the reader will have understood that when they get to the task
> list.
> 
> 
> > proxy deployments.²
> > This list does not give much more details about the work to be
> > conducted than is already given by the title of the WG. To a person
> > not having followed the discussion, the impression is that the work
> > starts from scratch and there is no clear understanding of what to do.
> >
> > solution in some degree of detail before starting the WG that will
> > anyway be the first task to do, so let¹s try to get something in writing.
> >
> >
> > This is hiding the fact that there has been 6 months of work on the
> > use case and requirements draft (the first version of this draft was
> > submitted to CoRE in IETF88), which no one has disagreed is setting
> > the stage for this work. Look at parallel threads on this mailing list
> > where people ask whether their particular security-for-IoT draft fits
> > into ACE. The answer Hannes is giving is correctly: the scope of this
> > work is what is outlined by the use case and requirements draft. I
> > don¹t mind using the Wiki as a working tool but this does not give
> > traceability a year later. And I don¹t see the point if copying the
> > use case document into a Wiki page - read the draft and provide your
> comments!
> >
> > documenting the design criteria and its rationale since that provides
> > a means for traceability. Make it a milestone to have a draft with
> > assumptions and design criteria  (you may include ³architecture² in
> > this document). This work is anyway a pre-requisite for coming to a
> > solution, and once you have this content, the candidate solutions are
> > much easier evaluated.
> >
> > b) use Wiki pages for listing assumptions and protocol design
> > criteria, document the result in a draft"
> >
> > Proxy deployment aspects fits well into 1b)  [more in separate
> > upcoming mail]
> >
> >
> > Here I¹m missing among other things the specific problem statement.
> > The preliminary conclusions from the use case and requirements draft
> > formed the basis for the problem statement as presented in the BOF: We
> > lack a mechanism for dynamic and fine grained access control for
> > authentication and authorization protocols against requirements and
> > design criteria, in particular addressing dynamic and fine grained
> > access control suitable for CoAP resource access requests in constrained
> environments."
> >
> >
> >
> > proxy deployments.²
> > In 2¹) it is already stated that in particular we should consider CoAP
> > on interface (II). As for use of other protocols besides CoAP that
> > issue is orthogonal to this so I leave that out from this discussion.
> >
> >
> >
> > Göran
> >
> >
> >
> >
> >
> >> seems to be more of a distraction than anything else, and will
> >> probably result in increased complexity. Was proxy support maybe just
> >> a misunderstanding? Do we really see the need for a proxy in the
> >> middle of I or III?
> >>
> >> I think what we really want here is to make sure that e.g. even
> >> through I is based on HTTP/TLS, II and III for example can run
> >> CoAP/DTLS. In other words, some interfaces can be constrained while
> >> others are not. I think the charter already covers this fine.
> >>
> >> proxies. If we really see the need for this some day in the future,
> >> it could be tackled then.
> >>
> >> Zach
> >>
> >>> I have taken the feedback from the meeting and the recent
> >>> discussions on the mailing list and produced a new strawman proposal.
> >>>
> >>> The changes include:
> >>> * Added the focus on DTLS/CoAP with an indication that we will check
> >>> a candidate solution for suitability with HTTP/TLS.
> >>> * Merged several items on the task list (use cases, requirements,
> >>> and protocol design guidelines). Followed the suggestion to use of a
> >>> Wiki for capturing those.
> >>>
> >>> What do you think?
> >>>
> >>> -----
> >>>
> >>> Draft Charter V0.5 - Authentication and Authorization for
> >>> Constrained Environment (ACE)
> >>>
> >>> requirements of constrained devices and networks. An example of such
> >>> a protocol is the Constrained Application Protocol (CoAP).
> >>> components
> >>> example, a door lock has to authorize the person seeking access
> >>> using a "digital key". Where are the authorization decisions stored?
> >>> How does the digital key communicate with the lock? Does the lock
> >>> interact with an authorization server to obtain authorization
> >>> information? How can access be granted to other persons temporarily?
> How can access be revoked?
> >>> These types of questions have been answered by existing protocols
> >>> for use cases outside the constrained environment. But in
> >>> constrained environment, additional requirements pose challenges for
> >>> the use of various security protocols.
> >>>
> >>> and the Web Authorization Protocol (OAuth). All these protocols
> >>> enjoy widespread deployment on the Internet. Although they all aim
> >>> to solve a similar goal, at an abstract level, they offer quite
> >>> different functions and utilize different message exchanges. These
> >>> differences are motivated by the main deployment use cases they were
> designed for.
> >>>
> >>> resource server by a client devices takes place using CoAP and is protected
> by DTLS.
> >>> selecting a subset of them, restricting the options within each of
> >>> the specifications. Some functionalities may, however, not be
> >>> available in existing protocols and for those cases new
> >>> functionality has to be standardized. Thus, existing work can be
> >>> leveraged and the group benefits from available security analysis,
> >>> implementation, and deployment experience. Moreover, a standardized
> >>> solution for federated authentication and authorization will help to
> >>> stimulate the deployment of IoT devices offering increased security.
> >>>
> >>> made the working group will verify whether the same mechanism are
> >>> also applicable beyond the use of CoAP and DTLS. In particular, the
> >>> ability to use the developed solution over HTTP and TLS will be
> investigated.
> >> -- IMPORTANT NOTICE: The contents of this email and any attachments
> >> are confidential and may also be privileged. If you are not the
> >> intended recipient, please notify the sender immediately and do not
> >> disclose the contents to any other person, use it for any purpose, or
> >> store or copy the information in any medium.  Thank you.
> >>

---

From: Göran Selander <[email-masked]>
Date: Thu, 13 Mar 2014 11:53:36 +0000

Hi Hannes,

>A wiki page to document the requirements, and use cases is not good

Interesting comment. Could someone please tell me if I’ve broken some
etiquette and deserve this treatment?

>chairs) to finish the requirements work since nobody wants to review or

OK - this is exactly my point: If you don’t complete the use case and
requirements work there is no traceability. I hear something similar on
the list.

>I am sure that the reader will have understood that when they get to the

"your other comment about pointing to the constraint nature to every item”
???

- I proposed to explicitly include the detailed problem statement we used
in the BOF which is missing not only in the task description.

- I proposed to specifically mention CoAP in access request (i.e.
Interface II) in the task description, which seems to be consensus on the
list.

(Again, did I break some etiquette by explicitly proposing charter text?
Was this “nit picking”? What went wrong?)

Göran

>>anyway
>>design
>>on
>>>through I
>>>>on
>>>>where
>>>>also
>>>>and
>>>>already
>>>>taken
>>>>working
>>>>access
>>>>made
>>>>party
>>>>proxy

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 02:21:50 +0100

Hi Goeran,

sorry if I was a bit too direct and went straight down to the meat of
your comment.

Regarding the "traceability" note that requirements have never been a
sort of "contract". Whenever there are reasons to violate the
requirements then this has been done. For example, the group may gain
some new insight during the solution work.

But as I said, I listen to the group when it comes to this issue.

There is, however, an interesting aspect to your remark in your email
below. Are you suggesting that we should sequence the work meaning that
solution work should only start after the use cases are finished? That
has advantages and disadvantages but it certainly has an impact on the
milestones. You seem to be saying "yes, they should be sequenced" and I
also see Margaret’s mail to the list saying "no".

Regarding to the charter I will post a mail to the list and hopefully it
meets your needs.

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Thu, 13 Mar 2014 14:02:32 +0000

Hi Hannes

>sorry if I was a bit too direct and went straight down to the meat of

Well, I disagree with your interpretation of "the meat” of my comment, but
I think I’ve made my point clear, so let’s leave it at that.

>also see Margaret’s mail to the list saying "no".

I don’t have a strong opinion here and certainly do not insist on a
“waterfall” design model. It could be fruitful to elaborate on different
requirements as long as you are aware of what requirements you break and
what the consequences might be in terms of e.g. supported use cases or
security.

Göran

>>>>conducted
>>>>use
>>>>a
>>>>this
>>>>upcoming
>>>>The
>>>>>probably
>>>>>it
>>>>>>discussions
>>>>>>for
>>>>>>the
>>>>>are

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 16:27:13 +0100

> what the consequences might be in terms of e.g. supported use cases or

I have seen both approaches being used and there are advantages and
disadvantages. The benefit is that it forces folks to agree on the
requirements early rather to push them into the solution space. On the
other hand, everyone has some solutions in mind and hence they argue for
their solution via requirements.

If you move on too early there is the risk that you haven't actually
concluded the use case/requirements discussion. If you start too late
people moved on to do other things already and the work becomes irrelevant.

Ciao
Hannes