[ipcdn] RE: IETF64 - IPCDN meeting minutes (preliminary)

["Woundy, Richard" <[e-mail]>]

Thanks, Bert. I believe I incorporated all of these suggestions to the
final posted minutes:
 
http://www3.ietf.org/proceedings/05nov/minutes/ipcdn.html
 
-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[e-mail]] 
Sent: Monday, November 28, 2005 8:41 AM
To: Woundy, Richard; Ipcdn (E-mail)
Cc: Wijnen, Bert (Bert); Jean-Francois Mule
Subject: RE: IETF64 - IPCDN meeting minutes (preliminary)


Inline

-----Original Message-----
From: Woundy, Richard [mailto:[e-mail]]
Sent: Tuesday, November 22, 2005 02:46
To: Ipcdn (E-mail)
Cc: Wijnen, Bert (Bert); Jean-Francois Mule; Woundy, Richard
Subject: IETF64 - IPCDN meeting minutes (preliminary)


Folks,
 
Below is my working copy of the meeting minutes from our WG session in
Vancouver.
 
Please send corrections to the mailing list and to myself -- especially
concerning the WG recommendations and next steps.
 
Thanks.
 
-- Rich
 
IETF IPCDN Meeting
Vancouver, British Columbia
Thursday November 10, 2005

Reported by Richard Woundy ([e-mail]) 


WG Meeting Summary and Administration


The IPCDN WG met to discuss the progress of various MIB documents,
especially the outstanding PacketCable/IPCablecom and DOCSIS
internet-drafts. 

The DOCSIS BPI+ MIB was published as RFC 4131 in September. The DOCSIS
QoS MIB and the DOCSIS Event Notification Management MIB are on the RFC
Editor Queue. 

Most of the meeting discussion centered on resolving open issues with
the PacketCable/IPCablecom MTA MIB (syntax of Kerberos realm names and
realm organization names, and a textual convention for encryption
algorithms), and with the PacketCable/IPCablecom Management Event MIB
(whether event throttling applies to local logging on the cable modem).
The PacketCable/IPCableCom NCS Signaling MIB, DOCSIS Cable Device MIB,
and DOCSIS RFIv2 MIB were also discussed, with a focus on the next steps
to get to the 'Publication Requested' state for all five
internet-drafts. 

There is a strong desire by the WG to conclude all DOCSIS and
PacketCable/IPCablecom MIB drafts by December 2005.  

 

Aggressive! But let's go for it, we have 3 more days!

Maybe you meant end-of-december 2005. With all the holidays, that will
arrive soon too!

 There were about ten attendees at the WG session in Vancouver. Total
meeting time was one hour. 


PacketCable/IPCableCom MTA MIB


Eugene Nechamkin and Jean-Francois Mule produced version 07 of the MTA
MIB draft, to address comments from the AD review (Bert Wijnen) and from
the IPCDN mailing list. The resolution of these comments were posted
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01806.html>  on
the mailing list. Most comments were resolved with simple editorial
fixes. One significant addition is specification of the same encryption
algorithms as the BPI+ MIB (RFC 4131, ref: DocsBpkmDataEncryptAlg). 

The WG discussion was centered on the proper MIB object SYNTAX for
Kerberos realm names and Kerberos realm organization names. 

With respect to the Kerberos realm organization name
(pktcMtaDevRealmOrgName), X.509 and RFC 2459 contrain the length of the
organization name to 64 characters. The characters may be encoded as a
UTF8String, so each character may occupy between one and six octets.
Therefore, a single organization name may occupy up to 384 octets. The
current MIB object has a SYNTAX of SnmpAdminString(SIZE (1..255)). 

The WG recommends to change the pktcMtaDevRealmOrgName object as
follows: 


1.	Remove the sentence referring to the "o=" prefix in the
DESCRIPTION clause. Do not include the "o=" prefix in the value of this
MIB object. 

2.	Change the SYNTAX of this object to LongUtf8String, imported
from the SYSAPPL-MIB defined in RFC 2287. This enables a maximum size of
1024 octets (for future growth). 

3.	Add a compliance statement for this object to limit the maximum
size of the object to 384 octets, and include justification, e.g. each
UTF-8 character can be up to 6 octets long, and the organization name
may contain up to 64 UTF-8 characters. 



