Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

From: "Kumar, Satish" <[email-masked]>
Date: Fri, 1 Aug 2003 20:58:29 +0530

Gordon,
Your comments from #1 to #11 on Signaling MIB are acceptable. 
I am in favour to Obsolete the MIBS marked in comment #12. 
 
Thanks,
Satish Kumar
Texas Instruments

-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email-masked]]
Sent: Monday, July 28, 2003 5:52 PM
To: [email-masked]'
Subject: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

Rick, 

Thanks for your review of the signaling MIB recommendations and for
providing additional suggestions.

For items 1-5 and 7,8, and 10 there is substantial agreement, and I have
made the changes as indicated in the open issues list (as posted on the
IPCDN web site and included in your document), however, there is one minor
exception  item 8. It turns out that sixteenthousand is more commonly used
than twelvethousand. Consequently, the description and default are
recommended to be sixteenthousand not twelvethousand. 

For item 9, Motorola agrees with the default change recommended. 

For item 11, Motorola agrees with the recommendation to obsolete these
objects. These objects are product hardware design issues. 

For item 6, Motorola, after further review determined that there is already
an object for setting the level for dtmf or any other tone
(pktcSigDevToneDbLevel), which can vary by geographic location.
Consequently, the only change recommended for item 6 then is the addition of
3 user defined tones.

For item 12, Motorola does not agree with obsoleting these objects. The dial
pulse objects vary by geographic location (e.g., NA, Europe, Japan, etc),
and need to be retained in order to be adjusted as necessary by the
operator.

Gordon Beacham

Digital Core Gateways, BCS

Motorola, Inc.

858-404-2335

