[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 102: IEEE RFC (WG Last Call Review) Status Recap
This is a recap of status for Issue 102 (raised by Pasi Eronen), which
consists of a number of sub-issues. We believe all issues have
acceptable action recommendations and unless we hear otherwise, the
action noted will be taken.
102-1
Description: Section 3.5 is currently quite difficult to follow since
it mixes L2, IP, tunneling and HTTP redirect rules... It's not always
even clear when some element is just a name for a rule (like "ipno") and
when it's a literal string (like "from"). So some editing work is
needed here. Maybe describing the L2, IP filtering, IP tunneling and
HTTP rules one-by-one(instead of mixing their descriptions) would make
this moreunderstandable. (The IPFilterRule description in RFC3588 isn't
nearly ascomplicated as this, since it doesn't have the L2, tunneling or
HTTP rules.)
Discussion: 9/23 - Paul Congdon suggests that this issue be solved
through description of nas-filter-rule using ABNF. No additional
discussion generated on this sub-issue.
Action: Replace current 'nas-filter-rule' description that uses
non-standard syntax language to use ABNF.
---------------------------------------------------
102-2
Description: Use ABNF to describe 'nas-filter-rule'
Discussion: 9/23 - Paul accepts Posi's suggestion to use ABNF and
questions whether it should replace existing non-standard syntax
description or appended to it. 9/26 - Posi says that regardless of the
way, multiple syntax descriptions should not be in conflict. No
additional discussion.
Action: Replace current 'nas-filter-rule' description that uses
non-standard syntax language to use ABNF.
---------------------------------------------------
102-3
Description: Example of "macaddr/mask": The example should use some
other width than /24 to make it clearer how the counting works. Also,
the example given is an invalid one, since it does not meet the "The MAC
address MUST NOT have bits set beyond the mask" requirement. Suggested
change: use 00-10-A4-23-00-00/32 as the
example.
Discussion: 9/23 - Paul accepts suggestion to change example.
Action: Change example to use 00-10-A4-23-00-00/32
---------------------------------------------------
102-4
Description: Description of "ipno/bits" says "the IP number MUST NOT
have bits set beyond the mask", but the example given, "1.2.3.4/24",
does not follow this. Suggested change: use 192.0.2.0/24 as the example.
Discussion: 9/23 - Paul accepts suggestion to change example. Also
suggests a different addres example. 9/26 - Pasi asserts RFC3330
mandates given address example.
Action: Change example to use 192.0.2.0/24 .
---------------------------------------------------
102-5
Description: Description of tunnel_id: according to RFC 2868, there are
no restrictions on the format of the Tunnel-Assignment-ID. Currently
it's not clear if the NAS-Filter-Rule syntax supports correctly parsing
arbitrary IDs (what happens if the ID
includes spaces, for instance?)
Discussion: 9/23 - Paul suggests use of escaping function, since there
are no restrictions on the format of the string used in
Tunnel-Assignment-ID we MUST provide a way to parse it as a single
element in the entire attribute string. Of course, the
Tunnel-Assignment-ID could itself contain quotes, so we will also need
to describe some escaping function before including them in the rule.
The escaping function would be: For all occurrence of " replace with \"
and for all occurrence of \ replace with \\.
Action: Modify paragraph describing role of 'tunnel-id' parameter for
nas-filter-rule as follows:
"A tunnel id. When the 'tunnel' rule matches, traffic is redirected over
the tunnel with the specified tunnel_id. Traffic can only be redirected
to or from named tunnels that have been established per [RFC2868] and
named using the Tunnel-Assignment-ID attribute described therein.
The tunnel id MUST be encapsulated in double quotes and use the
following escape functions in case the tunnel id itself contains any
quotes:
For all occurances of " replace with \"
For all occurances of \ replace with \\
Example: A tunnel with the name of tunnel "ppp1" would be specified as
"tunnel /"pp1/"" within the rule."
------------------------------------------------------
102-6
Description: Near the end of Section 3.5: The "concise syntax
statements" don't exactly match the definitions earlier. I catched at
least these:
- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"
Discussion: 9/23 - Paul accepts change
Action: Per sub-issue 102-2 the description of nas-filter-rule will be
using ABNF. The need for concise syntax statements no longer exists and
will be removed from document.
------------------------------------------------------
102-7
Description: The document does not seem to describe what HTTP filter
rules are or how they work (HTTP redirect rules are explained, but not
HTTP filter rules).
Discussion: 9/23 - Paul agrees better description necessary. 12/2 -
Mauricio responds with new text proposal to list.
Action: Replace existing HTTP filter description with new text proposed
on 12/2.
------------------------------------------------------
102-8
Description: The document allows an IP tunnel rule with direction "out",
but does not describe what such a rule means (the description seems to
apply only to rules with direction "in")
Discussion: 9/23 - Paul posted Avi's tunneling document 9/26 - Posi
found the document useful 11/18 - Mauricio asked Posi for guidance on
what to add to the document from Avi's document. 11/22 - Posi suggest
inclusion of a portion of Avi's tunneling document as an Appendix to
draft 12/13 - Paul posts to radext email list new proposed text for
appendix A.
Action: Add Paul's suggested text from 12/13 to appendix A.
------------------------------------------------------
102-9
Description: Currently the text says "A flush rule MUST appear before
all other rule types." I first read this to mean that a flush rule must
always be present, but I guess that was not what was
meant. Furthermore, it's not easy to parse the ordering requirements.
Rewrite that paragraph to "Furthermore, if the list contains different
types of rules, they MUST appear in the following order: flush rules,
base encapsulation filter rules, IP tunnel rules, HTTP redirect rules,
IP filter rules, and HTTP filter rules."
Discussion: 9/23 - Paul accepts change.
Action: Replace paragraph in question with Pasi's suggested text.
------------------------------------------------------
102-10
Description: The document should explain why different types of rules
must be given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally
obvious why other orderings need to be forbidden.
Discussion: 9/23 - Paul asserts proposed ordering rules are to maxium
interoperability 9/26 - Pasi accepts
Action: None
------------------------------------------------------
102-11
Description: The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.
Discussion: 9/23 - Paul accepts Pasi's recommendation.
Action: Add several example of NAS filter rules per Pasi's
recommendation.
------------------------------------------------------
102-12
Description: The document should somewhere describe the differences to
Diameter's NAS-Filter-Rule syntax.
Discussion: 9/23 - Paul accepts Pasi's recommendation
Action: Add paragraph to description section detailing differences to
Diameter's NAS-Filter-Rule
------------------------------------------------------
102-13
Description: If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte attribute
length limit, then boundaries between individual rules
are lost. Parsing may be ambiguous.
Discussion: 9/23 - Paul asserts that this should not be a problem. No
action proposed. 9/26 - Pasi states that dependancies exist on grammer
to be parsable in non-ambigous manner. Current grammer seems to have no
opportunities for ambiguity. 9/26 - Paul agrees it would be nice to have
a rule delimeter 9/26 - Pasi agrees with Paul. Pasi goes on to suggest
usage of a rule delimeter field.
Action: Add rule delimeter to filter syntax.
--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557
916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez@hp.com
--------------------------------------------
--
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/>