Subject: RE: terminology (was Re: [midcom] Protocol Requirements Bullet List v2.0)

From: "Christian Huitema" <[email-masked]>
Date: Mon, 23 Apr 2001 07:15:53 -0700

In fact, I don't agree with that either. We can agree that the protocol
should be extensible to handle functions that are outside the "initial
scenarios", but we do not need to actually specify these functions. From
a scenario analysis, we need:

1) To open a hole based on a combination of addresses, protocol type,
and port numbers, any of which can possibly be replaced by wild cards.

2) To obtain the "external" mapping of an address + port pair.

That is about the end of our "functional" requirements. We have then
operational requirements, e.g. fate sharing or soft state, and security
requirements, e.g. authenticate the requestor of a command. 

-- Christian Huitema

> From: Paul Sijben [mailto:[email-masked]]
> 
> I agree we do not need to open it up. We do however need to identify
the
> functions of the middlebox and their parameters to see what the MIDCOM
> protocol needs to express.
> 
> Paul
> 
> Christian Huitema wrote:
> >
> > I don't believe that "opening the guts of the box" is particularly
> > useful. If we start from the scenarios document, we see only one
> > function of relevance, the passing/blocking/natting of packets based
on
> > addresses and port numbers. We should concentrate on that.
> >
> > -- Christian Huitema

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: [email-masked]
Date: Mon, 23 Apr 2001 10:34:54 -0400

From:  Tom Gray@MITEL on 04/23/2001 10:34 AM

There should also be distinct consideration of stakeholder and non-functional
requirements which seem to be being confounded with functional requirements in
the discussion.

There should also be a distinct category of 'non-functional' requirements that
describe how the functional requirements will operate. Non-functionals describe
the operation of a system but do not dictate it. So all issues of quality,
extendibility, responsivity ... fall within the NFR purview. They should be kept
distinct because they are not firmly bound to any set of functional requirements
or proposed solutions to these requirements. They act as parameters which can be
used to characterise the match of any proposed solution or set of functional
requirements to the stakeholder requirements which have been discovered earlier.

"Christian Huitema" <[email-masked]> on 04/23/2001 10:15:53 AM

To:   "Paul Sijben" <[email-masked]>
cc:   [email-masked] (bcc: Tom Gray/Kan/Mitel)

Subject:  RE: terminology (was Re: [midcom] Protocol Requirements Bullet List
      v2.0)

-- Christian Huitema

the
on