Jouni wrote....
> Issue 192: Comments
> Submitter name: Jouni Korhonen
> Submitter email address: jouni.korhonen@teliasonera.com Date
> first submitted: April 26, 2006
> Reference: http://ops.ietf.org/lists/radiusext/2006/msg00480.html
> Document: Filter-00
> Comment type: Technical
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> I had a quick look at this draft. A few initial comments:
>
> o Introduction talks about 'home realm' and in the same
> sentence also about 'local operator'. Maybe changing
> home realm to home operator would be better?
I'm open to this suggestion. It does seem more succinct when the home
operator term is used.
>
> o Introduction also discusses VLANs. I think that text
> there does not really belong to this draft anymore.
Sounds appropriate. We'll back off the usage of VLANs as a driving use case
and focus on what specifically drives the need for these attributes.
>
> o terminology section lists Authenticator, Authentication
> Server and Supplicant even if those are not used in the
> text outside the terminology section. Imho a reference
> to 802.1X should be enough
>
I remember adding this terms into the terminology section after group
discussion. I remember people wanting additional detail around this and
having only a reference to 802.1X did not seem like enough. I'll push back
and say that unless you really think having these terms are distraction,
then we should just leave them in.
> o hot-lining is also only mentioned in the terminology
> section. Should there be some more text in the draft
> itself about hot-lining e.g. in form of motivation for
> this draft? Actually I would like to see a general
> short motivation section somewhere under section 1
Hmmm, previous version talked about hotlining and people started to feel
that it was getting to be a distraction in the introduction. Elaboration on
hotlining was cut down to what it is now. Why do you feel we need to add
more motivation based on hot-lining?
> o what is the purpose of the rule-delim in the
> NAS-Traffic-Rule ABNF? As far as I interpreted the
> ABNF there can be only one rule per attribute anyway?
> I could be wrong ;)
The first version of the syntax had no rule delimiter and people commented
that having a delimiter would eliminate any possibility for ambiguity of
rule end.
>
> o in the NAS-Traffic-Rule why there could not be
> - ip-proto = ["!"] d8
> - tcp-ports = ["!"] tcp-port *("," tcp-port)
>
> That would ease blocking of specific ports and
> protocols. E.g. in case of trying to block some
> virus/worm generated traffic, while allowing
> everything else..
There no strong reason anymore why this couldn't be done. It used to be an
argument of remaining true to the L3-L4 capabilities specified by Diameter's
IPFilterRule to facilitate translation. However, given that we're going
down the path of creating a Diameter AVP for NAS-Traffic-Rule, we probably
no longer need to constrain ourselves to the limitations of the IPFilterRule
syntax.
>
> o tcp-port name might be a bit misleading as ports are
> also used for other protocols. Maybe just using
> ports or similar?
How about 'layer4-port' or 'l4-port'?
>
> o What's the intended use for the L2 filtering? I'd
> like to see some real use case described here
BPDU filtering is one real use case.
>
> o section 3.1 Acct-NAS-Traffic-Rule attribute definition
> - the length should probably be >= 11
> - The 'String' should probably be 'Counter'
> - the description for 'Text' is missing
Ok.
>
> o Security considerations mention VLAN-related attributes
> several times although those are now in a separate
> document.
Ok. Will update.
>
> Some nits:
>
> o section 2
> s/one new RADIUS authentication attributes/...attribute
Ok.
MS
Attachment:
smime.p7s
Description: S/MIME cryptographic signature