[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 25, 2003 2:08 PM
To: Wim De Ketelaere
Cc: Gordon Beacham; [email-masked]; [email-masked]
Subject: Re: Fw: Publication of PacketCable IETF MIBs - SIB draft 01

Wim and Gorden, 

I apologize for the length of time it has taken me to get this response back
to you.     However, we wanted to make sure that we had thoroughly reviewed
and considered each of Gorden's suggestions.  Please distribute our comments
to your list as appropriate. 

I would like to say that Gorden has done an excellent job of scoping out
several suggested changes.  The attached document from ARRIS contains any
agreements with his recommendations, along with a couple of additional
comments.  ARRIS would be very interested with discussing our comments with
you, and others on your distribution list at your convenience. 

Thank you both for your efforts in working to clean up this MIB's contents.
With the joint cooperation of tComLabs and the MTA vendors, I feel confident
we can all move towards a successful certification wave in ECW13. 

Regards, 
Rick Morris 
ARRIS, SrMgr - Engineering, Certification and Standards 
+001 770 622 8619 

	"Wim De Ketelaere" <[email-masked]> 

07/03/2003 01:53 PM 

        To:        <[email-masked]> 
        cc:        <[email-masked]> 
        Subject:        Fw: Publication of PacketCable IETF MIBs - SIB draft
01	

Hi Rick,

Here's the document !

Thanks,
 Best regards,
   Wim

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 1 Aug 2003 18:06:44 +0200

I did a quick check/scan.

I also see references to RTP... should the AVT WG be 
informed about this work, so they can check?

1. Long lines can be handled by RFC-Editor, 
   non-US-ASCII characters are more problemsome, cause
   they appear in the MIB MOdule

   $ /bin/checkpage.awk < drafts/draft-ietf-ipcdn-pktc-signaling-01.txt
   Long line at 25 with 73 chars, only spaces extra
   Long line at 92 with 73 chars, only spaces extra
   Long line at 1059 with 73 chars, only spaces extra
   Long line at 1086 with 73 chars, only spaces extra
   Bad chars at 1947
   Long line at 2172 with 73 chars, only spaces extra
   Long line at 2365 with 73 chars, only spaces extra
   Long line at 2523 with 73 chars, only spaces extra
   Long line at 2533 with 73 chars, only spaces extra
   Bad chars at 2927
   Bad chars at 2930
   -: 3 lines containing non-US-ASCII characters
   -: 8 lines longer than 72 characters, max 73

2. smilint discovered issues:

   C:\smi\mibs\ietf>smilint -m -s -l 6 -i namelength-32 ./PKTC-IETF-SIG-MIB
   ./PKTC-IETF-SIG-MIB:1115: [5] {index-element-accessible} index element
     `pktcSigDevToneType' of row `pktcSigDevToneEntry' should be
      not-accessible in SMIv2 MIB
   ./PKTC-IETF-SIG-MIB:2069: [6] {} implicit node definition
   ./PKTC-IETF-SIG-MIB:1883: [5] {inetaddress-inetaddresstype} `InetAddress'
     object should have an accompanied preceding `InetAdressType' object

3. Did you consider to change:
     pktcSigNotification  OBJECT IDENTIFIER ::= { pktcSigMib 2 0 }
   Into
     pktcSigNotification  OBJECT IDENTIFIER ::= { pktcSigMib 0 }
   Makes any notifications (if ever defined) one subid shorter.
   If there are no notifications, might also just delete that line
   (and the talk about notifications in sect 3.1 and 3.3
   If you need to define NOTIFICATIONs in the future, you need
   to open up the doc anyway.

4. Might want to expand MTA in the document title

5. Why is there a "reserved" value in the following?
   Is it maybe because ncs(3) needs to be 3 cause that is a number/value
   used/assigned in some other spec, and so you create a reserved(2) in
   order to have sequential enumeration?

     PktcSigType     ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
           " This object lists the various types of signaling that may
             be supported.
             ncs - Network call signaling is a derivation of MGCP
                   (Media Gateway Control Protocol) defined for
                   PacketCable and IPCablecom MTAs. "
        SYNTAX INTEGER {
                      other(1),
                      reserved(2), -- reserved for future use
                      ncs(3)

6. In 
   pktcSigDevCodecEntry  OBJECT-TYPE
       SYNTAX      PktcSigDevCodecEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           " List of supported codec types for the MTA."
    It seems this an "Entry" is not a "list of" but just a
    single codec type, no? So maybe better
       DESCRIPTION
           "Each entry represents a supported codec type for the MTA."

    Similar questions for other DESCRIPTION clauses in other xxxEntry
    definitions

7.    pktcSigDevCodecIndex  OBJECT-TYPE
       SYNTAX      Unsigned32 (1..255)
    Will there be max 255 for now and forever? If there is any change
    that there could be more, why not allow for a larger range, like
    32K or 64K or so?

8. pktcSigDevCodecMax ?? 
   Maybe a better name: pktcSigDevCodecMaxSimSessions ?

9. Shows my ignorance in this field:
   pktcSigDevEchoCancellation is that a "device" capability or a
   "codec" capability? If the latter then maybe it should go
   in the table?

10. pktcSigServiceClassNameUS and  pktcSigServiceClassNameDS
    Kind of strange to see a UTF-8 based SYNTAX being used while
    the DESCRIPTION says that the content MUST be ASCII printable
    characters. Why is that needed? if it is indeed needed, you
    may add the explanation. And if that is a valid argument,
    and if we do not expect internationalization in the future,
    then we might be better of to use DisplayString TC instead.

11. pktcSigServiceClassNameMask
    I do not understand how the value of the Integer32 contains
    a mask and which "mask" bits would control what. Is that
    just me?

12. pktcSigPulseSignalTable
    Mmm... so a NMS cannot create entries, right?
    But it can SET (write) some values.
    Pls specify the persistence of such written values. Will they
    survive a reboot or agent restart? Either make it fixed
    for the whoile table (then you put it in Table or Entry 
    DESCRIPTION clause, or make it variable per entry by using
    a StorageType object in each row

13. same for pktcSigDevRingCadenceTable and pktcSigDevToneTable

14. pktcSigEndPntConfigTable is a read-create table.
    That means we need to see RowStatus object to control such
    creation and deletion. 
    Also need to specify persistence behaviour of this table
    as for other tables above.

15. Same for pktcSigEndPntConfigTable

16. pktcNcsEndPntConfigCallAgentId contains in DESCRIPTION clause
    an example:
             (e.g.,: [email-masked]).
    According to ID-NITs, that should be something aka
             (e.g.,: [email-masked]).
Thanks,
Bert 
-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: vrijdag 1 augustus 2003 2:53
To: [email-masked]; [email-masked]; Wim De Ketelaere; [email-masked]
Cc: [email-masked]; [email-masked]; Satish Kumar at Texas Instruments; Sumanth Channabasappa; Rick Vetter
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

All,

The co-authors of the ipcdn IPCablecom/PacketCable sig mib intend to address all the pending comments including those received during WGLC by August 8 and release an updated draft by August 15.

Gordon Beacham, Satish Kumar and a couple of us from the packetcable oss team spent some time today to try to review the comments and address them. Here are the notes I took to document the consensus we had.
Please review & comment by August 5, 2003.
Jean-Francois.

--- Participants
Gordon Beacham - Motorola
Robert Lund - Terayon
Satish Kumar - TI
Paul Duffy - Cisco
Eugene Nechamkin - Broadcom
Rick Vetter - Lemur Networks
Jean-Francois Mule - CableLabs

--- Notes for ipcdn distribution
ipcdn documents we reviewed:
 - Signaling MIB
  ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-01.txt

+ Comments on draft-ietf-ipcdn-pktc-signaling-01.txt
We have 3 sets of comments on the ipcdn sig MIB from the WGLC review:
 1.a) List of outstanding issues provided by Gordon
 1.b) Proposal to consider PacketCable Engineering Change Request
      mibsig-o-03004-v3 - additional input
 1.c) Comments from Satish logged in these meeting notes
-----------------------------------
 1.a) Review of outstanding issues provided by Gordon
