RE: [Nea] REQ: Abstract and Section 1

["Paul Sangster" <Paul_Sangster at symantec.com>]

Thanks for the many sets of comments organized by section.

I presume the bulk of this thread is about the introduction.  We tried
to keep the use of terminology to a minimum but are happy to reduce it
even further (some of the use of capitalization is a bug.)  Maybe you
could help us spot the words whose more generic meeting do not fit the
text (without clearer definition as per the terminology section.)

Comments below...

> -----Original Message-----
> From: Alan DeKok [mailto:aland at deployingradius.com] 
> Sent: Wednesday, January 10, 2007 8:12 PM
> To: nea at ietf.org
> Subject: [Nea] REQ: Abstract and Section 1
> 
>   The abstract and introduction are long, and use terminology 
> defined later in section 2.  It seems that an assumption of

Upon review of the abstract, we used "posture" in several places would
the abstract be clear enough if we used a different word or phrase (e.g.
"system configuration")? 

In the introduction:
    P3 contains "Posture" and "Validator" which could be replaced
    P4 contains "Endpoint" and "Assessment" which should be lower case.
       - hopefully these words are generic enough for use in the
         intro but we could select alternatives if desired

Are their other words whose generic definition are insufficient to use
so early in the document?  At a minimum the P3 and P4 words should not
be capitalized (thus referring to a term not yet defined.)
 
> the document is that people are already familiar with the 
> models and terminology of NAP, NAC, TNC, etc.  While that may 
> be true for the draft authors, it would be best to have the 
> introduction describe the space using more neutral terminology.

Agreed we want the intro to use neutral terminology.  The only word I
see that is commonly associated with NAP, NAC or TNC is "Posture" and
possibly "admission."  These word seemed useful as its traditional
meaning is in line with our usage in the document but possibly not
before its been defined as a NEA term (which might differ from NAC.)

As for the models of the other architectures, I would hope the NEA
Requirements spec could create enough context that it could stand alone
and just reference prior work (like any paper) that might be relevant
for background and to show the discussion is based on understood
approaches and not starting from scratch.  The text in earlier
paragraphs (particularly 3,4) tried to describe in neutral way the
general model common to those existing technologies.  The word Validator
needs to be replaced or augmented with some text though.

> 
>   Parts of the introduction are lifted directly from the 
> charter.  I'm not sure that's necessary.

The goal was creating some readible text so lifting text from other
documents was likely because it was well written.  If the text is a
problem we could fix it, I agree we don't need to repeat the charter.

> 
>   Alan DeKok.
> --
>   http://deployingradius.com       - The web site of the book
>   http://deployingradius.com/blog/ - The blog
> 
> _______________________________________________
> Nea mailing list
> Nea at ietf.org
> https://www1.ietf.org/mailman/listinfo/nea
> 

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea