RE: review of draft-ietf-radext-ieee802-01.txt

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

Jari commented...

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Jari Arkko
> Sent: Friday, January 27, 2006 4:15 AM
> To: radiusext@ops.ietf.org
> Subject: review of draft-ietf-radext-ieee802-01.txt
> 
> I reviewed this draft. Overall, this draft is in good shape, 
> but some minor mistakes and question marks are noted below. 
> In addition, the document is silent on the use of these 
> attributes in Diameter, which needs further work.
> 
> The title should probably mention redirection, too.

Wouldn't this make the title too long?  Besides, redirection is action
taken by the filtering attribute. There is no standalone redirection
attribute.

> Is this for informational or standards track? In some sense 
> the latter would make more sense, as this is an important 
> functionality that many people will need.

Standards track. 


> 
> And please run ABNF checker from tools.ietf.org:

Which checker did you use?  I ran it through and it didn't pick up on
these errors.

> >   5.  IANA Considerations
> >
> Do you want to say something about allocation policy on new 
> enumerated values?

What do you think should be said?

> >   2.5.  NAS-Filter-Rule
> >
> This is quite complicated. Do we have implementation 
> experience that this works and is well defined?

What sort of proof points are you looking for?

> 
> >      The security mechanisms in [RFC2865] and [RFC3576] are 
> primarily 
> >      concerned with an outside attacker who modifies messages in 
> >      transit or inserts new messages. They do not prevent 
> an authorized 
> >      RADIUS server or proxy from inserting attributes with 
> a malicious 
> >      purpose in message it sends. 
> >  
> >
> Or deleting, for that matter...

Fair enough, easy enough to add. 

<...Removed DIAMETER discussion - being discussed in different thread>

> Editorial:
> 
> >      In this document when we refer to Blocking of IP 
> traffic we mean 
> >      Filtering of IP traffic.
> >
> Not sure if Capitalization is Needed.

Ok. Capitalization not necessary. 

> 
> >       0                   1                   2                   3 
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
> 7 8 9 0 1 
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >      |     Type      |    Length     |  Tag Option   |   
> Pad (12-bit)          
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >        Pad   |    VLANID (12-bit)    |  
> >      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >      Type
> >    
> >         TBD
> >    
> >      Length
> >    
> >         6    
> >    
> >      Integer
> >    
> >
> The picture and text do not match. Show two pictures:
> one with "Integer" and then another one with the detailed 
> substructure.

Ok.

> 
> >         "l2:"       Prefix on any base encapsulation rule 
> to designate 
> >                     as rule as such. 
> >  
> >
> "a rule as such"?

Would the following be clearer?

'Prefix to designate rule as a base encapsulation rule.'

> 
> > TODO / TBD
> 
> Two different placeholders are used. Just use TBD, or better 
> yet, TBD-by-IANA so that they can better search for these.

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