http://www.ipcdn.org/meetings/sigmib-01-outstanding-issues.html
Note that Arris also provided input on these at:
http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00754.html

- Issue 1 - pktcSigDevCodecTable 
Motorola (Gordon) and Arris' proposal was to delete this object
(i.e. delete it in the IETF version of the mib). We (Paul, Rik,
Eugene, Jean-Francois) had consensus that having knowledge of the MTA
supported codecs can actually serve to the operators.
 Consensus: we must not delete the codec table object.
We discussed pktcSigDevCodecTable along with 1.b) mibsig-o-03004-v3
which is a proposal to enhance the table by adding several objects.
Jean-Francois expressed various comments on the motivations of this
ECO - I'll start a separate thread. Rick & Eugene also expressed why
they believe it is needed. Overall, there is no consensus on this ECO
and, it needs to be discussed on the list.
More opinions must be expressed on the mailing list. See separate
thread to follow.

AI:
  - Rick to send proposed ECO to ipcdn list for full disclosure
  - team to review ECO mibsig-o-03004-v3 and make comments.

- Issue 2 - PktcSigDevConnectionMode
For review by COB 8/5/2003.
Consensus : delete object.

- Issue 3 - pktcSigPowerRingFrequency
For review by COB 8/5/2003.
No consensus , Eugene & Paul to send comments on this one.

- Issue 4 - PktcSigPCMCoding
For review by COB 8/5/2003.
Consensus : delete object.

- Issue 5 - pktcNcsEndPntConfigNomJitterBufferSize  
            pktcNcsEndPntConfigMaxJitterBufferSize
For review by COB 8/5/2003.
Consensus : delete objects.

- Issue 6 - PktcSigDevToneType
For review by COB 8/5/2003.
Consensus :
  1/ keep DTMF 0-15 as read-write (Gordon agrees)
  2/ add 3 user-defined tones

- Issue 7 - pktcSigPulseSignalDuration
For review by COB 8/5/2003.
Consensus :
replace
<   pktcSigPulseSignalDuration    OBJECT-TYPE  
<       SYNTAX       Unsigned32 (1..5000)  
by
>   pktcSigPulseSignalDuration    OBJECT-TYPE  
>       SYNTAX       Unsigned32 (50..5000)  

And replace
< pktcSigPulseSignalPauseDuration    OBJECT-TYPE  
<       SYNTAX       Unsigned32 (1..5000)  
by
> pktcSigPulseSignalPauseDuration    OBJECT-TYPE  
>       SYNTAX       Unsigned32 (50..5000)  

- Issue 8 - pktcSigPulseSignalFrequency
For review by COB 8/5/2003.
Consensus :
replace
<   pktcSigPulseSignalFrequency    OBJECT-TYPE  
<       SYNTAX       INTEGER {  
<                    zero (1),  
<                    fifty(2),  
<                    twelvethousand(3),  
<                    sixteenthousand(4) 
<       }             
with
>   pktcSigPulseSignalFrequency    OBJECT-TYPE  
>       SYNTAX       INTEGER {  
>                    zero (1),  
>                    twelvethousand(2),  
>                    sixteenthousand(3) 
>       }
and make DEFVAL sixteenthousand(3)

- Issue 9 - pktcSigPulseSignalDbLevel
For review by COB 8/5/2003.
Consensus :
replace
<   pktcSigPulseSignalDbLevel    OBJECT-TYPE  
<       SYNTAX       TenthdBm (-250..150)  
with
>  pktcSigPulseSignalDbLevel    OBJECT-TYPE  
>      SYNTAX       TenthdBm (-200..30)  

- Issue 10  
For review by COB 8/5/2003.
Consensus :
  delete pktcNcsEndPntConfigTxGain, pktcNcsEndPntConfigRxGain

- Issue 11
For review by COB 8/5/2003.
Consensus :
  delete pktcNcsEndPntConfigOffHookDebounce, pktcNcsEndPntConfigOnHookDebounce

