Subject: [ipcdn] : proposed wording

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 10 Jan 2003 08:46:21 -0700

Dummy comment, 

Would be nice to have a precise enumeration  reference in the
DESCRIPTION clauses, not sure what is the appropiate one, ie, in RFC
2573 a case shows in the same DESCRIPTION clause (rowstatus)
createAndGo(4) and 'notReady'  
Would prefer an unique one, 'notReady'  or notReady(3) to be consistent

In IPCDN mibs there is more flavors:

i.e
docsSubMgtPktFilterAction OBJECT-TYPE 

     SYNTAX      INTEGER
                    {
                    accept(1),
                    drop(2)
                    }
.....

     DESCRIPTION
         "The action to take upon this filter matching.  Accept means
     to end filter matching and to accept the packet for further
     processing. Drop means to drop the packet."

Would be more clean (
         "The action to take upon this filter matching.  accept(1) means
     to end filter matching and to accept the packet for further
     processing. drop(2) means to drop the packet."

Or 'accept' 'drop'

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Friday, January 10, 2003 5:39 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [ipcdn] RE: docsis subscriber management: proposed wording for
filter action

I am OK with that

Thanks,
Bert 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: donderdag 9 januari 2003 16:57
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: docsis subscriber management: proposed wording for filter 
> action
> 
> 
> Vedvyas Shanbhogue wrote:
> 
> 1.There should be an object describing the default
>    action to be taken when none of the filters in a
>    filter group match the packet. The default action
>    could be configurable as 'accept' or 'drop'
> 
> Bert Wijnen had also expressed concern about the original description 
> clause of docsSubMgtPktFilterAction, which was:
> 
> "The action to take upon this filter matching.  Accept means
> to accept the
> packet for further processing.  Drop means to drop the packet."
> 
> to wit: what does further processing mean? In particular,
> what does it mean
> in terms of continuing with or exiting this table?
> 
> I have been reluctant to clarify "accepted for further
> processing" beyond
> what is necessary for describing the mechanics of this table. 
> Terms like
> "forwarding" violate the separation of layers needed for a clean
> definition, and in practice have always provoked confusion.
> 
> The following is proposed new wording for
> docsSubMgtPktFilterTable, as well
> as the -07 text from docsSubMgtPktFilterAction. Are the mechanics of
> pktFilterAction now sufficiently clear?
> 
> docsSubMgtPktFilterTable OBJECT-TYPE
>     SYNTAX      SEQUENCE OF DocsSubMgtPktFilterEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "A table of filter or classifier criteria. Classifiers are
>     assigned by group to the individual CMs.  That assignment is made
>     via the configuration objects sent upstream from the CM to the
>     CMTS during registration. Each filter in the group is applied
>     in index order to each packet. If the filter matches, then the
>     indicated action is taken. If no filter matches then the packet
>     is accepted for further processing."
>     ::= { docsSubMgtObjects 6 }
> 
> ...
> 
> docsSubMgtPktFilterAction OBJECT-TYPE
>     SYNTAX      INTEGER
>                    {
>                    accept(1),
>                    drop(2)
>                    }
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "The action to take upon this filter matching.  Accept means
>     to end filter matching and to accept the packet for further
>     processing. Drop means to drop the packet."
>     DEFVAL { accept }
>     ::= { docsSubMgtPktFilterEntry 11 }
> 
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn