Freyman Phillip-FPF300 | 1 Sep 2005 16:14

FW: IPCDN Digest, Vol 15, Issue 16

Eugene,

Thank you for reviewing the GR 506 document however, I do not fully agree with your proposal.

Per your email, GR 506 states:

Table 12-2. Flash Response Enabled Timing
On-Hook Duration (milliseconds) SPCS Interpretation

< 200 Hit
200 to 300 Hit or Flash
300 to 1100 Flash
1100 to 1550 Flash or Disconnect
>1550 Disconnect

This implies that the network MUST accept 300 to 1100 milliseconds as hook flash and must NOT accept less
than 200 ms or more than 1550 ms.

The ranges of 200 to 300 and 1100 to 1550 are ranges where the network may accept or may reject the timing.

I do agree that some changes may be appropriate in the ranges of min/max values..

I do not agree with your proposed max default value and propose the following to bring the SigMIB into
alignment with GR 506.

Current rev8 text:

pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1000) 
    UNITS        "Milliseconds" 
(Continue reading)

Thomas Anders | 1 Sep 2005 17:37
Picon
Favicon

Re: FW: IPCDN Digest, Vol 15, Issue 16

Freyman Phillip-FPF300 wrote:
> Proposed rev8 text change:
> 
> pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
>     SYNTAX       Unsigned32 (200..1550) 
[...]
> pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 
>     SYNTAX       Unsigned32 (200..1500) 

I guess you rather intended to propose "(200..1550)" for 
pktcNcsEndPntConfigMaxHookFlash, too?

+Thomas

--

-- 
Thomas Anders (thomas.anders at blue-cable.de)
ewt breitbandnetze gmbh, berlin, germany
Nakanishi Greg-MGI8179 | 1 Sep 2005 18:44

RE: cable dev mib draft09 - WG consensus requested on pro posed changes

I concur with the proposed resolution.
 
For Issue 4, my preference is that 'MUST NOT' be used, rather than 'SHOULD NOT'.  I think a device will run into operational problems if it maintains these table entries across reboots.  When the device reboots, the config log will attempt to create rows in these tables and will fail if the rows already exists.
 
greg

From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of Jean-Francois Mule
Sent: Monday, August 15, 2005 3:20 PM
To: ipcdn <at> ietf.org
Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes

Folks,

   As you may have read in meeting notes from last week, we spent the IETF 63 meeting discussing the closure of open issues on the CD mib v2.

   The meeting notes proposed some changes to get final (yes, final) closure on this mib.

Please review the text below and please speak up if you have some concerns (it's also welcome that you express your agreement).

Thanks,

Jean-François

[extract from ipcdn minutes]

3.1/ DOCSIS Cable Device MIB version 2

     draft-ietf-ipcdn-device-mibv2-09.txt

     Editors: Kevin Marez & Rich Woundy

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt

We spent most of the meeting reviewing the 4 top remaining issues, see

summary sent by Rich and Kevin in:

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html


+ ISSUE #1: DEFVAL for docsDevNmAccessInterfaces

Raised by Randy, the issue is, in the defval we have a 4 octet value

=> How can systems with interfaces in a number not multiple

of 8 interpret the DEFVAL value. Are bits ignored?

Randy commented that he would be ok if there was some mention like

'octets containing bits corresponding to non-existent interfaces are

ignored.' That said, if there are implementations that would reject a

SET, then we need to say something about that.

Rich commented that the DEFVAL was added due to prior MIB doctor

comment and that the object is now deprecated. Bert asked whether

there was any concern deleting the DEFVAL.

Proposal for wg review:

 a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h }

 b) consider the following (NICE TO HAVE kind of fix)

    adding a sentence to say something like:

    bits set corresponding to non-existing interfaces is

    implementation specific (to warn the mgmt admin/apps that no

    assumptions should be made on existing implementations of this

    object. (Randy's suggestion)


+ ISSUE #2: docsDevNmAccessStatus

-- Also, we should change the DESCRIPTION of docsDevCpeStatus

-- and docsDevCpeInetRowStatus to document how the agent adds rows.

See issue raised by Randy and the email summary provided by Rich for

the context around this issue #2.

We had some discussions around the persistency of those tables, the

fact that the CM config file drives the row creation at boot-up and

the fact that they are read-create tables so admins can also create

entries as Bert pointed out.

In most cases (except for docsDevEvControlTable), entries do not

persist across CM reboots. Even in the case of docsDevEvControlTable,

after some discussion, we believe that the entries are cleared and

"recreated" after the CM reads the config file. That is the common

understanding.

Bert said: add a statement ("this is a deprecated table, this is

vendor specific as to what vendors do with this table, mgmt app cannot

expect a certain behavior").

+ ISSUE #3: docsDevEvReporting and local(0) rows

Comment close: ID authors agree with Randy's comment re: local(0) rows

MUST persist. Text will be revised.

in docsDevFilterLLCTable:

             Any attempt to SET the traps(1) or syslog(2) bits

             without setting the local(0) or localVolatile(8)

             bits MUST result in an error being generated.

Proposal:

   DELETE above text if nobody complains after reading the meeting

   notes

+ ISSUE #4: docsDevFilterLLCTable

Issue is around text for the level of requirements on table

persistence. Agree with Rich's text proposal:

  |"Table entries MUST NOT persist across reboots for cable modems."

Rich also proposed to apply this requirement to:

  NmAccess, FilterLLC, FilterIp, Policy, Tos,

  Cpe and InetCpe tables.

It was suggested to use SHOULD NOT rather than MUST NOT but other than

that, proposal is ok.


+ Other items on CD Device MIB:

Randy added for consideration:

wherever we have this "must not persist" langage in table definitions,

it would be a plus to indicate that they may come back as entries may

reappear when CM reboots and comes up with config file. Or consider

adding this in the front paper as a consideration for users of the

MIBs if that is too many little edits in the MIB objects.

Proposal:

  add a note on persistence model explaining the persistance of some

mib objects and the CM re-creating them upon config file reloading.

A comment was made that in general, we should indicate the persistency

model in each object rather than in the compliance section.

Bert also commented on the compliance sections: if different

requirements apply to CM and CMTS, suggestion is to make 2 different

compliances. Rich added that the new compliance statement is designed

like that.

# AI: [authors: Kevin Marez & Rich Woundy]

# Authors to summarize list of agreed changed and the technical

# changes in the text per wg consensus and issue new draft after AD

# review comments are in.

# Due by early September?

# AD review by Bert due by August 15

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
Eugene Nechamkin | 2 Sep 2005 06:00
Favicon

RE: FW: IPCDN Digest, Vol 15, Issue 16


Phil,

I agree with your approach to modify two objects - Min and Max with the
following comment:

ETSI EN 300 001 V1.5.1 spec defines the break period (which is an equivalent
for flash) as being as low as 50ms (Table 9.1.1). As a reality check - we
have seen some European requests for having the flash range starting from
50-100ms. Hence, I would think that the lower range of 20 msec for both
objects would have a better chance to meet the various requirements in the
field. The following objects definitons seem to be satisfactory from our
prospective:

pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1550) 
    .....
    DEFVAL (300)

pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1550) 
    .....
    DEFVAL (1100)

Eugene.

-----Original Message-----
From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of
Freyman Phillip-FPF300
Sent: Thursday, September 01, 2005 7:14 AM
To: 'ipcdn <at> ietf.org'
Subject: [ipcdn] FW: IPCDN Digest, Vol 15, Issue 16

Eugene,

Thank you for reviewing the GR 506 document however, I do not fully agree
with your proposal.

Per your email, GR 506 states:

Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds)
SPCS Interpretation

< 200 Hit
200 to 300 Hit or Flash
300 to 1100 Flash
1100 to 1550 Flash or Disconnect
>1550 Disconnect

This implies that the network MUST accept 300 to 1100 milliseconds as hook
flash and must NOT accept less than 200 ms or more than 1550 ms.

The ranges of 200 to 300 and 1100 to 1550 are ranges where the network may
accept or may reject the timing.

I do agree that some changes may be appropriate in the ranges of min/max
values..

I do not agree with your proposed max default value and propose the following
to bring the SigMIB into alignment with GR 506.

Current rev8 text:

pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1000) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the minimum time a line needs to be on hook for a
          valid hook flash. The value of this object MUST be
          greater than the value of
          pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of
          pktcNcsEndPntConfigMinHookFlash MUST be less than
          pktcNcsEndPntConfigMaxHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process.
             Furthermore, given the possibility for the 'pulse dial' 
             and 'hook flash' to overlap, the value of this object MUST

             be greater than the value contained by the MIB Object 
             pktcNcsEndPntConfigPulseDialMaxMakeTime."
    DEFVAL { 300 } 
    ::= { pktcNcsEndPntConfigEntry 32 } 

pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1000) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the maximum time a line needs to be on hook for a
          valid hook flash. The value of
          pktcNcsEndPntConfigMaxHookFlash MUST be greater than
          pktcNcsEndPntConfigMinHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process."
    DEFVAL { 800 } 
    ::= { pktcNcsEndPntConfigEntry 33 } 

Proposed rev8 text change:

pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (200..1550) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the minimum time a line needs to be on hook for a
          valid hook flash. The value of this object MUST be
          greater than the value of
          pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of
          pktcNcsEndPntConfigMinHookFlash MUST be less than
          pktcNcsEndPntConfigMaxHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process.
             Furthermore, given the possibility for the 'pulse dial' 
             and 'hook flash' to overlap, the value of this object MUST

             be greater than the value contained by the MIB Object 
             pktcNcsEndPntConfigPulseDialMaxMakeTime."
    DEFVAL { 300 } 
    ::= { pktcNcsEndPntConfigEntry 32 } 

pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (200..1500) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the maximum time a line needs to be on hook for a
          valid hook flash. The value of
          pktcNcsEndPntConfigMaxHookFlash MUST be greater than
          pktcNcsEndPntConfigMinHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process."
    DEFVAL { 1100 } 
    ::= { pktcNcsEndPntConfigEntry 33 } 

Regards,
Phil
-----Original Message-----
From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of
ipcdn-request <at> ietf.org
Sent: Wednesday, August 31, 2005 11:08 AM
To: ipcdn <at> ietf.org
Subject: IPCDN Digest, Vol 15, Issue 16

Send IPCDN mailing list submissions to
	ipcdn <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ipcdn
or, via email, send a message with subject or body 'help' to
	ipcdn-request <at> ietf.org

You can reach the person managing the list at
	ipcdn-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific than "Re:
Contents of IPCDN digest..."

Today's Topics:

   1. RE: draft-ipcdn-pktc-signaling-08, further	changes;result of
      conference call (Eugene Nechamkin)

----------------------------------------------------------------------

Message: 1
Date: Tue, 30 Aug 2005 18:44:56 -0700
From: "Eugene Nechamkin" <enechamkin <at> broadcom.com>
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further
	changes;result of conference call