- Issue 12
For review by COB 8/5/2003.
Consensus :
For the objects below, redefine the range to be based on real-world
mins
 pktcNcsEndPntConfigPulseDialInterdigitTime,
 pktcNcsEndPntConfigPulseDialMinMakeTime,
 pktcNcsEndPntConfigPulseDialMaxMakeTime,
 pktcNcsEndPntConfigPulseDialMinBreakTime,
 pktcNcsEndPntConfigPulseDialMaxBreakTime,
 pktcNcsEndPntConfigMinHookFlash,
 pktcNcsEndPntConfigMaxHookFlash.

For e.g.,
replace
< pktcNcsEndPntConfigPulseDialMinMakeTime    OBJECT-TYPE  
<       SYNTAX       Unsigned32 (1..200)  
with
> pktcNcsEndPntConfigPulseDialMinMakeTime    OBJECT-TYPE  
>       SYNTAX       Unsigned32 (20..200)  

-----------------------------------
 1.b) Proposal to consider mibsig-o-03004-v3 as additional input
 We addressed this proposal as part of issue #1.
 No consensus, more text on the mailing lists.

-----------------------------------
 1.c) Comments from Satish logged in these meeting notes
- PktcRingCadence - need to know the MSB
 Team debated that this is covered by SNMP STD RFCs. interval(0) is
MSB; we found RFC 2579 section 3.1. as a possible normative reference
for this. Team is ok with Satish proposing one sentence to clarify
text.

- pktcSigServiceClassNameMask  
   Satish raised a comment re: syntax of this object. What does it
mean to have a non-zero value for the mask?
   Eugene said: see DOCSIS RFI 1.1 page 144, IP classifier def has 3
masks:
"   IP Classification Parameters: zero or more of the IP classification
parameters (IP TOS Range/Mask, IP Protocol, IP Source Address/Mask, IP
Destination Address/Mask, TCP/UDP Source Port Start, TCP/UDP Source
Port End, TCP/UDP Destination Port Start, TCP/UCP Destination Port
End)"
=> the question still remains:
We dismissed the TOS masks in DOCSIS mibs so we eliminated that one.
Still, is the mask defined in pktcSigServiceClassNameMask applicable to IP
source mask or destination or both?
AI: Based upon the answer, revise description clause.
   pktcSigServiceClassNameMask  OBJECT-TYPE
        SYNTAX     Integer32
        MAX-ACCESS  read-write
        STATUS     current
        DESCRIPTION
            " This object contains a value used for the NCS Call
              Signaling classifier mask. If this object is set to a
              zero value, an MTA MUST delete both NCS SFs. When
              this object is set to a non-zero value, an MTA MUST
              create the NCS SF for which the corresponding MIB object
              (pktcSigServiceClassNameUS  or pktcSigServiceClassNameDS)
              has a non-empty value, if the NCS SF does not already
              exist."
        DEFVAL { 0 }
        ::= { pktcSigDevConfigObjects 14 }

- pktcSigPulseSignalRepeatCount 
  do we need a DEFVAL for this object?
  AI: team to comment
    pktcSigPulseSignalRepeatCount    OBJECT-TYPE
       SYNTAX       Unsigned32 (0..5000)
       MAX-ACCESS   read-write
       STATUS       current
       DESCRIPTION
           " This is the repeat count, which signifies how many times
             to repeat the pulse."
       ::={ pktcSigPulseSignalEntry 6 }

- pktcNcsEndPntConfigEntry
   Nit: junk char in description
   pktcNcsEndPntConfigEntry  OBJECT-TYPE
       SYNTAX        PktcNcsEndPntConfigEntry
       MAX-ACCESS    not-accessible
       STATUS        current
       DESCRIPTION
           " Entries in pktcNcsEndPntConfigTable û Each entry describes
->                                             ^^^^
             what signaling type a particular endpoint uses."

>end. 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 1 Aug 2003 10:51:25 -0600

Satish,

I'm not sure I understand the email you sent today.
> I am in favour to Obsolete the MIBS marked in comment #12. 

You attended the meeting yesterday where we discussed those same outstanding issues on the signaling MIB, right? You were also in copy of the meeting notes I sent to ipcdn and asking for comments.  Did you read the decisions logged in the notes?

For e.g.,
On Issue #1, see my notes, consensus is to *not* delete the object, hence Gordon's proposal was rejected by some of us. 
On Issue #2 - #11 - same comments. Please read the notes I sent and comment on the thread!
On Issue #12, the proposal made by Gordon is to simply redefine the range for those objects, not delete them. I don't understand your comment here either. 

Please clarify your statement below. 
Jean-François 