Three distinct MIB objects contain a Kerberos realm name:
pktcMtaDevProvKerbRealmName, pktcMtaDevRealmName, and
pktcMtaDevCmsKerbRealmName. RFC 4120 specifies a syntax of GeneralString
for the Kerberos realm name, although the RFC says the realm name may be
non-ASCII (UTF8String) in the future. The WG recommendation is to
continue to use SnmpAdminString as the SYNTAX for these three MIB
objects. 

This draft also has a new textual convention for MTA configuration file
encryption algorithms, PktcMtaDevProvEncryptAlg. This textual convention
enables future support of triple-DES and AES encryption, similar to the
DocsBpkmDataEncryptAlg textual convention in the DOCSIS BPI+ MIB (RFC
4131). It was suggested to compare the PktcMtaDevProvEncryptAlg and
DocsBpkmDataEncryptAlg textual conventions, and if they were identical,
then have the MTA MIB IMPORT DocsBpkmDataEncryptAlg from the BPI+ MIB. 

Editor's note: the DocsBpkmDataEncryptAlg includes 40-bit and 56-bit DES
encryption but not 64-bit DES encryption as in PktcMtaDevProvEncryptAlg.
These textual conventions are NOT identical nor compatible. 

The next steps for this internet-draft are: 


1.	Bert Wijnen will respond to the author's email
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01806.html>  and
confirm whether or not the draft addresses the AD review comments. 

2.	The authors will incorporate the recommended changes to the
pktcMtaDevRealmOrgName MIB object. 

3.	Bert Wijnen will put the draft into the 'Publication Requested'
state.   

4.	

I probably have said that "I could put it in Publication Requested".
But I want/need a PROTO writeup as well.
So as per my email of past weekend, pls do the proto writeup and send a
request (from one of
the WG chairs) to the [e-mail] and ask for publication as
Proposed Standard.
Pls do copy me.  
And pls do only do so, after revision 8 has been posted, because that is
(as per our email exchange
over the weekend) the one that you want published. Current ID_tracker
state of this doc is "Revised ID needed"
which will change when new revision shows up.




PacketCable/IPCableCom NCS Signaling MIB 


I'd add that this is document:  draft-ietf-ipcdn-pktc-signaling-09.txt


 Gordon Beacham, Satish Kumar, and Sumanth Channabasappa submitted
version 09 of the NCS Signaling MIB draft, to address comments from the
MIB doctor and various WG participants. The resolution of these comments
were posted
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01809.html>  on
the mailing list. 


Significant updates included changes to a number of MIB objects in the
pktcSigDevMultiFreqToneTable, and the removal of the
pktcNcsEndPntConfigTxGain and pktcNcsEndPntConfigRxGain objects. 

There were no comments concerning this internet-draft in this meeting. 

The next steps for this internet-draft are: 


1.	The WG co-chairs will review this draft. 

2.	The co-chairs will request to put the draft into the
'Publication Requested' state. (Editor's note: does this imply a PROTO
writeup for this draft?)  

Yes, for every "publication requested as XX" (where XX is Proposed
Standard, or the state you want)  I want/need a PROTO
writeup.
 
This doc is in a weird "expired/dead" state in the ID-tracker. I am
following up on that with secretariat to get that
fixed. Pls keep your work going to get PROTO writeup done and to send
request to publish.
 




PacketCable/IPCableCom Management Event MIB 


 


I'dd add that this is document: draft-ietf-ipcdn-pktc-eventmess-05.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-05.
txt> 


 


also this doc is in a weird DEAD state in ID-tracker.


I am following up with secretrariat to get that fixed.


 


Wim De Ketelaere, Eugene Nechamkin, and Sumanth Channabasappa submitted
version 05 of the PacketCable/IPCableCom Management Event MIB draft,
responding to comments from a review by Greg Nakanishi and additional
feedback from Randy Presuhn. The resolution of these comments were
posted
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01810.html>  on
the mailing list. 

There was some discussion in the meeting about whether the event
throttling objects (pktcDevEvThrottleAdminStatus,
pktcDevEvThrottleThreshold, and pktcDevEvThrottleInterval) apply to
local logging of events, or only to network transmissions of events via
SNMP or SYSLOG messages. The current throttling MIB objects only refer
to SNMP and SYSLOG, but pktcDevEventDescrReporting and pktcDevEvLogType
refer to local logging. 