To: "Sumanth Channabasappa" <sumanth <at> cablelabs.com>
Cc: ipcdn <at> ietf.org
Message-ID:
	
<24CDBA67F085904999751B3C4F9E8C0B031230A3 <at> NT-RMNA-0740.brcm.ad.broadcom.com>
	
Content-Type: text/plain; charset=iso-8859-1

Sumanth,

Looking further at the Bellcore specs for pulse flash requirements
(GR-506-CORE "LSSGR: Signaling for Analog Interfaces"), it turnes out that
the requirements for the pulse range for flash are higher than it is
currently allowed by the "pktcNcsEndPntConfigMaxHookFlash" MIB Object.
Bellcore specs say that flash MUST be 300-1100, but may be up to 1550:

Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds)
SPCS Interpretation

< 200 Hit
200 to 300 Hit or Flash
300 to 1100 Flash
1100 to 1550 Flash or Disconnect
>1550 Disconnect

To better meet the Bellcore specs requirements, the following modification of
the MIB Object's range is proposed:

   pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE  
       SYNTAX       Unsigned32 (20..1550)  
       UNITS        "Milliseconds"  
       MAX-ACCESS   read-only  
       STATUS       current  
       DESCRIPTION  
           " This is the maximum time a line needs to be on hook for a 
             valid hook flash. The value of 
             pktcNcsEndPntConfigMaxHookFlash MUST be greater than 
             pktcNcsEndPntConfigMinHookFlash. This object MUST only be 
             set via the configuration file during the provisioning 
             process." 
       DEFVAL { 800 }  
       ::= { pktcNcsEndPntConfigEntry 33 }   

.

-----Original Message-----
From: Sumanth Channabasappa [mailto:sumanth <at> cablelabs.com]
Sent: Friday, August 26, 2005 7:24 AM
To: Jean-Francois Mule
Cc: ipcdn <at> ietf.org; Freyman Phillip-FPF300; Eugene Nechamkin; David De Reu;
T, Shivakumar; sercu <at> tComLabs.com; Satish Kumar at Texas Instruments; Beacham
Gordon-CGB005
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of
conference call

Jean-Francois,

I concur. Unless there are objections, I will be presenting the final
proposal to this group in the next week.

Regards
Sumanth 

-----Original Message-----
From: Jean-Francois Mule
Sent: Friday, August 26, 2005 7:18 AM
To: Sumanth Channabasappa
Cc: ipcdn <at> ietf.org; 'Freyman Phillip-FPF300'; 'Eugene Nechamkin'; 'David De
Reu'; 'T, Shivakumar'; 'sercu <at> tComLabs.com'; Satish Kumar at Texas
Instruments; 'Beacham Gordon-CGB005'
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of
conference call

Sumanth,

   Thanks for inviting anyone from IETF ipcdn to attend the discussion and
for the notes.

   We have not seen one comment on your posting in 15 days so the proposal
should be good enough. Per the IETF#63 meeting, the action item on the
signaling MIB was: # AI: authors to close one open issue on tone table by
August 20. # Ask Randy to review final proposal.

  Can you put out the proposed changes in the form of updated object
definitions to the list so we can see all the aggregated changes?

  Based on our discussions, we are getting close to the end on this one and I
would like to set the date of next Friday, September 2nd to have a consensus
on the technical changes to allow a draft09 publication by mid-September at
the latest.

Thanks,
Jean-François

> -----Original Message-----
> From: Sumanth Channabasappa
> Sent: Wednesday, August 10, 2005 10:09 AM
> To: ipcdn <at> ietf.org
> Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result 
> of conference call
> 
> Folks,
> 
> As per the discussion on the conference call today (thanks to the 
> attendees), the proposal from Phil seems to be reasonable.
> 
> Further, there was a suggestion to include the following examples in 
> the draft for clarity and ease of implementation. Note: Example B was 
> also the cause for the latest suggestion.
> 
> 
> Example A:  Call waiting tone defined per ITU-T E.180:
> 1)	400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm
> 2)	400 Hz AM modulated by 16 Hz, off for 400ms
> 3)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 4)	400 Hz not AM modulated, off for 450 ms
> 5)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 6)	400 Hz not AM modulated, off for 3450 ms
> 7)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 8)	400 Hz not AM modulated, off for 450 ms
> 9)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 10)	400 Hz not AM modulated, off for 3450 ms
> 11)	not repeated, not continuous
> 
> Assume userDefined1(17) is assigned to this tone:
> 
> ToneType|Freq-1|Freq-2|Freq-3|Freq-
> 4|FreqMode|ModePrtg|DbLevel|OnDur|Off
> Dur|Rep-Count
> ======================================================================
> ==
> =============
> 17       400     16       0       0     1        90      -40    500
> 400    0
> 17       400      0       0       0     2         0      -40     50
> 450    0
> 17       400      0       0       0     2         0      -40     50
> 3450    0
> 17       400      0       0       0     2         0      -40     50
> 450    0
> 17       400      0       0       0     2         0      -40     50
> 3450    0
> 
> 
> pktcSigDevToneTable:
> ToneType|ToneRep-Count|Steady
> ================================
>   17         0         false(2)
> 
> 
> ----------------------------------------------------------------------
> --
> ---------------
> 
> Example B - Congestion Tone - congestion(17):
> 
> This example of an embedded cadence is based on an operator variation.
> 1) 400Hz on for 400ms -10 dBm
> 2) 400Hz off for 350ms
> 3) 400Hz on for 225ms -4 dBm
> 4) 400Hz off for 525ms
> 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is 
> shortest period)
> 
> ToneType|Freq-1|Freq-2|Freq-3|Freq-
> 4|FreqMode|ModePrtg|DbLevel|OnDur|Off
> Dur|Rep-Count
> ======================================================================
> ==
> =============
> 17        400     0       0     0       2         0     -100    400
> 350      0
> 17        400     0       0     0       2         0     -40     225
> 525      0
> 
> 
> pktcSigDevToneTable:
> ToneType|ToneRep-Count|Steady
> =================================
>   17       5000        false(0)
> 
> 
> Please feel free to provide any comments.
> 
> Regards
> Sumanth
> 
> -----Original Message-----
> From: Sumanth Channabasappa
> Sent: Tuesday, August 09, 2005 2:37 PM
> To: 'ipcdn <at> ietf.org'
> Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; 
> conference call
> 
> Folks,
> 
> There has been a suggestion (from Phillip Freyman, Motorola) to move 
> the 'dBm level', currently under 'PktcSigDevToneTable' to 
> 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that 
> require this structure.
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn

------------------------------

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

End of IPCDN Digest, Vol 15, Issue 16
*************************************

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
Freyman Phillip-FPF300 | 2 Sep 2005 15:17

FW: IPCDN Digest, Vol 16, Issue 2

Eugene,

Thank you for reviewing the ETSI requirement.

I agree on your revised proposal for the range to be 20 ms to 1550 ms so that the SigMIB can cover international
requirements but with the default values set per Telcordia.

Regards,
Phillip Freyman

-----Original Message-----
From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of ipcdn-request <at> ietf.org
Sent: Thursday, September 01, 2005 11:17 PM
To: ipcdn <at> ietf.org
Subject: IPCDN Digest, Vol 16, Issue 2

Send IPCDN mailing list submissions to
	ipcdn <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ipcdn
or, via email, send a message with subject or body 'help' to
	ipcdn-request <at> ietf.org

You can reach the person managing the list at
	ipcdn-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of IPCDN digest..."

Today's Topics:

   1. RE: cable dev mib draft09 - WG consensus requested on pro
      posed changes (Nakanishi Greg-MGI8179)
   2. RE: FW: IPCDN Digest, Vol 15, Issue 16 (Eugene Nechamkin)

----------------------------------------------------------------------

Message: 1
Date: Thu, 1 Sep 2005 09:44:14 -0700 
From: Nakanishi Greg-MGI8179 <gnakanishi <at> motorola.com>
Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on
	pro	posed changes
To: Jean-Francois Mule <jf.mule <at> cablelabs.com>, ipcdn <at> ietf.org
Message-ID: <D5A7E45D575DD61180130002A5DB377C145AA158 <at> ca25exm01>
Content-Type: text/plain; charset="iso-8859-1"

I concur with the proposed resolution.

For Issue 4, my preference is that 'MUST NOT' be used, rather than 'SHOULD NOT'.  I think a device will run into
operational problems if it maintains these table entries across reboots.  When the device reboots, the
config log will attempt to create rows in these tables and will fail if the rows already exists.

greg

  _____  

From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of Jean-Francois Mule
Sent: Monday, August 15, 2005 3:20 PM
To: ipcdn <at> ietf.org
Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes

Folks,

   As you may have read in meeting notes from last week, we spent the IETF 63 meeting discussing the closure of
open issues on the CD mib v2.

   The meeting notes proposed some changes to get final (yes, final) closure on this mib.

Please review the text below and please speak up if you have some concerns (it's also welcome that you
express your agreement).

Thanks,

Jean-François

[extract from ipcdn minutes]

3.1/ DOCSIS Cable Device MIB version 2

     draft-ietf-ipcdn-device-mibv2-09.txt

     Editors: Kevin Marez & Rich Woundy

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt> 

We spent most of the meeting reviewing the 4 top remaining issues, see

summary sent by Rich and Kevin in:

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html> 

+ ISSUE #1: DEFVAL for docsDevNmAccessInterfaces

Raised by Randy, the issue is, in the defval we have a 4 octet value

=> How can systems with interfaces in a number not multiple

of 8 interpret the DEFVAL value. Are bits ignored?

Randy commented that he would be ok if there was some mention like

'octets containing bits corresponding to non-existent interfaces are

ignored.' That said, if there are implementations that would reject a

SET, then we need to say something about that.

Rich commented that the DEFVAL was added due to prior MIB doctor

comment and that the object is now deprecated. Bert asked whether

there was any concern deleting the DEFVAL.