-----Original Message-----
From: Satish Kumar at Texas Instruments 
Sent: Friday, August 01, 2003 9:28 AM
To: 'Beacham Gordon-CGB005'; [email-masked]'
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

Gordon,

Thanks,
Satish Kumar
Texas Instruments
-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email-masked]]
Sent: Monday, July 28, 2003 5:52 PM
To: [email-masked]'
Subject: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

Rick, 
Thanks for your review of the signaling MIB recommendations and for providing additional suggestions.
For items 1-5 and 7,8, and 10 there is substantial agreement, and I have made the changes as indicated in the open issues list (as posted on the IPCDN web site and included in your document), however, there is one minor exception  item 8. It turns out that sixteenthousand is more commonly used than twelvethousand. Consequently, the description and default are recommended to be sixteenthousand not twelvethousand. 
For item 9, Motorola agrees with the default change recommended. 
For item 11, Motorola agrees with the recommendation to obsolete these objects. These objects are product hardware design issues. 
For item 6, Motorola, after further review determined that there is already an object for setting the level for dtmf or any other tone (pktcSigDevToneDbLevel), which can vary by geographic location. Consequently, the only change recommended for item 6 then is the addition of 3 user defined tones.
For item 12, Motorola does not agree with obsoleting these objects. The dial pulse objects vary by geographic location (e.g., NA, Europe, Japan, etc), and need to be retained in order to be adjusted as necessary by the operator.
Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
[email-masked]
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 25, 2003 2:08 PM
To: Wim De Ketelaere
Cc: Gordon Beacham; [email-masked]; [email-masked]
Subject: Re: Fw: Publication of PacketCable IETF MIBs - SIB draft 01

Wim and Gorden, 

I apologize for the length of time it has taken me to get this response back to you.     However, we wanted to make sure that we had thoroughly reviewed and considered each of Gorden's suggestions.  Please distribute our comments to your list as appropriate. 

I would like to say that Gorden has done an excellent job of scoping out several suggested changes.  The attached document from ARRIS contains any agreements with his recommendations, along with a couple of additional comments.  ARRIS would be very interested with discussing our comments with you, and others on your distribution list at your convenience. 

Thank you both for your efforts in working to clean up this MIB's contents.  With the joint cooperation of tComLabs and the MTA vendors, I feel confident we can all move towards a successful certification wave in ECW13. 

Regards, 
Rick Morris 

        To:        <[email-masked]> 
        cc:        <[email-masked]> 
        Subject:        Fw: Publication of PacketCable IETF MIBs - SIB draft 01

Hi Rick,

Here's the document !

Thanks,
 Best regards,
   Wim

---

From: "Kumar, Satish" <[email-masked]>
Date: Sat, 2 Aug 2003 02:10:01 +0530

Jean-François,
 Sorry for all the confusion.. I missed a portion of the call yesterday
which resulted the confusing mail. I did gone thru your comments proposed on
IPCDN and here is my openon on each item. My comments matches to your
postings in Ipcdn. This overides my all earlier mails

issue#1: Agreed, NOT to delete the pktcSigDevCodecTable untill the new
proposal is thru(mibsig-o-03004)
issue#2: Agreed to obsolete the MIBs
issue#3: Agreed to change MIBs to read-only
issue#4: Agreed to obsolete the MIBs
issue#5: Agreed to obsolete the MIBs
issue#6: Agreed to retain DTMF 0-15
issue#7: Agreed to change the range in SYNTAX
issue#8: Agreed to remove fifty(2) and reword description
issue#9: Agreed to change the range
issue#10: Agreed to obsolete the MIBs
issue#11: Agreed to obsolete the MIBs
issue#12: Agreed to change the range, not to obsolete the MIB(discard
earlier mail)

My action item(one sentence summary) for PktcRingCadence: 
Current text: 64 bits MUST be used for cadence representation.
Proposed text: 64 bits MUST be used for cadence representation with
interval1(bit0) as MSB. 

Thanks,
Satish Kumar
Texas Instruments

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Friday, August 01, 2003 4:51 PM
To: Kumar, Satish; Beacham Gordon-CGB005; [email-masked]
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG
draft 01

Satish,

> I am in favour to Obsolete the MIBS marked in comment #12. 

You attended the meeting yesterday where we discussed those same outstanding
issues on the signaling MIB, right? You were also in copy of the meeting
notes I sent to ipcdn and asking for comments.  Did you read the decisions
logged in the notes?

For e.g.,
On Issue #1, see my notes, consensus is to *not* delete the object, hence
Gordon's proposal was rejected by some of us. 
On Issue #2 - #11 - same comments. Please read the notes I sent and comment
on the thread!
On Issue #12, the proposal made by Gordon is to simply redefine the range
for those objects, not delete them. I don't understand your comment here
either. 

