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

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Mon, 28 Jul 2003 10:51:36 -0700

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 on 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: Beacham Gordon-CGB005 <[email-masked]>
Date: Tue, 29 Jul 2003 06:49:50 -0700

It has been brought to my attention that a pending PC Signaling MIB ECO should be considered for item 1 (pktcSigDevCodecTable).
 
Instead of obsoleting pktcSigDevCodecTable, the suggestion is to adopt the changes in sigmib-o-03004-v2 as the new definition for the pktcSigDevCodecTable, and only obsolete the pktcSigDevCodecMax object.
 
Gordon

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

Rick, 

Gordon Beacham

Motorola, Inc.

858-404-2335

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

07/03/2003 01:53 PM 

Hi Rick,

Here's the document !

Thanks,
 Best regards,
   Wim

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 29 Jul 2003 09:33:15 -0600

Gordon,

Thanks for raising this issue on the list.
I don't agree with accepting this ECO as part of the ipcdn draft
revision unless:
 1. the proposed changes are disclose to the ipcdn list
    the eco you reference is not accessible to IETF & ipcdn folks and
ECOs are covered by the IPR agreement. This means that if the authors of
the ECO (in copy) want to disclose the proposed changes, they should
send text to the ipcdn list.
 2. the proposed changes represent a rough consensus
    I think it needs some more discussions, especially since we have
passed WGLC!

Jean-Francois 

-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2003 7:50 AM
To: [email-masked]'
Subject: [ipcdn] RE: Publication of PacketCable IETF MIBs - SIG draft 01

It has been brought to my attention that a pending PC Signaling MIB ECO
should be considered for item 1 (pktcSigDevCodecTable).

Instead of obsoleting pktcSigDevCodecTable, the suggestion is to adopt
the changes in sigmib-o-03004-v2 as the new definition for the
pktcSigDevCodecTable, and only obsolete the pktcSigDevCodecMax object.

Gordon

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 31 Jul 2003 18:52:36 -0600

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