RE: Issue 129: Editorial nits

["Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com>]

Paul stated some editorial nits a while back... 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Wednesday, September 07, 2005 11:40 PM
> To: radiusext@ops.ietf.org
> Subject: Issue 129: Editorial nits
> 
> Issue 129:  Editorial NITs
> 1. Pg 3, end of second paragraph. Seems like a reference to 
> RFC3580 would be appropriate

[ms] Ok. 

> 
> 2. Pg 3, middle of sixth paragraph. We aren't providing the 'full set'
> of VLAN functionality either.  Suggest replacing "...the full 
> set of VLAN functionality" with "...a more complete set of 
> VLAN functionality as defined by IEEE 802.1Q-2003"

[ms] Ok. 

>  
> 3. Pg 3, end of sixth paragraph.  Reference to IEEE-802.1Q 
> should probably be the Bridge-MIB or RFC 2674

[ms] ok. 

> 
> 4. Pg 4. The following terms aren't really used and should be 
> removed; Access Point (AP), Association, Port Access Entity 
> (PAE), Stations (STA).

[ms] ok. 

> 
> 5. Pg 10, 3.4 User-Priority-Table. The reference to 802.1D 
> should probably be 802.1D-2004.

[ms] Propose to change 802.1D reference to [IEEE8021D], which is already
used in other sections of document. 

> 
> 6. Pg 10, 3.4 User-Priority-Table, 1st paragraph of String. 
> There are 8 regenerated priorities, not 7.

[ms] ok. 

> 
> 7. Pg 12, First item 2). The way this item is worded it makes 
> it sound like you must have a flush rule present and as the 
> first item.  Suggest rewording as follows: Base encapsulation 
> filter rules MUST appear after a flush rule (if present) and 
> before IP tunnel,...

[ms] I102 resolution already changed this text in substantial fashion.
See resolution for I102. 

> 
> 8. Pg 12, first paragraph after list. If you only wanted to 
> filter specific traffic, but allow other stuff you would want 
> the list to end with an 'accept all' rule.  The behavior we 
> have defined is more of a firewall type behavior rather than 
> a router behavior.  We should document a syntax for the 
> 'accept all' rule and make a note to the implementer of how 
> to do this.  Suggest adding a note that describes how to 
> terminate the list with a rule that allows all traffic.  I 
> believe the rule is: permit both ip from any to any.  We may 
> need an L2 rule as well.

[ms] Propose adding new rule statement that can be added to a rule list
that matches all traffic.  Propose the following rule statement 
"permit inout any from any to any"  

Description to be added that talks to the use case for this, as follows:

"Special rule that matches against all traffic. This allows the implicit
deny at the end of a filter list to be overridden."
 
> 9. Pg 12, last paragraph on Filter-ID and NAS-Filter-Rule.  
> The paragraph is clumsy.  Suggest replacing the start of the 
> second sentence with, "These attributes are not intended to 
> be used..."

[ms] ok. 

> 
> 10. Pg 15, Note: at top of page. Seems like a missing word or 
> something in the second sentence.  Suggest, "Also, [ports] 
> optional argument is not valid for ..."

[ms] nas-filter rule description changed substantially due to I102.
This specific text no longer appears. 

> 
> 11. Pg 17, Editorial note in Text section.  I think you can 
> just delete this now.  Isn't the text about fragmenting these below?

[ms] ok. 

> 
> 12. Pg 23, end of page. RFC 2866 and RFC 2867 are normative, 
> but never referenced.  Perhaps we should be referencing them 
> somewhere or move them to informative references.  Also, 
> IEEE802.11i reference should be IEEE80211i (all one word - no dot).

[ms] ok.

> 
> 13. Pg 28, Acknowledgments. Since all the wireless stuff has 
> been removed, we can remove Dorothy Stanley of Agere from 
> this list of names.

[ms] ok.


Cheers,
MS

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>