-----Original Message-----
From: Satish Kumar at Texas Instruments 
Sent: Friday, August 01, 2003 9:28 AM
To: 'Beacham Gordon-CGB005'; [email-masked]'
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

Gordon,

Thanks,
Satish Kumar
Texas Instruments
-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email-masked]]
Sent: Monday, July 28, 2003 5:52 PM
To: [email-masked]'
Subject: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

Rick, 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 25, 2003 2:08 PM
To: Wim De Ketelaere
Cc: Gordon Beacham; [email-masked]; [email-masked]
Subject: Re: Fw: Publication of PacketCable IETF MIBs - SIB draft 01

Wim and Gorden, 

Regards, 
Rick Morris 

Hi Rick,

Here's the document !

Thanks,
 Best regards,
   Wim

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Fri, 1 Aug 2003 14:10:14 -0700

I hate doing that but I cannot resist asking the following question: if we agree to make clarification in PktcRingCadence TC on bit-0 being an MSB, then why don't we do the same with all other TCs of type BITS (and we have several of them in both MTA and SIG MIBs) ? 

Eugene.

-----Original Message-----
From: Kumar, Satish [mailto:[email-masked]]
Sent: Friday, August 01, 2003 1:40 PM
To: 'Jean-Francois Mule'; Beacham Gordon-CGB005; [email-masked]
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG
draft 01

Jean-François,

Thanks,
Satish Kumar
Texas Instruments

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Friday, August 01, 2003 4:51 PM
To: Kumar, Satish; Beacham Gordon-CGB005; [email-masked]
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG
draft 01

Satish,

For e.g.,

-----Original Message-----
From: Satish Kumar at Texas Instruments 
Sent: Friday, August 01, 2003 9:28 AM
To: 'Beacham Gordon-CGB005'; [email-masked]'
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

Gordon,

Thanks,
Satish Kumar
Texas Instruments
-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email-masked]]
Sent: Monday, July 28, 2003 5:52 PM
To: [email-masked]'
Subject: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

Rick, 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 25, 2003 2:08 PM
To: Wim De Ketelaere
Cc: Gordon Beacham; [email-masked]; [email-masked]
Subject: Re: Fw: Publication of PacketCable IETF MIBs - SIB draft 01

Wim and Gorden, 

Regards, 
Rick Morris 

Hi Rick,

Here's the document !

Thanks,
 Best regards,
   Wim

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 1 Aug 2003 23:33:55 +0200

> From: Eugene Nechamkin [mailto:[email-masked]]
> Sent: vrijdag 1 augustus 2003 23:10
> To: Kumar, Satish; Jean-Francois Mule; Beacham Gordon-CGB005;
> [email-masked]
> I hate doing that but I cannot resist asking the following 
> question: if we agree to make clarification in 
> PktcRingCadence TC on bit-0 being an MSB, then why don't we 
> do the same with all other TCs of type BITS (and we have 
> several of them in both MTA and SIG MIBs) ? 
> 
If you look at the definition of BITS in RFC2579, sect 7.1.4
and how they are encoded in RFC3416, sect 2.5, then it seems
to me that there may be no need to go into details here,
is there? In any event, I do not recall that I ever saw
it explained when BITS are used.

Bert

---

From: "Kumar, Satish" <[email-masked]>
Date: Sat, 2 Aug 2003 03:16:41 +0530

If we go with clarification for MSB, both MTA and Signaling MIB in total has
only THREE objects.
pktcRingCadence, pktcSigDevConnectionMode  ===> Signaling MIB
pktcMtaDevResetKrbTickets===> MTA MIB

Adding clarification avoids unnessary confusion or else we need to quote RFC
reference in the MIB definition.

Thanks,
SatishK

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, August 01, 2003 9:34 PM
To: Eugene Nechamkin; Kumar, Satish; Jean-Francois Mule; Beacham
Gordon-CGB005; [email-masked]
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG
draft 01

Bert

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 1 Aug 2003 15:51:43 -0600

Bert,

Thanks. I agree with your point that RFC 3416 section 2.5 explains the BITS
syntax very well... but it looks like we didn't realize that as we worked on
different IPCDN MIBs.

For example, from
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt>:

docsIfCmCapabilities OBJECT-TYPE
        SYNTAX      BITS {
            atmCells(0),
            concatenation(1)
        }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "Identifies the capabilities of the MAC implementation
             at this interface. Note that packet transmission is
             always supported. Therefore, there is no specific bit
             required to explicitly indicate this capability.
             Note that BITS objects are encoded most significant bit
             first. For example, if bit 1 is set, the value of this
             object is the octet string '40'H."
        ::= { docsIfCmMacEntry 2 }