Proposal for wg review:

 a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h }

 b) consider the following (NICE TO HAVE kind of fix)

    adding a sentence to say something like:

    bits set corresponding to non-existing interfaces is

    implementation specific (to warn the mgmt admin/apps that no

    assumptions should be made on existing implementations of this

    object. (Randy's suggestion)

+ ISSUE #2: docsDevNmAccessStatus

-- Also, we should change the DESCRIPTION of docsDevCpeStatus

-- and docsDevCpeInetRowStatus to document how the agent adds rows.

See issue raised by Randy and the email summary provided by Rich for

the context around this issue #2.

We had some discussions around the persistency of those tables, the

fact that the CM config file drives the row creation at boot-up and

the fact that they are read-create tables so admins can also create

entries as Bert pointed out.

In most cases (except for docsDevEvControlTable), entries do not

persist across CM reboots. Even in the case of docsDevEvControlTable,

after some discussion, we believe that the entries are cleared and

"recreated" after the CM reads the config file. That is the common

understanding.

Bert said: add a statement ("this is a deprecated table, this is

vendor specific as to what vendors do with this table, mgmt app cannot

expect a certain behavior").

+ ISSUE #3: docsDevEvReporting and local(0) rows

Comment close: ID authors agree with Randy's comment re: local(0) rows

MUST persist. Text will be revised.

in docsDevFilterLLCTable:

             Any attempt to SET the traps(1) or syslog(2) bits

             without setting the local(0) or localVolatile(8)

             bits MUST result in an error being generated.

Proposal:

   DELETE above text if nobody complains after reading the meeting

   notes

+ ISSUE #4: docsDevFilterLLCTable

Issue is around text for the level of requirements on table

persistence. Agree with Rich's text proposal:

  |"Table entries MUST NOT persist across reboots for cable modems."

Rich also proposed to apply this requirement to:

  NmAccess, FilterLLC, FilterIp, Policy, Tos,

  Cpe and InetCpe tables.

It was suggested to use SHOULD NOT rather than MUST NOT but other than

that, proposal is ok.

+ Other items on CD Device MIB:

Randy added for consideration:

wherever we have this "must not persist" langage in table definitions,

it would be a plus to indicate that they may come back as entries may

reappear when CM reboots and comes up with config file. Or consider

adding this in the front paper as a consideration for users of the

MIBs if that is too many little edits in the MIB objects.

Proposal:

  add a note on persistence model explaining the persistance of some

mib objects and the CM re-creating them upon config file reloading.

A comment was made that in general, we should indicate the persistency

model in each object rather than in the compliance section.

Bert also commented on the compliance sections: if different

requirements apply to CM and CMTS, suggestion is to make 2 different

compliances. Rich added that the new compliance statement is designed

like that.

# AI: [authors: Kevin Marez & Rich Woundy]

# Authors to summarize list of agreed changed and the technical

# changes in the text per wg consensus and issue new draft after AD

# review comments are in. 

# Due by early September?

# AD review by Bert due by August 15

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/ipcdn/attachments/20050901/711d24ed/attachment.htm

------------------------------

Message: 2
Date: Thu, 1 Sep 2005 21:00:36 -0700
From: "Eugene Nechamkin" <enechamkin <at> broadcom.com>
Subject: RE: [ipcdn] FW: IPCDN Digest, Vol 15, Issue 16
To: ipcdn <at> ietf.org
Message-ID:
	<24CDBA67F085904999751B3C4F9E8C0B031230FB <at> NT-RMNA-0740.brcm.ad.broadcom.com>
	
Content-Type: text/plain; charset=iso-8859-1

Phil,

I agree with your approach to modify two objects - Min and Max with the following comment:

ETSI EN 300 001 V1.5.1 spec defines the break period (which is an equivalent for flash) as being as low as 50ms
(Table 9.1.1). As a reality check - we have seen some European requests for having the flash range starting
from 50-100ms. Hence, I would think that the lower range of 20 msec for both objects would have a better
chance to meet the various requirements in the field. The following objects definitons seem to be
satisfactory from our
prospective:

pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1550) 
    .....
    DEFVAL (300)

pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1550) 
    .....
    DEFVAL (1100)

Eugene.

-----Original Message-----
From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of Freyman Phillip-FPF300
Sent: Thursday, September 01, 2005 7:14 AM
To: 'ipcdn <at> ietf.org'
Subject: [ipcdn] FW: IPCDN Digest, Vol 15, Issue 16

Eugene,

Thank you for reviewing the GR 506 document however, I do not fully agree with your proposal.

Per your email, GR 506 states:

Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds) SPCS Interpretation

< 200 Hit
200 to 300 Hit or Flash
300 to 1100 Flash
1100 to 1550 Flash or Disconnect
>1550 Disconnect

This implies that the network MUST accept 300 to 1100 milliseconds as hook flash and must NOT accept less
than 200 ms or more than 1550 ms.

The ranges of 200 to 300 and 1100 to 1550 are ranges where the network may accept or may reject the timing.

I do agree that some changes may be appropriate in the ranges of min/max values..

I do not agree with your proposed max default value and propose the following to bring the SigMIB into
alignment with GR 506.

Current rev8 text:

pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1000) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the minimum time a line needs to be on hook for a
          valid hook flash. The value of this object MUST be
          greater than the value of
          pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of
          pktcNcsEndPntConfigMinHookFlash MUST be less than
          pktcNcsEndPntConfigMaxHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process.
             Furthermore, given the possibility for the 'pulse dial' 
             and 'hook flash' to overlap, the value of this object MUST

             be greater than the value contained by the MIB Object 
             pktcNcsEndPntConfigPulseDialMaxMakeTime."
    DEFVAL { 300 } 
    ::= { pktcNcsEndPntConfigEntry 32 } 

pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (20..1000) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the maximum time a line needs to be on hook for a
          valid hook flash. The value of
          pktcNcsEndPntConfigMaxHookFlash MUST be greater than
          pktcNcsEndPntConfigMinHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process."
    DEFVAL { 800 } 
    ::= { pktcNcsEndPntConfigEntry 33 } 

Proposed rev8 text change:

pktcNcsEndPntConfigMinHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (200..1550) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the minimum time a line needs to be on hook for a
          valid hook flash. The value of this object MUST be
          greater than the value of
          pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of
          pktcNcsEndPntConfigMinHookFlash MUST be less than
          pktcNcsEndPntConfigMaxHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process.
             Furthermore, given the possibility for the 'pulse dial' 
             and 'hook flash' to overlap, the value of this object MUST

             be greater than the value contained by the MIB Object 
             pktcNcsEndPntConfigPulseDialMaxMakeTime."
    DEFVAL { 300 } 
    ::= { pktcNcsEndPntConfigEntry 32 } 

pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 
    SYNTAX       Unsigned32 (200..1500) 
    UNITS        "Milliseconds" 
    MAX-ACCESS   read-only 
    STATUS       current 
    DESCRIPTION 
        " This is the maximum time a line needs to be on hook for a
          valid hook flash. The value of
          pktcNcsEndPntConfigMaxHookFlash MUST be greater than
          pktcNcsEndPntConfigMinHookFlash. This object MUST only be
          set via the configuration file during the provisioning
          process."
    DEFVAL { 1100 } 
    ::= { pktcNcsEndPntConfigEntry 33 } 

Regards,
Phil
-----Original Message-----
From: ipcdn-bounces <at> ietf.org [mailto:ipcdn-bounces <at> ietf.org] On Behalf Of ipcdn-request <at> ietf.org
Sent: Wednesday, August 31, 2005 11:08 AM
To: ipcdn <at> ietf.org
Subject: IPCDN Digest, Vol 15, Issue 16

Send IPCDN mailing list submissions to
	ipcdn <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ipcdn
or, via email, send a message with subject or body 'help' to
	ipcdn-request <at> ietf.org

You can reach the person managing the list at
	ipcdn-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of IPCDN digest..."

Today's Topics:

   1. RE: draft-ipcdn-pktc-signaling-08, further	changes;result of
      conference call (Eugene Nechamkin)

----------------------------------------------------------------------

Message: 1
Date: Tue, 30 Aug 2005 18:44:56 -0700
From: "Eugene Nechamkin" <enechamkin <at> broadcom.com>
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further
	changes;result of conference call
To: "Sumanth Channabasappa" <sumanth <at> cablelabs.com>
Cc: ipcdn <at> ietf.org
Message-ID:
	
<24CDBA67F085904999751B3C4F9E8C0B031230A3 <at> NT-RMNA-0740.brcm.ad.broadcom.com>
	
Content-Type: text/plain; charset=iso-8859-1

Sumanth,

Looking further at the Bellcore specs for pulse flash requirements (GR-506-CORE "LSSGR: Signaling for
Analog Interfaces"), it turnes out that the requirements for the pulse range for flash are higher than it
is currently allowed by the "pktcNcsEndPntConfigMaxHookFlash" MIB Object. Bellcore specs say that
flash MUST be 300-1100, but may be up to 1550:

Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds) SPCS Interpretation

< 200 Hit
200 to 300 Hit or Flash
300 to 1100 Flash
1100 to 1550 Flash or Disconnect
>1550 Disconnect

To better meet the Bellcore specs requirements, the following modification of the MIB Object's range is proposed:

   pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE  
       SYNTAX       Unsigned32 (20..1550)  
       UNITS        "Milliseconds"  
       MAX-ACCESS   read-only  
       STATUS       current  
       DESCRIPTION  
           " This is the maximum time a line needs to be on hook for a 
             valid hook flash. The value of 
             pktcNcsEndPntConfigMaxHookFlash MUST be greater than 
             pktcNcsEndPntConfigMinHookFlash. This object MUST only be 
             set via the configuration file during the provisioning 
             process." 
       DEFVAL { 800 }  
       ::= { pktcNcsEndPntConfigEntry 33 }   

.

-----Original Message-----
From: Sumanth Channabasappa [mailto:sumanth <at> cablelabs.com]
Sent: Friday, August 26, 2005 7:24 AM
To: Jean-Francois Mule
Cc: ipcdn <at> ietf.org; Freyman Phillip-FPF300; Eugene Nechamkin; David De Reu; T, Shivakumar;
sercu <at> tComLabs.com; Satish Kumar at Texas Instruments; Beacham Gordon-CGB005
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of conference call

Jean-Francois,

I concur. Unless there are objections, I will be presenting the final proposal to this group in the next week.

Regards
Sumanth 

-----Original Message-----
From: Jean-Francois Mule
Sent: Friday, August 26, 2005 7:18 AM
To: Sumanth Channabasappa
Cc: ipcdn <at> ietf.org; 'Freyman Phillip-FPF300'; 'Eugene Nechamkin'; 'David De Reu'; 'T, Shivakumar';
'sercu <at> tComLabs.com'; Satish Kumar at Texas Instruments; 'Beacham Gordon-CGB005'
Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of conference call

Sumanth,

   Thanks for inviting anyone from IETF ipcdn to attend the discussion and for the notes.

   We have not seen one comment on your posting in 15 days so the proposal should be good enough. Per the IETF#63
meeting, the action item on the signaling MIB was: # AI: authors to close one open issue on tone table by
August 20. # Ask Randy to review final proposal.

  Can you put out the proposed changes in the form of updated object definitions to the list so we can see all the
aggregated changes?

  Based on our discussions, we are getting close to the end on this one and I would like to set the date of next
Friday, September 2nd to have a consensus on the technical changes to allow a draft09 publication by
mid-September at the latest.

Thanks,
Jean-François

