Subject: Re: [rrg] Fwd: Design Goals editorial feedback

From: RJ Atkinson <[email-masked]>
Date: Wed, 3 Nov 2010 09:22:24 -0400

Much earlier, RJ Atkinson wrote:
>> <http://www.postel.org/ien/pdf/ien001.pdf>

Earlier, Tony Li wrote:
> Unfortunately, this particular PDF file doesn't seem to render 
> properly on my system (MacOSX 10.6.4, Preview.app).  I was able 
> to render it using Adobe Reader.  Reference added.

Good point.  

There seems to be a bug/limitation/issue in some PDF readers that 
prevents them from displaying all pages of the PDF file of IEN-1 
at the URL quoted above.  As far as I know, IEN-1 is only available
in PDF, apparently because of some hand-drawn figures in the document.

So if others have run into the issue tli describes, they might
want to try the (no cost) Adobe PDF Reader application instead.

>> 3.10  Aside:
>>   Would it be OK if we said "capabilities" instead of "functionality" ?
> 
> I actually think that there's an important distinction here:
> there are many capabilities of the routing system today that
> are not in active use, such as deaggregation.  I don't think
> that an architecture needs to support all capabilities,
> as it means that we must propagate our overhead as well.

Interesting.  

Many people, including me, would say that "capabilities" has
the same meaning as "functionality".  My sense always has been
that the two words differed mainly in that "functionality" 
is a jargon non-word, while "capabilities" is actually in the 
dictionary.

Apparently, the document intends some different meaning for
"functionality".   I'm not at all sure what that might be.
If a native reader of English is unsure, then some folks 
who aren't native readers of English are very likely to be confused.  

Please rephrase this part of the text in some way that 
(a) eliminates the word "functionality" and (b) makes 
the intended meaning clear and unambiguous.

Thanks,

Ran

---

From: Tony Li <[email-masked]>
Date: Wed, 3 Nov 2010 08:00:52 -0700

Hi Ran,

> is a jargon non-word, while "capabilities" is actually in the 

Quick searches of three different dictionaries (webster.com, dictionary.com, Apple's dictionary widget) show that functionality is well defined.

> the intended meaning clear and unambiguous.

I'm happy to try to clarify, but I think that your restriction is onerous.  We have one language to work with here, and it's bad enough that it's an imprecise natural language.  To have to restrict ourselves to the intersection of everyone's vocabulary and not the union is going to leave us writing for Dr. Seuss.

Regards,
Tony

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 3 Nov 2010 11:24:09 -0400

On 03  Nov 2010, at 11:00 , Tony Li wrote:
> Quick searches of three different dictionaries
> (webster.com, dictionary.com, Apple's dictionary widget)
> show that functionality is well defined.

Merriam-Webster (http://www.merriam-webster.com/dictionary/functionality) 
indicates in its definition that "functionality" has
"capabilities" as a synonym.  

Dictionary.com (http://dictionary.reference.com/browse/functionality)
uses "capable" in its 2nd definition for "functional".
In turn, the 1st definition of "functionality" there
references the definition for "functional".

Your note indicated that you did not think "capabilities"
was a synonym for "functionality".  This begs the question 
of what the Design Goals text means when it uses that word,
since you indicated that "capabilities" is not the
intended meaning.

> I'm happy to try to clarify, ...

Thanks very much,

Ran

---

From: Scott Brim <[email-masked]>
Date: Wed, 03 Nov 2010 10:33:54 -0500

ok ok ... Tony, make it "deployed capabilities"?

On 11/03/2010 10:24 EDT, RJ Atkinson wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 4 Nov 2010 09:08:22 +0200

Perhaps we could use the term "functional requirements", which is used
quite often by software architects

>From http://en.wikipedia.org/wiki/Functional_requirement
"Functional requirements may be calculations, technical details, data
manipulation and processing and other specific functionality that
define what a system is supposed to accomplish."

Patrick

---

From: Tony Li <[email-masked]>
Date: Thu, 4 Nov 2010 00:19:51 -0700

> quite often by software architects

Proposed rewording:

	This implies that a solution must continue to support
	  the functions in today's routing subsystem that are actually used.

Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 4 Nov 2010 11:19:01 +0200

>          the functions in today's routing subsystem that are actually used.

+1

Since there has been a discussions between capability and
functionality you might want to consider to replace "capability" in
sections 3.2, 3.3 and 3.4 with "functional requirement". TE,
multi-homing and mobility are real requirements that we aren't allowed
to drop.

Patrick

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 4 Nov 2010 08:24:44 -0400

> 	  the functions in today's routing subsystem that are actually used.

Works well for me.  Crisp, clear, concise.

Thanks very much.

:-)