and from
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-08.txt>:

docsQosPktClassBitMap OBJECT-TYPE
    SYNTAX          BITS {              -- Reference SP-RFIv1.1-I09-020830
                        rulePriority(0),     -- Appendix C.2.1.3.4
                        activationState(1),  -- Appendix C.2.1.3.6
                        ipTos(2),            -- Appendix C.2.1.5.1
                        ipProtocol(3),       -- Appendix C.2.1.5.2
                        ipSourceAddr(4),     -- Appendix C.2.1.5.3
                        ipSourceMask(5),     -- Appendix C.2.1.5.4
                        ipDestAddr(6),       -- Appendix C.2.1.5.5
                        ipDestMask(7),       -- Appendix C.2.1.5.6
                        sourcePortStart(8),  -- Appendix C.2.1.5.7
                        sourcePortEnd(9),    -- Appendix C.2.1.5.8
                        destPortStart(10),   -- Appendix C.2.1.5.9
                        destPortEnd(11),     -- Appendix C.2.1.5.10
                        destMac(12),         -- Appendix C.2.1.6.1
                        sourceMac(13),       -- Appendix C.2.1.6.2
                        ethertype(14),       -- Appendix C.2.1.6.3
                        userPri(15),         -- Appendix C.2.1.7.1
                        vlanId(16)           -- Appendix C.2.1.7.2
                    }
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
                    "This object indicates which parameter encodings were
                    actually present in the DOCSIS packet classifier
                    encoding signaled in the DOCSIS message that
                    created or modified the classifier. Note that
                    Dynamic Service Change messages have replace
                    semantics, so that all non-default parameters must
                    be present whether the classifier is being created
                    or changed.

                    A bit of of this object is set to 1 if the parameter
                    indicated by the comment was present in the classifier
                    encoding, and 0 otherwise.

                    Note that BITS are encoded most significant bit
                    first, so that if e.g. bits 6 and 7 are set, this object
                    is encoded as the octet string '030000'H.
                   "
    ::= { docsQosPktClassEntry 27 }

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, August 01, 2003 5:34 PM
To: Eugene Nechamkin; Kumar, Satish; Jean-Francois Mule; Beacham

Bert

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Fri, 1 Aug 2003 14:59:22 -0700

That's exactly the reference I had in mind when was asking my inital question. I think it's better not to explain something which has a clear reference to the existing RFC.

Eugene.

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Friday, August 01, 2003 2:52 PM
To: 'Wijnen, Bert (Bert)'; Eugene Nechamkin
Cc: Kumar, Satish; Jean-Francois Mule; Beacham Gordon-CGB005;
[email-masked]

Bert,

For example, from

and from

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, August 01, 2003 5:34 PM
To: Eugene Nechamkin; Kumar, Satish; Jean-Francois Mule; Beacham

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 2 Aug 2003 00:16:38 +0200

> Sent: vrijdag 1 augustus 2003 23:58
> To: 'Kumar, Satish'; 'Wijnen, Bert (Bert)'; Eugene Nechamkin;
> Jean-Francois Mule; Beacham Gordon-CGB005
> Cc: [email-masked]
> >Adding clarification avoids unnessary confusion or else we
> >need to quote RFC reference in the MIB definition.
> 
> But the reference to the BITS definition in RFCs 2578 and 
> 3416 are implied in all MIB internet-drafts, just as the definition 
> for INTEGER or OCTET STRING syntax.
> 
> I agree with Bert that the clarifications should be removed, for
> consistency's sake.
> 
Indeed. It seems a waste of time to repeat stuff that is kind
of standard for ALL MIB modules.

Bert
> Sent: Friday, August 01, 2003 5:47 PM
> To: 'Wijnen, Bert (Bert)'; Eugene Nechamkin; Jean-Francois 
> Mule; Beacham

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 1 Aug 2003 15:58:09 -0600

>need to quote RFC reference in the MIB definition.

But the reference to the BITS definition in RFCs 2578 and 3416 are implied
in all MIB internet-drafts, just as the definition for INTEGER or OCTET
STRING syntax.

-- Rich

-----Original Message-----
From: Kumar, Satish [mailto:[email-masked]]
Sent: Friday, August 01, 2003 5:47 PM
To: 'Wijnen, Bert (Bert)'; Eugene Nechamkin; Jean-Francois Mule; Beacham

Thanks,
SatishK

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, August 01, 2003 9:34 PM
To: Eugene Nechamkin; Kumar, Satish; Jean-Francois Mule; Beacham