> -----Original Message-----
> From: Sumanth Channabasappa
> Sent: Wednesday, August 10, 2005 10:09 AM
> To: ipcdn <at> ietf.org
> Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result
> of conference call
> 
> Folks,
> 
> As per the discussion on the conference call today (thanks to the
> attendees), the proposal from Phil seems to be reasonable.
> 
> Further, there was a suggestion to include the following examples in
> the draft for clarity and ease of implementation. Note: Example B was 
> also the cause for the latest suggestion.
> 
> 
> Example A:  Call waiting tone defined per ITU-T E.180:
> 1)	400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm
> 2)	400 Hz AM modulated by 16 Hz, off for 400ms
> 3)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 4)	400 Hz not AM modulated, off for 450 ms
> 5)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 6)	400 Hz not AM modulated, off for 3450 ms
> 7)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 8)	400 Hz not AM modulated, off for 450 ms
> 9)	400 Hz not AM modulated, on for 50 ms at -4 dBm
> 10)	400 Hz not AM modulated, off for 3450 ms
> 11)	not repeated, not continuous
> 
> Assume userDefined1(17) is assigned to this tone:
> 
> ToneType|Freq-1|Freq-2|Freq-3|Freq-
> 4|FreqMode|ModePrtg|DbLevel|OnDur|Off
> Dur|Rep-Count
> ======================================================================
> ==
> =============
> 17       400     16       0       0     1        90      -40    500
> 400    0
> 17       400      0       0       0     2         0      -40     50
> 450    0
> 17       400      0       0       0     2         0      -40     50
> 3450    0
> 17       400      0       0       0     2         0      -40     50
> 450    0
> 17       400      0       0       0     2         0      -40     50
> 3450    0
> 
> 
> pktcSigDevToneTable:
> ToneType|ToneRep-Count|Steady
> ================================
>   17         0         false(2)
> 
> 
> ----------------------------------------------------------------------
> --
> ---------------
> 
> Example B - Congestion Tone - congestion(17):
> 
> This example of an embedded cadence is based on an operator variation.
> 1) 400Hz on for 400ms -10 dBm
> 2) 400Hz off for 350ms
> 3) 400Hz on for 225ms -4 dBm
> 4) 400Hz off for 525ms
> 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is
> shortest period)
> 
> ToneType|Freq-1|Freq-2|Freq-3|Freq-
> 4|FreqMode|ModePrtg|DbLevel|OnDur|Off
> Dur|Rep-Count
> ======================================================================
> ==
> =============
> 17        400     0       0     0       2         0     -100    400
> 350      0
> 17        400     0       0     0       2         0     -40     225
> 525      0
> 
> 
> pktcSigDevToneTable:
> ToneType|ToneRep-Count|Steady
> =================================
>   17       5000        false(0)
> 
> 
> Please feel free to provide any comments.
> 
> Regards
> Sumanth
> 
> -----Original Message-----
> From: Sumanth Channabasappa
> Sent: Tuesday, August 09, 2005 2:37 PM
> To: 'ipcdn <at> ietf.org'
> Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;
> conference call
> 
> Folks,
> 
> There has been a suggestion (from Phillip Freyman, Motorola) to move
> the 'dBm level', currently under 'PktcSigDevToneTable' to 
> 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that 
> require this structure.
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn

------------------------------

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

End of IPCDN Digest, Vol 15, Issue 16
*************************************

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

------------------------------

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