The WG recommends to add the following text to the DESCRIPTION of
pktcDevEvThrottleAdminStatus: "The impact of event throttling controls
on local logging is an implementation-specific matter." 

Editor's note: The following DESCRIPTION of pktcDevEvLogType suggests
that the throttling controls do NOT apply to local logging. If
throttling of local logging is implementation-specific, then at least
this DESCRIPTION should be revised. 

<FONT face="Times New Roman" size=3>   pktcDevEvLogType OBJECT-TYPE 

       SYNTAX      BITS { 

                   local(0), 

                   syslog (1), 

                   trap (2), 

                   inform (3) 

                   } 

       MAX-ACCESS  read-only 

       STATUS      current 

       DESCRIPTION 

               "This MIB Object contains the kind of actions taken by  

                the MTA when the event under consideration occurred. 

    

                A bit with a value of 1 indicates the corresponding 

                action was taken. Setting it to a value of 0 indicates  

                that the corresponding action was not taken. 

     

                An event may trigger one or more actions (e.g.: Syslog  

                and SNMP) or may remain as a local event since  

                transmissions could be disabled or inhibited as defined


                by the Throttle MIB Objects." 

                 

       ::= { pktcDevEventLogEntry 7 } 

</FONT>
 
As I think I stated at the meeting.
Pls be very explicit in the text of the DESCRIPTION clause(s) as to what

people can expect. 
<FONT face=Arial color=#0000ff></FONT>




  The next steps for this internet-draft are: 


1.	The WG co-chairs will review this draft. 

2.	The co-chairs will request to put the draft into the
'Publication Requested' state. (Editor's note: does this imply a PROTO
writeup for this draft?)   

3.	

Yes 




DOCSIS Cable Device MIB (replacing RFC2669) 


 


I would add: this is document: draft-ietf-ipcdn-device-mibv2-10.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.tx
t>  


Kevin Marez and Richard Woundy produced version 10 of the DOCSIS Cable
Device MIB draft, to address comments from the AD review (Bert Wijnen)
and from the MIB doctor review. The resolution of the AD review comments
were posted
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01808.html>  on
the mailing list. Most comments were resolved with simple editorial
fixes. 

Two significant changes in version 10 discussed in the meeting were the
new narrative text for MIB module IMPORTs and REFERENCE clauses (section
3.1.1), and the new narrative text discussing the persistance model for
cable modem MIB objects (section 3.1.2). There were no significant
comments on the IMPORT/REFERENCE narrative text, although this is
different from the approach taken by other IPCDN internet-drafts. Bert
noted that there was no MUST statements in the persistance model
narrative, but that was OK since the normative persistance requirements
were in the MIB object definitions. 

The next step for this internet-draft is for the IPCDN co-chairs (in
this particular case, Jean-Francois Mule) to write a "Protocol Write-Up"
to prepare for the IESG review process.  

 

Yep, the so called PROTO write up.

And that normally comes in with a "request t  to publish as XX" (XX is
the stds track you want, i believe PS for this doc).

Pls send to [e-mail] and cc: myself.

 


DOCSIS RFIv2 MIB (replacing RFC2670) 


This is document: draft-ietf-ipcdn-docs-rfmibv2-14.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-14.tx
t>  


Eduardo Cardona produced version 14 of the DOCSIS RFIv2 MIB, in response
to comments from the AD
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01694.html>
review (Bert Wijnen). 

There were no comments concerning this internet-draft in this meeting. 

The next steps for this internet-draft are: 


1.	The WG co-chairs will review this draft. 

2.	The co-chairs will request to put the draft into the
'Publication Requested' state. (Editor's note: does this imply a PROTO
writeup for this draft?)   

3.	

Yep, see above
 
Bert 




IPCDN Next Steps


The co-chairs will review plans for promoting, finalizing, and reviewing
current IPCDN MIBs, with a focus on the DOCSIS and
PacketCable/IPCableCom MIB internet-drafts. 


Co-chairs:


Richard Woundy <[e-mail]>
Jean-Francois Mule' <[e-mail]> 

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