Subject: [Nea] REQ: sections <= 2

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 26 Feb 2007 02:23:36 -0000

My comments/questions on sections less than or equal to two:

General NITs
1.There seem to be some non-standard control characters present in the
document. For example, in section 5.3 the usage of "nouns" in the second
sentence shows up incorrectly.

2.Some sections of the document refer to "vendor-defined" attributes while
other refer to "vendor-specific" attributes.  Isn't the term
"vendor-specific" more widely used in other IETF efforts versus the
"vendor-defined" term?  If so, I suggest we change all references of
"vendor-defined" to "vendor-specific."  

3.Why are "core" attributes not called "standard" attributes?  After all,
they're just the attributes that will be standardized by NEA WG.  To me
calling them "standard" attributes is a more intuitive label than "core."

4.Have IETF writing styles changed such that all terms defined in the
terminology section need to be capitalized?  If so, then there are instances
where this guideline are not followed (e.g. the term 'reference model' is
not capitalized in abstract section vs. rest of document).  IMHO, extreme
usage of capitalized terms, as is the case with this document, detracts from
the readability.

Section 2 specific comments
1. How exactly do policy attributes differ from posture attributes?  It's
unclear to me because of the claim in the definition of policy attributes
that states that policy attributes can be used to establish compliancy
without divulging posture information.  Isn't the exchange of policy and
compliance attributes in fact a form of posture information exchange.  

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 26 Feb 2007 19:10:14 -0800

Comments below... 

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, February 25, 2007 6:24 PM
> To: [email-masked]
> Subject: [Nea] REQ: sections <= 2
> 
> 1.There seem to be some non-standard control characters 
> present in the document. For example, in section 5.3 the 
> usage of "nouns" in the second sentence shows up incorrectly.

I see those in the browser as well but not in vi nor word ;).

> 
> 2.Some sections of the document refer to "vendor-defined" 
> attributes while other refer to "vendor-specific" attributes. 
>  Isn't the term "vendor-specific" more widely used in other 
> IETF efforts versus the "vendor-defined" term?  If so, I 
> suggest we change all references of "vendor-defined" to 
> "vendor-specific."  

Agreed this should be consistent.

> 
> 3.Why are "core" attributes not called "standard" attributes? 
>  After all, they're just the attributes that will be 
> standarFrom [email-masked] Mon Feb 26 22:11:09 2007
Content-class: urn:content-classes:message
Subject: RE: [Nea] REQ: sections <= 2
Date: Mon, 26 Feb 2007 19:10:14 -0800
From: "Paul Sangster" <[email-masked]>
To: "Sanchez, Mauricio \(ProCurve\)" <[email-masked]>, <[email-masked]>
Cc: 

Comments below... 

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, February 25, 2007 6:24 PM
> To: [email-masked]
> Subject: [Nea] REQ: sections <= 2
> 
> 1.There seem to be some non-standard control characters 
> present in the document. For example, in section 5.3 the 
> usage of "nouns" in the second sentence shows up incorrectly.

I see those in the browser as well but not in vi nor word ;).

> 
> 2.Some sections of the document refer to "vendor-defined" 
> attributes while other refer to "vendor-specific" attributes. 
>  Isn't the term "vendor-specific" more widely used in other 
> IETF efforts versus the "vendor-defined" term?  If so, I 
> suggest we change all references of "vendor-defined" to 
> "vendor-specific."  

Agreed this should be consistent.

> 
> 3.Why are "core" attributes not called "standard" attributes? 
>  After all, they're just the attributes that will be 
> standardized by NEA WG.  To me calling them "standard" 
> attributes is a more intuitive label than "core."

Agreed (and this matches the named used in the charter.)

> 
> 4.Have IETF writing styles changed such that all terms 
> defined in the terminology section need to be capitalized?  
> If so, then there are instances where this guideline are not 
> followed (e.g. the term 'reference model' is not capitalized 
> in abstract section vs. rest of document).  IMHO, extreme 
> usage of capitalized terms, as is the case with this 
> document, detracts from the readability.

We wanted to call out when we were using a defined term vs. the generic
equivalent (roughly equivalent of SHOULD vs should.)  Since we use a few
commonly used words (e.g. Message, Component ...) with a special meaning
we thought it was important to be clear what was intended.  For sections
that are prior to the terminology section we didn't wish to use defined
terms (since they weren't defined yet) and instead stick with generally
known wordings.  Another WG member already pointed out that we missed a
few terms that were used in the abstract (which is fixed in -01.)

If others agree that this hurts readibility we could make them lower
case as well and hope the reader understands this is a reserved term for
this spec.

> 1. How exactly do policy attributes differ from posture 
> attributes?  It's unclear to me because of the claim in the

Policy Attributes describe or reference policies that the Endpoint must
meet to be considered compliant ("must have <vendor> firewall running at
least version 1.2.3").  These are sent by the NEA Server (will add text
to mention this.)

Posture Attributes includes Posture information about a requested
Component (Firewall installed, version 1.5, Firewall running, ...)  The
Posture Validator compares this information to its policy to determine
compliance.  These are sent by the NEA Client.

> definition of policy attributes that states that policy 
> attributes can be used to establish compliancy without 
> divulging posture information.  Isn't the exchange of policy 
> and compliance attributes in fact a form of posture 
> information exchange. 

I presume you mean Policy and Compliance Claim Attributes.  In some
sense you could argue this but we felt it was important to be more clear
about the different types of attributes as they have differing security,
privacy and operational properties.  We found these names very helpful
when writing the spec and hope that after a read of the draft they
aren't confusing.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Feb 2007 11:38:03 +0100

Paul Sangster wrote:
> we thought it was important to be clear what was intended.

  My suggestion is to avoid re-defining common words.  It makes it that
much harder to understand the document.  (e.g. "That depends on what the
meaning of the word 'is' is.")

> compliance.  These are sent by the NEA Client.

  Can we just please use the term "attributes"?  It's already understood
that attributes are sent by the client for one purpose, and the server
for another.  Other protocols (DHCP, RADIUS, etc.) do not over-specify
terms like this... they just use "attributes".

  The sheer volume of Capitalized Terms in the document makes me think
of the quote "Entities should not be multiplied unnecessarily".

> when writing the spec and hope that after a read of the draft they

  I'm confused as heck by them, and I've been doing posture assessment
and policy application in RADIUS & DHCP for a decade.  I don't
understand why NEA is so much more complicated than other posture
assessment and policy application protocols.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

---

From: "todd glassey" <[email-masked]>
Date: Tue, 27 Feb 2007 06:08:02 -0800

As long as Terms of Art are noted as that, there shouldn't be an issue.

Todd