Bert

---

From: Paul Duffy <[email-masked]>
Date: Mon, 04 Aug 2003 11:39:39 -0400

>reference in the MIB definition.

Agreed.  Explicitly stating MSB would help (or explicitly reference 
appropriate RFC (exists?))

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Paul Duffy <[email-masked]>
Date: Mon, 04 Aug 2003 11:39:39 -0400

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Tue, 5 Aug 2003 12:59:52 -0700

Satish,
 
Regarding issue 1.c), a default value of zero will be fine for this meter pulse object.
 
Gordon

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Thursday, July 31, 2003 5:53 PM
To: Gordon Beacham; [email-masked]; Wim De Ketelaere; [email-masked]
Cc: [email-masked]; [email-masked]; Satish Kumar at Texas Instruments; Sumanth Channabasappa; Rick Vetter
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

All,

Jean-Francois.

--- Participants

Robert Lund - Terayon

Satish Kumar - TI

Paul Duffy - Cisco

 - Signaling MIB

 <http://www.ipcdn.org/meetings/sigmib-01-outstanding-issues.html> http://www.ipcdn.org/meetings/sigmib-01-outstanding-issues.html

 <http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00754.html> http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00754.html

thread to follow.

AI:

Consensus :

Consensus :

replace

by

And replace

by

Consensus :

replace

<       SYNTAX       INTEGER {  

<                    zero (1),  

<                    fifty(2),  

<                    twelvethousand(3),  

<                    sixteenthousand(4) 

<       }             

with

Consensus :

replace

with

- Issue 10  

Consensus :

- Issue 11

Consensus :

- Issue 12

Consensus :

mins

For e.g.,

replace

with

text.

masks:

End)"

        SYNTAX     Integer32

        MAX-ACCESS  read-write

        STATUS     current

        DESCRIPTION

              exist."

        DEFVAL { 0 }

  AI: team to comment

       MAX-ACCESS   read-write

       STATUS       current

       DESCRIPTION

             to repeat the pulse."

       STATUS        current

       DESCRIPTION

->                                             ^^^^

---

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Wed, 6 Aug 2003 16:17:00 -0700

Bert,

Thanks for your comments. To address them specifically:

1. Removed non-US ASCII characters.
2. Changed index element pktcSigDevToneType to not-accessible from read-only. Also removed pktcSigDevToneType from pktcInternationalGroup. Moved pktcNcsEndPntStatusCallIpAddressType above pktcNcsEndPntStatusCallIpAddress and renumbered objects.
3. Changed to: pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 }.
4. Expanded "MTA" in MIB title.
5. No change. The reserved value is to preserve the sequential enumeration as you indicated.
6. Changed pktcSigDevCodecEntry description.
7. No change. This was already changed from 16k to a more reasonable 255 per comments received prior to issuing rev 1 of the Signaling MIB. It is almost certain we will never have more than 255 codecs in an MTA.
8. No change. There is a ECO pending on this table in PC. Don't want to change this object and have to change it again pending the ECO.
9. No change. Echo cancellation is a device capability.
10. Not sure about this one. The MIB is for international use but the DOCSIS spec indicates the text is ASCII per the RFI spec section 8.1.7.1 and C.2.2.3.4.
11. TBD.
12. Updated pktcSigPulseSignalTable DESC to indicate objects in this table do not persist across a reboot.
13. Updated pktcSigDevRingCadenceTable and pktcSigDevToneTable DESC to indicate objects in these tables do not persist across a reboot.
14. Updated pktcSigEndPntConfigTable DESC to indicate objects in this table do not persist across a reboot. Added RowStatus object for this table.
15. Duplicate of 14. I think you meant pktcNcsEndPntConfigTable. Updated the DESC class to indicate objects in this table do not persist across a reboot. 
16. Changed description to [email-masked].

Gordon

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, August 01, 2003 9:07 AM
To: Jean-Francois Mule; Gordon Beacham; [email-masked]; Wim De
Ketelaere; [email-masked]
Cc: [email-masked]; [email-masked]; Satish Kumar at
Texas Instruments; Sumanth Channabasappa; Rick Vetter
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG
draft 01

6. In 

8. pktcSigDevCodecMax ?? 

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: vrijdag 1 augustus 2003 2:53
To: [email-masked]; [email-masked]; Wim De Ketelaere; [email-masked]
Cc: [email-masked]; [email-masked]; Satish Kumar at Texas Instruments; Sumanth Channabasappa; Rick Vetter
Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01

All,

  
--- Participants

AI:

And replace

- Issue 10  

- Issue 11

- Issue 12

For e.g.,
replace