Filter-rules-01 & Issue 192

[<jouni.korhonen@teliasonera.com>]

Hi Mauricio,

Sorry for a late reply on this issue ;-) I checked the -01
version and see the responses below (marked with [JiK]).

Cheers,
	Jouni


[Mauricio Sanchez]
>  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.

[JiK] -01 looks better now. I would still change change the
       'local operator' to 'local visited operator'.

>  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. 

[JiK] Ok.

>  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. 

[JiK] Right.. I don't really mind having these terms in the terminology
      but then you better not state they are used in the document (at
      least authenticator, authentication server, supplicant..)

>  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?

[JiK] There seems to be a bit more in appendix & example scenario.
      I'm OK with the current text.

>  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. 

[JiK] So if there can be only one rule per attribute I still don't see a
      need for rule-delim. It does not add any value imho.

>  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. 

[JiK] I'm OK not having the chance I proposed earlier.
      
>  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'?

[JiK] OK.

>  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. 

[JiK] Right. Probably a sentence or two saying L2 filtering is needed 
      e.g. for BPDU filtering in the intro or some appendix examples
      would be good.. 

>  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.

[JiK] OK.

>  o Security considerations mention VLAN-related attributes
>    several times although those are now in a separate
>    document.

Ok. Will update.

[JiK] OK.

> 
> Some nits:
> 
>  o section 2
>    s/one new RADIUS authentication attributes/...attribute

Ok.

[JiK] OK. 

--
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/>