End of IPCDN Digest, Vol 16, Issue 2
************************************
Wijnen, Bert (Bert | 2 Sep 2005 17:39
Picon
Favicon

RE: Late Agenda item: recharter of IPCDN WG

Updated charter was approved by IESG yesterday.

Formal announcment and web-page updates will occur
somewhere next week I suspect.

Bert
> -------------------
> Revised IPCDN WG Charter (date 26 Aug 2005)
> 
> Chair(s):
>    Richard Woundy <Richard_Woundy <at> cable.comcast.com>
>    Jean-Francois Mule <jf.mule <at> cablelabs.com>
> 
> Operations and Management Area Director(s):
>    Bert Wijnen <bwijnen <at> lucent.com>
>    David Kessens <david.kessens <at> nokia.com>
> 
> Operations and Management Area Advisor:
>    Bert Wijnen <bwijnen <at> lucent.com>
> 
> Mailing Lists:
>    General Discussion: ipcdn <at> ietf.org
>    To Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
>    Archive: http://www.ietf.org/mail-archive/web/ipcdn/index.html
> 
> 
> Description of Working Group:
> The IETF IPCDN Working Group develops and standardizes MIBs
> for IP-capable data-over-cable systems, for example cable
> modems, multimedia terminal adapters and associated
> cable-data equipment in a cable headend.
> These MIBs cover not only cable data interfaces, but also
> management of cable-data equipment and systems.
> 
> The WG mailing list may be used to discuss Internet-related
> issues in data-over-cable equipment and systems. In the event
> of a particular new Internet technology issue arising in the
> cable-data context, the WG will identify whether that is best
> handled within the IETF or is best handled by another standards
> body. In the event that new IETF MIB work is requested, the WG 
> chairs can discuss additional WG work items with the AD. Such
> additions will have to go through normal re-charter process.
> If non-MIB work gets identified, such items are not normal
> work items for this IPCDN-MIB WG and must go through normal
> IETF new WG chartering process.
> 
> Standardization of MIBs for DOCSIS and PacketCable systems are
> explicitly within the scope of the IPCDN Working Group.
> 
> The IPCDN WG will also keep informed on what other groups in
> the industry are doing as it relates to the efforts of this
> working group.
> 
> The WG will align its specifications with IPv6 and SNMP Standards.
> 
> Related groups:
> 
> CableLabs (http://www.cablelabs.com/) is structured into projects.
> In its Cable Modem DOCSIS project, CableLabs has produced three
> generations of data over cable specifications: DOCSIS 1.0,
> DOCSIS 1.1, and DOCSIS 2.0.
> In its PacketCable project, CableLabs has produced one generation
> of interface specifications for delivering real-time multimedia
> services over DOCSIS (http://www.packetcable.com/specifications/).
> Internationally, IPCablecom is the global name associated
> with the extensions & global standardization of PacketCable
> in ETSI & ITU-T SG9.
> 
> DOCSIS 1.0 includes specifications for a bidirectional
> data-over-cable interface (RFI, or Radio Frequency Interface)
> and a data privacy service (BPI, or Baseline Privacy Interface).
> The key devices in a DOCSIS network are the Cable Modem (CM, the
> device at the subscriber premise) and the Cable Modem Termination
> System (CMTS, the device at the cable headend). For DOCSIS 1.0
> systems, the IPCDN WG has published the Cable Device MIB
> (RFC 2669), the RF Interface MIB (RFC 2670), and the Baseline
> Privacy MIB (RFC 3083). 
> 
> DOCSIS 1.1 extends the DOCSIS 1.0 specifications to support
> better quality of service parameters (RFIv1.1), to enable
> operation in European cable networks (EuroDOCSIS), and to
> authenticate modems and firmware images (BPI+). The IPCDN WG
> will update the Cable Device and Radio Frequency MIBs for
> DOCSIS 1.1, and repair flaws discovered in operational use.
> Other IPCDN WG documents will address the operational and
> management issues for new DOCSIS 1.1 functional components
> (e.g. BPI+), for subscriber device management, and for
> uniform event notification. The IPCDN WG has also published the DOCSIS
> Subscriber Management MIB (RFC4036) for DOCSIS 1.1 and 2.0
> systems.
> 
> DOCSIS 2.0 enhances the DOCSIS 1.1 specifications at the
> physical layer, in particular to support two new physical
> layer encodings: S-CDMA and A-TDMA. The IPCDN WG will update
> the Radio Frequency MIB for DOCSIS 2.0.
> 
> PacketCable 1.0 is built on top of the DOCSIS 1.1 cable modem
> infrastructure and it includes a suite of interface
> specifications covering multimedia terminal adapter (MTA)
> device provisioning, voice over IP session signaling, QoS
> signaling based on IETF standards. The key systems in a
> PacketCable network are the multimedia terminal adapter (MTA),
> a Call Management Server (CMS), a PacketCable-compliant
> DOCSIS 1.1 CMTS, Media Gateway Controllers, Media Gateways
> along with back-office systems. In ITU-T SG-9 and ETSI AT,
> IPCableCom has standardized PacketCable to create a set of
> international standards.
> 
> 
> Work items:
> 
> The IPCDN WG will address issues related to network management,
> especially as they concern HFC access networks. It is expected
> that other services (i.e. RSVP, IPSEC, etc.) will operate
> mostly unmodified.
> 
> The specific work items include
> 
> -- DOCSIS,
>         - publish MIB documents for:
>             - subscriber device management on a DOCSIS 1.1 CMTS,
>             - managing the quality of service parameters for a
>                 DOCSIS 1.1 device,
>             - managing the Baseline Privacy Plus system for a
>                 DOCSIS 1.1 device,
>             - uniform event notification on a DOCSIS 1.1 device,
>         - revise MIB documents for:
>             - DOCSIS 1.0 RF Interface MIB to support EuroDOCSIS
>                   parameters and DOCSIS 2.0 physical layer management,
>             - the DOCSIS 1.0 Cable Device MIBs to address SNMPv3
>                   and IPv6 compliance and interoperability issues,
> 
>   -- IPCablecom & PacketCable
>         - publish MIB documents for:
>             - managing the device parameters of
>                 PacketCable/IPCableCom MTA devices,
>             - managing the signaling parameters of
>                 PacketCable/IPCableCom MTA devices,
>             - managing events for PacketCable/IPCablecom systems,
> 
> 
> Goals and Milestones:
> 
> Done	Post final I-D on Baseline Privacy MIB; Last call
> Done	Post I-Ds revising RF and CM MIBs to support DOCSIS1.1 
> and for compliance with SNMPv3 and IPv6
> Done    Submit Baseline Privacy MIB to IESG for publication 
> as a Standards Track RFC
> Done	Submit DOCSIS Subscriber Management MIB to IESG for
>         consideration as a Standards Track RFC
> Done	Submit DOCSIS 1.1 QoS MIB to IESG for consideration as a
>         Standards Track RFC
> Done	Submit DOCSIS BPI+ MIB to IESG for consideration as a Standards
>         Track RFC
> Done	Submit DOCSIS Event Notification MIB to IESG for consideration
>         as a Standards Track RFC
> 
> Oct 05	Submit updated DOCSIS RF MIB to IESG for 
> consideration as a
>         Standards Track RFC (Proposed Standard)
> Oct 05	Submit updated DOCSIS Cable Device MIB to IESG 
> for consideration
>         as a Standards Track RFC
> 
> Oct 05  Submit PacketCable/IPCableCom MTA device MIB to IESG for 
>         consideration as a Standards Track RFC
> 	
> Oct 05  Submit PacketCable/IPCableCom MTA signaling MIB to IESG for 
>         consideration as a Standards Track RFC
> 
> Dec 05  Submit PacketCable/IPCableCom MTA event MIB to IESG for 
>         consideration as a Standards Track RFC
> 
> Jan 06	Re-evaluate charter and milestones or conclude wg.
> 
Jean-Francois Mule | 5 Sep 2005 15:51
Favicon

RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

Bert, and all,

 

   Thanks again for the AD review of the IPCDN MTA MIB module. Eugene

and I got together to review and address them. Find below our

responses along with our proposed resolutions.

 

  We would appreciate receiving quick input from you and the wg on the

proposed changes for draft 07, and in particular, for Comments #:

  12, 13, 14, 15, 19, 20, 21, 22, 23, 28, 29, 30, 31, 32, and 38.

 

   Let us know what you think, pending your ack and wg consensus, we

will update the Internet-Draft by mid September.

 

Thanks,

Eugene and Jean-Francois.

 

---

--- Summary of responses to AD comments on

---            draft-ietf-ipcdn-pktc-mtamib-06.txt

---

 

Bert wrote:

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01693.html

 

# Comment 1

> - $ idnits draft-ietf-ipcdn-pktc-mtamib-06.txt

>   idnits 1.74

>

>   draft-ietf-ipcdn-pktc-mtamib-06.txt:

>

>   Checking nits according to http://www.ietf.org/ID-Checklist.html:

>     Checking conformance with RFC 3978/3979 boilerplate...

>   * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure

>     Acknowledgement.

>     (The document uses RFC 3667 boilerplate or RFC 3978-like

>     boilerplate instead of verbatim RFC 3978 boilerplate.  After 6 May

> 2005,

>     submission of drafts without verbatim RFC 3978 boilerplate is not

>     accepted.)

>

>   So if you do a new revision, pls make sure you take care of above.

>   If you use xml2rfc, then it is taken care of automagically by the

>   latest version (I think)

ok, fixed.

Will run the latest idnits tool before submission, just like we did

for draft06 (the boilerplate was updated since draft06 submission).

 

 

# Comment 2

> - References:

>

>    !! Contains embedded space:

>    P050 L006:    [ETSI TS 101 909-8] ETSI TS 101 909-8: "Access and

> Terminals (AT);

>

>    !! Contains embedded space:

>    P050 L014:    [EN 300 001] EN 300 001 V1.5.1 (1998-10):"European

> Standard

>

>    !! Contains embedded space:

>    P050 L022:    [EN 300 659-1] EN 300 659-1: "Public Switched

> Telephone Network

>

>    !! Contains embedded space:

>    P005 L029:      - the ETSI MTA MIB [ETSI TS 101 909-8]. The ETSI

> MTA MIB

>

>    !! Contains embedded space:

>    P005 L031:        defined in [EN 300 001] and [EN 300 659-1].

>

>    !! Contains embedded space:

>    P005 L031:        defined in [EN 300 001] and [EN 300 659-1].

>

>   Not sure if sapces in citations are really forbidden.

>   But I know the RFC-Editor checking tool has trouble with it.

ok - fixed, removed white spaces.

 

 

# Comment 3

>     !! Missing Reference for citation: [RFC2119]

>     P003 L011:    interpreted as described in RFC 2119 [RFC2119].

ok fixed, added reference.

 

 

# Comment 4

>     !! Missing citation for Normative reference:

>     P047 L040:    [RFC2863] McCloghrie, K., Kastenholz, F., "The

> Interfaces Group

ok, the reference is mostly because of the IMPORT of the IF-MIB.

Proposed resolution: reference to [RFC2863] is introduced. We propose

to add the following text in section 3:

   EMTA devices implementing this MIB Module MUST be compliant with

   RFC 2863 [RFC2863] and the Packetcable MTA Device Provisioning

   Specification [PKT-SP-PROV].

(we're also proposing to also add the existing normative reference to

the MTA device provisioning spec here).

 

 

# Comment 5

>     !! Missing citation for Informative reference:

>     P049 L042:    [RFC3410] Case, J., Mundy, R., Partain, D. and B.

> Stewart,

   [RFC3410] - the citation is not missing, it is present in the text.

               See: section 1, end of 1st sentence.

               No action taken.

 

 

# Comment 6

>     !! Missing citation for Normative reference:

>     P047 L043:    [RFC3411] Harrington, D., Presuhn, R., and Wijnen,

> B., "An

ok. This normative reference is required because of the IMPORTs.

Proposed resolution: add RFC citations as comments in the MIB module

definition as follows:

IMPORTS

    MODULE-IDENTITY,

    OBJECT-TYPE,

    OBJECT-IDENTITY,

    Unsigned32,

    Counter32,

    NOTIFICATION-TYPE,

    mib-2

          FROM SNMPv2-SMI                    -- [RFC2578]

    RowStatus,

    TruthValue

          FROM SNMPv2-TC                     -- [RFC2579]

    OBJECT-GROUP,

    MODULE-COMPLIANCE,

    NOTIFICATION-GROUP

          FROM SNMPv2-CONF                   -- [RFC2580]

    InetAddressType,

    InetAddress

          FROM INET-ADDRESS-MIB              -- [RFC4001]

    sysDescr

          FROM SNMPv2-MIB                    -- [RFC3418]

    SnmpAdminString

          FROM SNMP-FRAMEWORK-MIB            -- [RFC3411]

    docsDevSoftwareGroupV2

          FROM DOCS-CABLE-DEVICE-MIB         -- [RFCxxxx]

    -- ************************************************************

    -- * NOTES TO RFC Editor (to be removed prior to publication) *

    -- *                                                          *

    -- *     The I-D <draft-ietf-ipcdn-device-mibv2-10.txt>       *

    -- * is expected to become RFC before this draft.             *

    -- * Please replace RFCxxxx with the RFC number of the IPCDN  *

    -- * Cable Device MIBv2 and remove this note                  *

    -- *                                                          *

    -- ************************************************************

 

    DocsX509ASN1DEREncodedCertificate,

    docsBpi2CodeDownloadGroup

          FROM DOCS-IETF-BPI2-MIB            -- [RFC4131]

 

    ifPhysAddress

          FROM IF-MIB;                       -- [RFC2863]

 

 

# Comment 7

>     !! Missing Reference for citation: [RFC3495]

>     P004 L025:    Configuration DHCP specifications, RFC 3495

> [RFC3495] and RFC 3594

   RFC3495 - Reference is not missing it's present in the Normative References.

               No action taken.

 

 

# Comment 8

>    !! Missing Reference for citation: [RFC3594]

>    P004 L026:    [RFC3594].

>    P048 L027:    [RFC3594] P. Duffy, "PacketCable Security Ticket

> Control Sub-Option

  RFC3594 - Reference is not missing it's present in the Normative References.

               No action taken.

 

 

# Comment 9

>    !! Missing Reference for citation: [RFC3617]

>    P048 L031:    [RFC3617] E. Lear, "Uniform Resource Identifier (URI)

> Scheme and

   RFC3617 - Reference is not missing it's present in the Normative References.

               No action taken.

 

 

# Comment 10

>    !! Missing Reference for citation: [RFCxxxx]

>    P009 L016:    module (DOCS-CABLE-DEVICE-MIB [RFCxxxx]).

   RFCxxxx - Reference is not missing it's present in the Normative References.

               No action taken.

 

 

# Comment 11

>   My tool may have gotten a bit confused in that it is seeing the

>   refernce

>   as a citation instead of the oterhway around. In that case there is

>   no citation. Pls check carefully

yep, will do another check once we run idnits.

We also plan to update some of the PacketCable references:

   - Updated reference to PacketCable MTA MIB Specification

   - Updated reference to PacketCable Provisioning Specification

   - Updated reference to PacketCable Security Specification

 

 

# Comment 12

> - what is the persistency behaviour of the various read-write objects?

>     pktcMtaDevEnabled

>     ... etc ..

ok.

Proposed resolution and text:

Out of all the read-write objects, none of the values set in those

objects should persist, except for pktcMtaDevResetKrbTickets.

 

a) We propose to add the following text for non-persistant values:

=> for e.g., for pktcMtaDevResetNow, add:

          If a value is written into an instance of

          pktcMtaDevResetNow, the agent must not retain the supplied

          value across MTA re-initializations or reboots."

Similar text for pktcMtaDevEnabled, pktcMtaDevProvisioningTimer,

pktcMtaDevServerDns1, pktcMtaDevServerDns2, pktcMtaDevTimeServer,

pktcMtaDevConfigFile, pktcMtaDevProvConfigHash,

pktcMtaDevProvConfigKey.

b) Add text indicating persistence of object value only for

pktcMtaDevResetKrbTickets:

          If a value is written into an instance of

          pktcMtaDevResetKrbTickets, the agent MUST retain the

          supplied value across an MTA re-initialization or

          reboot.

 

 

# Comment 13

> - For pktcMtaDevEnabled a better name woul probably be

>       pktcMtaDevAdministrativelyEnabled

>   And how is the NMS going to see what the real Operational status is?

>   Is a AdminStatus and OperStatus (as in IF-MIB) not more appropriate?

Proposed resolution: no action

In general, we agree with the comment and our first reaction was, yes,

let's rename it and add an operStatus one.

But after looking at its definition in more details, syntax

(ThruthValue) and after considering a new operStatus object, we think

that:

        - pktcMtaDevEnabled is both an admin and operational status

          object, hence the name is probably ok,

        - it returns the operational status of the enable/disable

          switch when read.

Our proposal, after reviewing your comment is still to leave it as-is.

Is this ok? if not, can you elaborate?

 

 

# Comment 14

> - For

>     pktcMtaDevTypeIdentifier     OBJECT-TYPE

>        SYNTAX      SnmpAdminString

>   I see that it is an identifier as per DHCP option 60 (RFC2132.

>   There it is specified as a "string of octets". How are we sure that

>   such a "string of octets" is a valid SnmpAdminString?

Proposed resolution: no action

We traced this assurance to a requirement in the PacketCable MTA

Device Provisioning spec (see normative ref in the draft):

Section 8.2 says:

8.2 DHCP Option 60: Vendor Client Identifier

"Option code 60 contains a string identifying Capabilities of the MTA.

The MTA- MUST send the following ASCII Coded String in DHCP Option

----->                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

code 60: "pktc1.5:xxxxxx". Where xxxxxx MUST be an ASCII

representation of the hexadecimal encoding of the MTA TLV Encoded

Capabilities, as defined in Section 10."

No action required, leave as-is.

 

 

# Comment 15

>   There are other such objects too I think

> pktcMtaDevSerialNumber

> pktcMtaDevSwCurrentVers

> etc.

Right. Below is the list of objects with some analysis to justify the

object syntax.

 

pktcMtaDevSerialNumber

  object value == DHCP option 43 sub-option 4 value.

  see the PKT-SP-PROV spec, section 8.5, it says:

  "The sub-option 4 contains the device serial number represented as

   an ASCII string."

Proposal: No action required, leave as-is.

 

pktcMtaDevSwCurrentVers

  object value == DHCP option 43 sub-option 6 value.

  see the PKT-SP-PROV spec, section 8.5, it says:

  "The sub-option 6 contains the software version

   number represented as an ASCII string."

Proposal: No action required, leave as-is.

 

pktcMtaDevSnmpEntity

  object value == DHCP option 122 sub-option 3 value [RFC 3495]

                  in the form of an FQDN

  SnmpAdminString is therefore ok.

Proposal: No action required, leave as-is.

 

pktcMtaDevProvKerbRealmName

  object value == DHCP option 122 sub-option 6 value [RFC 3495]

                  ==> GeneralStrings encoded per RFC1510

  The Packetcable Security Specification adds a requirement for those

  names to be all UPPERCASE (note that this is consistent with RFC4120

  section 6.1, quote:

   "When establishing a new realm name based on an internet domain

   name it is recommended by convention that the characters be converted

   to uppercase.")

 

In addition, as noted below, the Kerberos protocol (RFC1510, RFC4120)

defines the RealmName to be of ASN.1 type "GeneralString". This type

has numerous interop problems (RFC4120, section 5.2.1).

The newer version of Kerberos protocol (RFC4120) requires that the

RealmName follows a new type "KerberosString" which effectively

constrains the value of the GeneralString to only contain characters

in IA5String.

     KerberosString  ::= GeneralString (IA5String)

The "IA5String" type is defined in ISO/IEC646:1991 and also known

as US-ASCII.

Hence, based on the above analysis, "DisplayString" and

"SnmpAdminString" seem to be the closest mapping in SMI. The

co-authors are shared on whether to change the current SYNTAX from

SnmpAdminstring to DisplayString. Any input on this?

There are a couple of other objects related to DHCP but they are not

strings.

 

 

# Comment 16

> - Where are the suboptions of DHCP option 43 defined?

in PKT-SP-PROV a normative reference in the MTA MIB ID

http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I11-050812.pdf

section 8.5

 

 

# Comment 17

>   are they all valid SnmpAdminStrings as you seem to assume for

>   several of them?

based on the above analysis, I think our use is legitime, if not,

please let us know.

 

 

# Comment 18

>   A REFERENCE clause migth help too.

Yes, agree.

Proposed text:

    REFERENCE

        " PacketCable MTA Device Provisioning Specification."

in the 2 objects referencing DHCP option 43.

 

 

# Comment 19

> - You have pktcMtaDevServerAddressType and then follow some 5

>   objects of InetAddress SYNTAX. The latter 5 objects MUST specify

>   which object of SYNTAX InetAddressType controls their format.

This is already the case in draft06. We don't understand the comment.

For eg, pktcMtaDevServerDhcp1 states:

          The type of this address is determined by the value of

          the pktcMtaDevServerAddressType object.

same for pktcMtaDevServerDhcp2, pktcMtaDevServerDns1,

pktcMtaDevServerDns2, and pktcMtaDevTimeServer.

 

 

# Comment 20

>   I also wonder if in the future all these servers need to be

>   of the same InetAddressType, and so I wonder if it is wise

>   to use just one object to identify the format of the 5

>   different server addresses.

Good point.

Proposed resolution:

   Define 3 Internet Address types:

        one for 2 DHCP server objects

        one for 2 DNS server objects

        1 for Time Server object.

 

 

# Comment 21

> - Mmm do we expect we can get away with pktcMtaDevProvConfigKey

>   once the Security ADs take a look?

Proposed Resolution:

  - change the syntax of pktcMtaDevProvConfigKey to be 32 octets (256)

    or may be more

  - add a new object named pktcMtaDevProvConfigEncryptAlg to specify

    the encryption algorithm

                           none(0),

                           des64CbcMode(1),

                           t3Des128CbcMode(2),

                           aes128CbcMode(3),

                           aes256CbcMode(4)

  - add DEFVAL des64CbcMode

  - add a compliance statement to only require des64CbcMode for

    compliant PacketCable 1.0 implementations.

The above proposal is inline with the Security AD comments on the BPI+

encryption algorithms and ok with us.

 

 

# Comment 22

> - The comment lines on page 26 probably better go into some

>   object DESCRIPTION clause, no?

OK they have been in the draft for a long time.

But where do we put it? should we just paste it in one or all of the 3

relevant objects (pktcMtaDevProvUnsolicitedKeyMaxTimeout,

pktcMtaDevProvUnsolicitedKeyNomTimeout,

pktcMtaDevProvUnsolicitedKeyMaxRetries)

We can also put it in section 3.3 and/or in the mib objects. if so, in

which one do we duplicate the same text in all the 3 objects?

Please let us know your preference.

 

 

# Comment 23

> - pktcMtaDevRealmOrgName

>   Is this really an SnmpAdminString of max size 64?

We confirmed the 2 points:

per RFC2459:

   - Organization Name MUST be of "UTF8String" (for all certs after

     Dec 31, 2003).

   - upper boundery is 64 for Organization name.

CONCLUSION: "SnmpAdminString" type is the closest mapping to "UTF8String"

                Hence, leave the SYNTAX "as is" - SnmpAdminString.

Proposed resolution no action required, leave as-is.

 

 

# Comment 24

> - Page 44

>            OBJECT  pktcMtaDevServerAddressType

>                SYNTAX      InetAddressType

>                DESCRIPTION

>                    " Support for address types other than 'ipv4(1)'

>                      is not presently specified and therefore, is not

>                      required. It may be defined in future versions of

>                      this MIB module."

>   In order to say so in machine readable form, yopu do:

>            OBJECT  pktcMtaDevServerAddressType

>                SYNTAX      InetAddressType { ipv4(1) }

>                DESCRIPTION

>                    " Support for address types other than 'ipv4(1)'

>                      is not presently specified and therefore, is not

>                      required. It may be defined in future versions of

>                      this MIB module."

ok, will be reflected in all applicable objects.

 

 

# Comment 25

>   You then also add the InetAddress objects with alength of 4.

>   You have done this in other MIB modules, so you should know I think.

ok, will be reflected in all applicable objects. will check thorougly.

 

 

# Comment 26

>   and is a similar refinement for pktcMtaBasicSmtaCompliance also not

>   needed/wanted?

ok, agree. Will be addressed.

 

 

# Comment 27

> - Refrence RFC3291 can now be repalced by RFC4001

ok, fixed.

 

 

# Comment 28

> I suspect we need another serious and close review.

We as co-authors would really like to understand the next steps in

more details. This draft has passed WGLC, has had at least 2 if not 3

MIB doctor reviews and now your complete review.

 

> I do not have all the details of Kerberos, DHCP and all such in

> my head that I could quickly ensure they are all correct.

  based on the above, we think we have addressed the concerns, if not,

let us know.

 

> Did the WG have any DHCP or Kerberos (or Security people) do

> an early review for this doc?

I think we have justified the DHCP questions. I (Jean-Francois) can

certainly asked Ralph Droms for cross-review. As for the security, per

the fixes of BPI+, let us know if this is not good enough.

 

 

>

> Bert

Thanks again for all the comments

 

# Comment 29

> - object pktcMtaDevProvUnsolicitedKeyMaxTimeout

>   is a read-only object and has text in the DESCRIPTION clause about

>              If this object is set to a zero value, the MTA MUST return

>              an 'inconsistentValue' in response to SNMP SET operations.

>   That seems conflicting, no?

Proposed resolution:

delete       If this object is set to a zero value, the MTA MUST return

             an 'inconsistentValue' in response to SNMP SET operations.

 

# Comment 30

> - Same for pktcMtaDevProvUnsolicitedKeyNomTimeout

Proposed resolution:

delete       If this object is set to a zero value, the MTA MUST return

             an 'inconsistentValue' in response to SNMP SET operations.

 

# Comment 31

> - I wonder if for an object like pktcMtaDevProvKerbRealmName

>   it is wise to use SnmpAdminString while the content MUST be

>   uppercase ASCII ??

Proposed resolution:

The Kerberos protocol (RFC1510, RFC4120) defines the RealmName to be

of ASN.1 type "GeneralString". This type has numerous interop problems

(RFC4120, section 5.2.1).

The newer version of Kerberos protocol (RFC4120) requires that the

RealmName follows a new type "KerberosString" which effectively

constrains the value of the GeneralString to only contain characters

in IA5String.

     KerberosString  ::= GeneralString (IA5String)

The "IA5String" type is defined in ISO/IEC646:1991 and also known

as US-ASCII.

Hence, based on the above analysis, "DisplayString" and

"SnmpAdminString" seem to be the closest mapping in SMI. The

co-authors are shared on whether to change the current SYNTAX from

SnmpAdminstring to DisplayString. Any input on this?

 

 

# Comment 32

> - Same for pktcMtaDevRealmName

Proposed resolution:

       see above, 2 options:

        change to DisplayString or leave as-is,

        keep SnmpAdminstring

 

 

# Comment 33

> - Why is

>    pktcMtaDevRealmAvailSlot   OBJECT-TYPE

>        SYNTAX      Unsigned32 (0..64)

>

>   While

>    pktcMtaDevRealmIndex  OBJECT-TYPE

>        SYNTAX      Unsigned32 (1..32)

>

>   Should they not be both limited to 64 or 32 (i.e. same value) ??

Agree.

Proposed resolution:

  change pktcMtaDevRealmIndex's SYNTAX to

       SYNTAX      Unsigned32 (1..64)

 

# Comment 34

> - Same for

>    pktcMtaDevCmsAvailSlot   OBJECT-TYPE

>        SYNTAX      Unsigned32 (0..128)

>   and

>    pktcMtaDevCmsIndex  OBJECT-TYPE

>        SYNTAX      Unsigned32 (1..64)

Proposed resolution:

  change pktcMtaDevCmsIndex's SYNTAX to

       SYNTAX       Unsigned32 (1..128)

 

 

# Comment 35

> - I wonder why:

>

>    pktcMtaNotificationPrefix OBJECT IDENTIFIER ::= { pktcMtaMib 2 }

>    pktcMtaNotification OBJECT IDENTIFIER ::= {

>    pktcMtaNotificationPrefix 0 }

>

>   is not specified as:

>

>    pktcMtaNotifications OBJECT IDENTIFIER ::= { pktcMtaMib 0 }

>

>   as suggested in the mib-review-guideleines.

>   It is not forbidden. I just wonder

Proposed resolution:

  change text to follow mib design guidelines as follows:

   pktcMtaNotifications OBJECT IDENTIFIER ::= { pktcMtaMib 0 }

 

 

# Comment 36

> - I wonder why

>    pktcMtaBasicCompliance MODULE-COMPLIANCE

>

>        STATUS      current

>        DESCRIPTION

>            " The compliance statement for MTA devices that implement

>              PacketCable or IPCablecom requirements.

>

>              This compliance statement applies to MTA implementations

>              that support PacketCable 1.0 or IPCablecom requirements,

>              which are not IPv6-capable at the time of this

>              RFC publication."

>

>        MODULE  -- Unconditionally mandatory groups for MTAs

>

>            MANDATORY-GROUPS {

>                pktcMtaGroup,

>                pktcMtaNotificationGroup

>            }

>

>            OBJECT  pktcMtaDevServerAddressType

>                SYNTAX      InetAddressType

>                DESCRIPTION

>                    " Support for address types other than 'ipv4(1)'

>                      is not presently specified and therefore, is not

>                      required. It may be defined in future versions of

>                      this MIB module."

>        ::= { pktcMtaCompliances 1 }

>

>   Does not have the following:

>

>            MANDATORY-GROUPS {

>                pktcMtaGroup,

>                pktcMtaNotificationGroup

>            }

>

>            OBJECT  pktcMtaDevServerAddressType

>                SYNTAX      InetAddressType { ipv4(1) }

>                DESCRIPTION

>                    " Support for address types other than 'ipv4(1)'

>                      is not presently specified and therefore, is not

>                      required. It may be defined in future versions of

>                      this MIB module."

>            OBJECT pktcMtaDevServerDhcp1

>                SYNTAX     InetAddress SIZE (4)

>                SESCRIPTION

>                    " Support for address formats other than 'ipv4(1)'

>                      is not presently specified and therefore, is not

>                      required. It may be defined in future versions of

>                      this MIB module."

>

>            .... and similar swtuff for the other InetAddress objects

>

>        ::= { pktcMtaCompliances 1 }

Agree. will be changed accordingly.

 

 

# Comment 37

> - Same for the pktcMtaBasicSmtaCompliance spec.

Agree. will be changed accordingly.

 

 

# Comment 38

> - At various places in your MIB module you have FQDNs present.

>   I wonder if it would not be wise (for interoperability) to

>   specify WHEN such FQDNs are supposed to be resolved to IP addresses.

Agree.

Proposed new text:

  for pktcMtaDevFQDN:

          The MTA FQDN is used to uniquely identify the

          device to the PacketCable back office elements.

  (on this one, the MTA does not resolve it, just uses it).

 

pktcMtaDevSnmpEntity

          The MTA must resolve

          the FQDN value before its very first network interaction

          with the SNMP entity during the provisioning phase.

 

pktcMtaDevCmsFqdn

           The MTA must resolve the CMS FQDN as required

           by the corresponding PacketCable Specifications."

    REFERENCE

        " PacketCable MTA Device Provisioning Specification;

          PacketCable Security Specification;

          PacketCable Network-Based Call Signaling Protocol

          Specification."

 

 

# Comment 39

--- Other comments on MTA MIB draft06

Bert wrote:

> I also see that various comments/questions were posted to the

> IPCDN WG mailing list, so those need to be answered too.

 

we need to double check that and report back.

 

> end.

 

 

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
Jean-Francois Mule | 5 Sep 2005 15:57
Favicon

Email from Sumanth C, editor of draft-ipcdn-pktc-signaling-08: final changes(?)

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40" xmlns:ns0="urn:schemas-microsoft-com:office:smarttags">

Folks,

 

   As you know, this ID is now expired and we have a good to complete the wg milestone by October.

 

   Below is an email from Sumanth sent at Wednesday, August 31, 2005 11:30 PM US Mountain Time summarizing the changes (per my email from 8/26). The original email included a preliminary version of draft09 (I removed it per IETF practice).

 

  Please review and provide any comments to Sumanth and the ipcdn list by Friday September 9, 9am ET.

 

Thanks,

Jean-François

IPCDN co-chair

From: Sumanth Channabasappa
Sent: Wednesday, August 31, 2005 11:30 PM
To: ipcdn <at> ietf.org
Subject: draft-ipcdn-pktc-signaling-08, final changes(?)

Folks,

Find enclosed a compilation of all the changes since the last draft as well as the actual MIB as an attachment. For those interested only in the changes made, please check the table (I have also included snippets of the MIB towards the end).

Please let me know if I have missed anything.

 

regards

Sumanth

 

Change

Reason

 

Renamed ‘pktcSigDevToneFrequencyNumber’ as ‘pktcSigDevToneNumber’

   As per discussion on July 6, 2005

Renamed ‘pktcSigDevToneFreqSecCompMode’ as ‘pktcSigDevToneFreqMode’

 

As per discussion on July 6, 2005

Renamed ‘pktcSigDevToneFreqSecCompPrtg’ as ‘pktcSigDevToneFreqAmpModePrtg’

 

As per discussion on July 6, 2005

Deleted ‘pktcNcsEndPntConfigTxGain’ and ‘pktcNcsEndPntConfigRxGain’

 

As per discussion on July 6, 2005

Modified Description of ‘pktcSigDevToneDbLevel’

 

As per discussion on July 6, 2005

(Phillip proposed new text for this MIB Object)

‘pktcSigDevToneNumber’ -> changed the cardinality from 5..16 to 1..8

 

As per discussion on July 6. 2005

 

Moved ‘pktcSigDevToneType’ to the Tone Table

   MIB doctor suggestion

Removed  ‘pktcSigDevToneNumFrequencies’

 

   As per discussion on July 6, 2005

Recommendation: ‘pktcSigDevToneNumber’ was recommended to be made ‘not-accessible’

Done

Entries in the ‘MultiFreqTable’ were recommended to be made ‘read-only’

Done

For all frequencies in the ‘MultiFreqTable’, the recommendation was to add a clarification to indicate that a value of ‘0’ implied ‘absence of the frequency’.

Done

Moved   

“pktcSigDevToneDbLevel” from SigDevToneTable to MultiFreqTable

Phillip’s email on 8/9 and corresponding call

Change to the range for the MIB Object‘ pktcNcsEndPntConfigMaxHookFlash’

As per Eugene’s email on 8/30

 

 

Snippets of the MIB:

 

<snip>

 

pktcSigDevToneTable    OBJECT-TYPE

<..>

    ::= { pktcSigDevConfigObjects 32 }

 

pktcSigDevToneEntry    OBJECT-TYPE

    SYNTAX       PktcSigDevToneEntry

    MAX-ACCESS   not-accessible

    STATUS       current

    DESCRIPTION

        " The different tone types that can be provisioned based on

          country specific needs.

          Each entry contains the tone generation parameters for

          a specific Tone Type. The different parameters can be

          provisioned by the MTA configuration file based on

          country specific needs. An MTA MUST populate all entries

          of this table for each tone type."

    INDEX { pktcSigDevToneType }

    ::= { pktcSigDevToneTable 1 }

 

PktcSigDevToneEntry ::= SEQUENCE {

    pktcSigDevToneType                      INTEGER,

    pktcSigDevToneWholeToneRepeatCount      Unsigned32,

    pktcSigDevToneSteady                    TruthValue

    }

 

 

pktcSigDevToneType        OBJECT-TYPE 

<..>

    ::= { pktcSigDevToneEntry 1 } 

 

 

pktcSigDevToneWholeToneRepeatCount      OBJECT-TYPE

<..>

 

    ::={ pktcSigDevToneEntry 2 }

 

pktcSigDevToneSteady    OBJECT-TYPE

<..>

    ::={ pktcSigDevToneEntry 3 }

 

 

 

 

<snip>

 

 

 

 

pktcSigDevMultiFreqToneTable    OBJECT-TYPE 

<..>

REFERENCE 

     ::= { pktcSigDevConfigObjects 35 } 

 

pktcSigDevMultiFreqToneEntry    OBJECT-TYPE 

<..>

 

INDEX { pktcSigDevToneType, pktcSigDevToneNumber} 

       ::= { pktcSigDevMultiFreqToneTable 1 } 

 

 

PktcSigDevMultiFreqToneEntry ::= SEQUENCE {

         pktcSigDevToneNumber                    Unsigned32,

         pktcSigDevToneFirstFreqValue            Unsigned32,

         pktcSigDevToneSecondFreqValue           Unsigned32,

         pktcSigDevToneThirdFreqValue            Unsigned32,

         pktcSigDevToneFourthFreqValue           Unsigned32,

         pktcSigDevToneFreqMode                  INTEGER,

         pktcSigDevToneFreqAmpModePrtg           Integer32,

         pktcSigDevToneDbLevel                   TenthdBm,

         pktcSigDevToneFreqOnDuration            Unsigned32,

         pktcSigDevToneFreqOffDuration           Unsigned32,

         pktcSigDevToneFreqRepeatCount           Unsigned32

   }

 

   pktcSigDevToneNumber OBJECT-TYPE 

   <..>

   ::={ pktcSigDevMultiFreqToneEntry 1} 

 

   pktcSigDevToneFirstFreqValue    OBJECT-TYPE 

   <..>

   ::={ pktcSigDevMultiFreqToneEntry 2} 

 

   pktcSigDevToneSecondFreqValue    OBJECT-TYPE 

   <..>

   ::={ pktcSigDevMultiFreqToneEntry 3} 

 

   pktcSigDevToneThirdFreqValue    OBJECT-TYPE 

   <..>

   ::={ pktcSigDevMultiFreqToneEntry 4} 

 

   pktcSigDevToneFourthFreqValue    OBJECT-TYPE 

   <..>

   ::={ pktcSigDevMultiFreqToneEntry 5} 

 

 

   pktcSigDevToneFreqMode OBJECT-TYPE 

       SYNTAX       INTEGER {

                     firstModulatedBySecond (1),

                     summation (2)

                    }

       MAX-ACCESS   read-write 

       STATUS       current 

       DESCRIPTION 

       "This MIB Object describes the way in which the

        frequencies comprising a tone need to be applied.

      

        It is to be noted that while summation can

        be done without any constraint on the number

        of frequencies, the modulation (amplitude)

        holds good only on two frequencies

        (first and second).

 

        Thus:

          - If the mode is set to a value of 

            firstModulatedBySecond (1), the first frequency

            MUST be modulated by the second and the remaining

            frequencies (third and fourth) ignored. The

            percentage of amplitude modulation to be applied

            is defined by the MIB Object

            'pktcSigDevToneFreqAmpModePrtg'.

          - If the mode is set to a value of

            summation (2), all the frequencies MUST be

            summed, without any modulation

       "

       ::={ pktcSigDevMultiFreqToneEntry 6} 

 

  pktcSigDevToneFreqAmpModePrtg OBJECT-TYPE 

       SYNTAX       Integer32(0..100)

       MAX-ACCESS   read-write 

       STATUS       current 

       DESCRIPTION 

          "This MIB Object represents the percentage of amplitude

           modulation applied to the second frequency

           when the MIB Object 'pktcSigDevToneFreqMode' is

           set to a value of 'firstModulatedBySecond (2)'.

 

           If the MIB Object 'pktcSigDevToneFreqMode' is set to

           value of 'summation (2)' then this MIB Object MUST be

           ignored."

       ::={ pktcSigDevMultiFreqToneEntry 7} 

 

   pktcSigDevToneDbLevel    OBJECT-TYPE

    SYNTAX       TenthdBm (-250..-30)

    UNITS        "dBm"

    MAX-ACCESS   read-only

    STATUS       current

    DESCRIPTION

             "This MIB Object contains the decibel level for each           

             analog signal (tone) that is locally generated 

             (versus in band supervisory tones) and sourced to 

             the a-b terminals (TE connection point). Each tone 

             in itself may consist of multiple frequencies as 

             defined by the MIB table 'pktcSigDevMultiFreqToneTable'.

   

             This MIB Object MUST reflect the desired level at 

             the Telco (POTS) a-b (T/R) terminals including the 

             affect of any MTA receiver gain (loss).  This is required

             so that locally generated tones are consistent with

             remotely generated in band tones at the a-b terminals,

             consistent with user expectations.

   

             This MIB Object must  be set for each tone. 

             When tones are formed by combining multi-frequencies,

             the level of each frequency shall be set so as to result

             in the tone level specified in this object at the a-b

             (T/R) terminals.

 

             The wide range of levels for this Object is required 

             to provide signal generator levels across the wide 

             range of gains (loss) - but does not imply the entire

             range is to be achievable given the range of gains (loss)

             in the MTA."

    DEFVAL { -40 }

    ::={ pktcSigDevMultiFreqToneEntry 8}

 

 

   pktcSigDevToneFreqOnDuration                     OBJECT-TYPE 

       SYNTAX       Unsigned32(0..5000)

       MAX-ACCESS   read-only 

       STATUS       current 

       DESCRIPTION 

          "This MIB Object represents the duration for which the

           frequency reference corresponding to the tone type

           is turned on." 

       ::={ pktcSigDevMultiFreqToneEntry 9} 

 

   pktcSigDevToneFreqOffDuration                     OBJECT-TYPE 

       SYNTAX       Unsigned32(0..5000)

       MAX-ACCESS   read-only 

       STATUS       current 

       DESCRIPTION 

          "This MIB Object represents the duration for which the

           frequency reference corresponding to the tone type

           is turned off." 

       ::={ pktcSigDevMultiFreqToneEntry 10} 

 

   pktcSigDevToneFreqRepeatCount             OBJECT-TYPE 

       SYNTAX       Unsigned32(0..5000)

       MAX-ACCESS   read-only 

       STATUS       current 

       DESCRIPTION 

       "This MIB Object indicates the number of times

       to repeat the cadence cycle represented by the

       on/off durations (refer to the MIB Objects

       pktcSigDevToneFreqOnDuration and

       pktcSigDevToneFreqOffDuration).

 

       Setting this object may result in a tone duration

       longer or shorter than the overall signal duration

       specified by the time out (TO) object for the

       corresponding tone type. If the value of this MIB

       Object indicates a longer duration than the

       specified by the TO, the latter overrules the former

       and the desired tone duration will be truncated according

       to the TO.

 

       However, if the repeat count results in a shorter

       tone duration than the signal duration specified by

       the TO, the tone duration defined by the repeat count

       takes precedence over the TO and will end the signal

       event. In this case, the TO represents a time not to

       be exceeded for the signal. It is recommended to

       ensure proper telephony signaling that the TO

       duration setting should always be longer than the

       desired repeat count time duration. A value of zero

       means the tone sequence is to be played once but not

       repeated."

       ::={ pktcSigDevMultiFreqToneEntry 11} 

 

 

<snip>

   pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE 

       SYNTAX       Unsigned32 (20..1550) 

       UNITS        "Milliseconds" 

       MAX-ACCESS   read-only 

       STATUS       current 

       DESCRIPTION 

           " This is the maximum time a line needs to be on hook for a

             valid hook flash. The value of

             pktcNcsEndPntConfigMaxHookFlash MUST be greater than

             pktcNcsEndPntConfigMinHookFlash. This object MUST only be

             set via the configuration file during the provisioning

             process."

       DEFVAL { 800 } 

       ::= { pktcNcsEndPntConfigEntry 33 }  

 

 

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
Thomas Anders | 5 Sep 2005 18:18
Picon
Favicon

Re: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

Jean-Francois Mule wrote:
>   We would appreciate receiving quick input from you and the wg on the
> proposed changes for draft 07

Here are my initial comments on #4, #14, #15 and #38:

> # Comment 4
>>     !! Missing citation for Normative reference:
>>     P047 L040:    [RFC2863] McCloghrie, K., Kastenholz, F., "The
>> Interfaces Group
> 
> ok, the reference is mostly because of the IMPORT of the IF-MIB.
> Proposed resolution: reference to [RFC2863] is introduced. We propose
> to add the following text in section 3:
> 
>    EMTA devices implementing this MIB Module MUST be compliant with
>    RFC 2863 [RFC2863] and the Packetcable MTA Device Provisioning
>    Specification [PKT-SP-PROV].
> 
> (we're also proposing to also add the existing normative reference to
> the MTA device provisioning spec here).

Isn't this a formal problem? [PKT-SP-PROV] (PKT-SP-PROV-I10-040730) 
itself has normative references to PKT-SP-MIB-MTA-I09-040402 (which our 
IPCDN MTA MIB is going to supersede) all over the place! Can we still
- say "MUST be compliant with ... [PKT-SP-PROV]"
- list [PKT-SP-PROV] as a normative reference at all
then? If we can't, this may affect the IPCDN MTA MIB at several places.

Will the PacketCable 1.0 specs be updated to include a normative 
reference to the IPCDN MTA MIB (instead of [PKT-SP-MIB-MTA-I09]) after 
it has become RFC?

> # Comment 14
> 
>> - For
> 
>>     pktcMtaDevTypeIdentifier     OBJECT-TYPE
>>        SYNTAX      SnmpAdminString
> 
>>   I see that it is an identifier as per DHCP option 60 (RFC2132.
>>   There it is specified as a "string of octets". How are we sure that
>>   such a "string of octets" is a valid SnmpAdminString?
> 
> Proposed resolution: no action
> We traced this assurance to a requirement in the PacketCable MTA
> Device Provisioning spec (see normative ref in the draft):
> 
> Section 8.2 says:
> 
>  8.2 DHCP Option 60: Vendor Client Identifier
> 
> "Option code 60 contains a string identifying Capabilities of the MTA.
> The MTA- MUST send the following ASCII Coded String in DHCP Option
> ----->                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> code 60: "pktc1.5:xxxxxx". Where xxxxxx MUST be an ASCII
> representation of the hexadecimal encoding of the MTA TLV Encoded
> Capabilities, as defined in Section 10."

Please note that you obviously quoted the PacketCable *1.5* Provisioning 
spec which doesn't apply here. However, this is not a problem as 
[PKT-SP-PROV] (but see #4!) has a similar requirement.

> # Comment 15
[...]
> pktcMtaDevSnmpEntity
> 
>   object value == DHCP option 122 sub-option 3 value [RFC 3495]
> 
>                   in the form of an FQDN
> 
>   SnmpAdminString is therefore ok.

Is it? DHCP 122.3 is *not* encoded as a string, but rather MUST be 
encoded per RFC 1035 (see RFC 3495, section 5). If the device is 
supposed to convert this object to a string, it should probably be 
stated explicitely.

> pktcMtaDevProvKerbRealmName
> 
>   object value == DHCP option 122 sub-option 6 value [RFC 3495]
> 
>                   ==> GeneralStrings encoded per RFC1510

RFC 3495, section 5.5, also requires RFC 1035 encoding here. See above.

> # Comment 38
> 
>> - At various places in your MIB module you have FQDNs present.
>>   I wonder if it would not be wise (for interoperability) to 
>>   specify WHEN such FQDNs are supposed to be resolved to IP addresses.
> 
> Agree.
> 
> Proposed new text:
[...]
> pktcMtaDevSnmpEntity
>           The MTA must resolve
>           the FQDN value before its very first network interaction
>           with the SNMP entity during the provisioning phase.

Beware that pktcMtaDevSnmpEntity can in fact resolve to multiple IP 
addresses and the expected behaviour is complex. I'd prefer to reference
the corresponding PacketCable Specifications instead.

Best regards,
Thomas

--

-- 
Thomas Anders (thomas.anders at blue-cable.de)
ewt breitbandnetze gmbh, berlin, germany
Jean-Francois Mule | 5 Sep 2005 18:40
Favicon

MTA MIB draft06 - AD comment #4 (RE: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt)

Thomas,

   Thank you for your input. I am splitting the threads to separate emails. This one is comment #4.

Jean-François

Thomas Anders wrote:
> Jean-Francois Mule wrote:
> >   We would appreciate receiving quick input from you and the wg on
> the
> > proposed changes for draft 07
> 
> Here are my initial comments on #4, #14, #15 and #38:
> 
> > # Comment 4
> >>     !! Missing citation for Normative reference:
> >>     P047 L040:    [RFC2863] McCloghrie, K., Kastenholz, F., "The
> >> Interfaces Group
> >
> > ok, the reference is mostly because of the IMPORT of the IF-MIB.
> > Proposed resolution: reference to [RFC2863] is introduced. We
> propose
> > to add the following text in section 3:
> >
> >    EMTA devices implementing this MIB Module MUST be compliant with
> >    RFC 2863 [RFC2863] and the Packetcable MTA Device Provisioning
> >    Specification [PKT-SP-PROV].
> >
> > (we're also proposing to also add the existing normative reference
> to
> > the MTA device provisioning spec here).
> 
> Isn't this a formal problem? 
 Not sure what you mean by "problem".

The "problem" solved by Comment #4 is missing citation.
 PKT-SP-PROV has always been a normative reference and it is also the case for RFC 2863 (due to the IMPORTs).

The "problem" you refer to below is imo for CableLabs to address. More inline.
> [PKT-SP-PROV] (PKT-SP-PROV-I10-040730)
> itself has normative references to PKT-SP-MIB-MTA-I09-040402 (which
> our
> IPCDN MTA MIB is going to supersede) all over the place! 
This is the usual chicken and egg kind of problem, and one of synchronizing cross-references.
For the IETF to get the RFC out, one must have a stable reference that is published (it can't be
PKT-SP-PROV-Ixx where xx is a future version referencing the IETF RFC).
For ETSI/ITU/CableLabs, we can't even start to consider the IETF MTA MIB rfc until it is published...

> Can we still
> - say "MUST be compliant with ... [PKT-SP-PROV]"
Yes. To my knowledge, PacketCable/IPcablecom MTAs do follow 1 spec for provisioning, and one can:
	a) comply with PKT-SP-PROV 
  and
	b) comply with RFC-to-be

> - list [PKT-SP-PROV] as a normative reference at all
> then? If we can't, this may affect the IPCDN MTA MIB at several places.
It has been there since draft02, and the draft passed 2 WGLC with it.

> Will the PacketCable 1.0 specs be updated to include a normative
> reference to the IPCDN MTA MIB (instead of [PKT-SP-MIB-MTA-I09]) after
> it has become RFC?

This is a question for:
	- CableLabs and its MSO members, as far as the PacketCable specifications are concerned;
	- the ETSI and the IPcablecom specifications 
	- the ITU SG9 for the ipcablecom recommendations still referencing the CableLabs mibs.

I will note that you have no particular comment on how the proposed text addresses the "problem" raised by
Comment#4 per se.

Jean-François

Gmane