From ipcdn-bounces@ietf.org Wed Nov 02 18:40:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXSDD-0004OO-23; Wed, 02 Nov 2005 18:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXSDC-0004OF-BE for ipcdn@megatron.ietf.org; Wed, 02 Nov 2005 18:40:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15785 for ; Wed, 2 Nov 2005 18:39:48 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXSRr-0005CE-LF for ipcdn@ietf.org; Wed, 02 Nov 2005 18:55:21 -0500 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14717021; Wed, 02 Nov 2005 18:39:32 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:39:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2005 18:39:32 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73016B13BE@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the standards track Thread-Index: AcXgBqy5efGaxNheS1Gp+6o0bBi/dA== From: "Woundy, Richard" To: "Jean-Francois Mule" X-OriginalArrivalTime: 02 Nov 2005 23:39:32.0703 (UTC) FILETIME=[AD0356F0:01C5E006] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: Bert Wijnen , ipcdn@ietf.org Subject: [ipcdn] Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the standards track X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Jean-Francois, I have posted an updated version of the DOCSIS Cable Device MIB, , which I believe is ready to be forwarded to the IESG for publication as an RFC with the status of Proposed Standard. I believe this draft incorporates the resolutions of the four open issues raised in , as clarified by . I will send details in a separate email. I also believe this draft satisfies the AD review concerns raised in . I will send details in another separate email. Please approve this draft for advancement. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Nov 02 18:47:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXSKW-0000w0-D5; Wed, 02 Nov 2005 18:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXSKU-0000sK-Qm for ipcdn@megatron.ietf.org; Wed, 02 Nov 2005 18:47:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16086 for ; Wed, 2 Nov 2005 18:47:21 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXSZA-0005XN-Pc for ipcdn@ietf.org; Wed, 02 Nov 2005 19:02:53 -0500 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14717229; Wed, 02 Nov 2005 18:47:02 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 18:40:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2005 18:40:46 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73016B13BF@PACDCEXCMB01.cable.comcast.com> Thread-Topic: AD review: draft-ietf-ipcdn-device-mibv2-09.txt Thread-Index: AcWioek39GafLeYWQHyDfwHAIXco3w9XvqkA From: "Woundy, Richard" To: "Wijnen, Bert \(Bert\)" , "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 02 Nov 2005 23:40:47.0024 (UTC) FILETIME=[D94FD300:01C5E006] X-Spam-Score: 0.0 (/) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Content-Transfer-Encoding: quoted-printable Cc: Jean-Francois Mule , "Woundy, Richard" Subject: [ipcdn] RE: AD review: draft-ietf-ipcdn-device-mibv2-09.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Bert, I believe I have addressed all of your comments on DOCSIS Cable Device = MIB -09 in = . I checked the new draft against the online idnits tool, = , and got the following = feedback: Checking nits according to http://www.ietf.org/ID-Checklist.html: =20 Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to = http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found. I used the online xml2rfc validator tool, = , against the XML = source, and got the following feedback: Processing... Validating document... Validation succeeded Performing additional checks... ...done (I put the XML source for -10 at = .) I used the smilint email service and got the following feedback: mailbody:2297: [5] {index-exceeds-too-large} warning: index of row = `docsDevCpeInetEntry' can exceed OID size limit by 141 subidentifier(s) mailbody:3003: [5] {group-unref} warning: deprecated group = `docsDevNmAccessExtGroup' is not referenced in this module (These are identical to some of the MIB compiler errors that you noted = below.) My responses to your comments below are marked [RW]. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, August 16, 2005 4:34 PM To: Woundy, Richard; Jean-Francois Mule Cc: Ipcdn (E-mail) Subject: AD review: draft-ietf-ipcdn-device-mibv2-09.txt In fact I did a review of a somewhat updated document: draft-ietf-ipcdn-device-mibv2-10-discussion.txt.=20 as per below email exchange between AD and WG chairs. Note that I did not re-review the decisions we took (and that are being verified by Jean Francois on the list) in Paris. The changes resulting from that should also go in. So here we go: - ID-Checklist - OK no nits found - References - NOK I find: !! Missing citation for Normative reference: P088 L036: [OSSI1.1] CableLabs, "Data-Over-Cable Service = Interface !! Missing citation for Normative reference: P088 L041: [OSSI2.0] CableLabs, "Data-Over-Cable Service = Interface Also: !! Missing citation for Normative reference: P090 L008: [RFC3411] Harrington, D., Presuhn, R., and B. = Wijnen, "An You have it in the IMPORTS clause. Possible solution OLD: SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 NEW: SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] Also: !! Missing citation for Normative reference: P089 L036: [RFC2863] McCloghrie, K. and F. Kastenholz, "The = Interfaces Group Possible solution OLD: InterfaceIndexOrZero FROM IF-MIB -- RFC 2863 NEW: InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] Also: !! Missing citation for Normative reference: P089 L008: [RFC2021] Waldbusser, S., "Remote Network Monitoring = Management Similar solution possible Also: !! Missing citation for Normative reference: P090 L035: [RFC3617] Lear, E., "Uniform Resource Identifier = (URI) Scheme and It is listed in he REFERENCE clause of = docsDevServerConfigTftpAddress. A possible solution: OLD: REFERENCE "RFC 3617, Section 5" NEW: REFERENCE "RFC 3617, Section 5" -- [RFC3617] Another way to solve it is to put some text just before the MIB = Module that states something aka: This MIB Module IMPORTS (normatively) from [RFC2580], [RFCxxxx], = etc It also has REFERENCE Clauses that refer to [RFCxxxx]. etc That way you will also be covered. [RW] I chose the latter approach, because it is also recommended in = section 3.2 (Narrative Sections) of RFC 4181. (Thanks Randy for pointing = it out.) Here is the new text: 3.1.1. IMPORTed MIB Modules and REFERENCE Clauses This MIB module IMPORTs definitions normatively from the following MIB modules, beyond [RFC2578], [RFC2579] and [RFC2580]: INET-ADDRESS- MIB [RFC4001], SNMP-FRAMEWORK-MIB [RFC3411], IF-MIB [RFC2863], RMON2- MIB [RFC2021], and DIFFSERV-MIB [RFC3289]. This MIB module also includes REFERENCE clauses that normatively refer to [RFC3617], [RFI1.0], [RFI1.1], [RFI2.0], [OSSI1.1], and [OSSI2.0]. [RW end] Further, you may want to update refrence to RFC3291 with reference to = RFC4001. Pls make sure to also correct the citations. [RW] All references to RFC3291 have been replaced by RFC4001. - MIB Module contents - SYNTAX check: docsDevEvReporting OBJECT-TYPE SYNTAX BITS { local(0), traps(1), syslog(2), localVolatile(8), stdInterface(9) } causes SMICng to bark: E: f(ipcdndevice.mi2), (1196,16) Named bits for BITS must be in contiguous positions =20 I guess you do this to not cause backward compatibility problems? Would it be good to do something aka: docsDevEvReporting OBJECT-TYPE SYNTAX BITS { local(0), traps(1), syslog(2), -- the following are extensions to the original set of -- labels. The extensions start at octet boundary. So=20 -- for bits 3-7, one MUST set them to zero on send and -- one MUST ignore them on receipt. localVolatile(8), stdInterface(9) } [RW] Done exactly as suggested. - More module syntax checking: W: f(ipcdndevice.mi2), (427,24) Item "docsDevNmAccessCommunity"=20 should have SIZE specified I guess theoretically we could specify a size of (0..255) because that must have been the intention all along (a community name=20 is limited to that size). But since object is deprecated I won't mind to leave as is [RW] I made no changes. W: f(ipcdndevice.mi2), (2428,4) Row "docsDevCpeInetEntry" has indexing that may create variables with more than 128 sub-ids I see that the InetAddress object DESCRIPTION clause instructs=20 implementors. So no problem. [RW] I made no changes. E: f(ipcdndevice.mi2), (2801,11) Item "diffServDataPathStatus" should be IMPORTed E: f(ipcdndevice.mi2), (2808,11) Item "diffServClfrStatus" should be IMPORTed E: f(ipcdndevice.mi2), (2815,11) Item "diffServClfrElementStatus" should be IMPORTed E: f(ipcdndevice.mi2), (2822,11) Item = "diffServMultiFieldClfrAddrType" should be IMPORTed E: f(ipcdndevice.mi2), (2829,11) Item = "diffServMultiFieldClfrSrcAddr" should beIMPORTed E: f(ipcdndevice.mi2), (2835,11) Item = "diffServMultiFieldClfrDstAddr" should beIMPORTed E: f(ipcdndevice.mi2), (2841,11) Item "diffServAlgDropStatus" = should be IMPORTed E: f(ipcdndevice.mi2), (2848,11) Item "diffServDataPathStorage" = should be IMPORTed E: f(ipcdndevice.mi2), (2854,11) Item "diffServClfrStorage" should be IMPORTed E: f(ipcdndevice.mi2), (2860,11) Item "diffServClfrElementStorage" should be IMPORTed E: f(ipcdndevice.mi2), (2866,11) Item = "diffServMultiFieldClfrStorage" should beIMPORTed E: f(ipcdndevice.mi2), (2872,11) Item "diffServActionStorage" = should be IMPORTed E: f(ipcdndevice.mi2), (2879,11) Item "diffServCountActStorage" = should be IMPORTed E: f(ipcdndevice.mi2), (2885,11) Item "diffServAlgDropStorage" = should be IMPORTed E: f(ipcdndevice.mi2), (2891,11) Item "diffServAlgDropType" should be IMPORTed Most of those were also imported in the subscriber MIB, so it seems = to me we have dealth with this before in that other MIB module. [RW] Done. All of these objects are now IMPORTed. W: f(ipcdndevice.mi2), (3140,4) OBJECT-GROUP = "docsDevNmAccessExtGroup" is not used in a MODULE-COMPLIANCE in current module I am kind of surprised to see this Group at all. It is deprecated, and it contains one object = docsDevNmAccessTrapVersion which is also deprecated. The object nor the Group existed in RFC = 2669 (which this doc obsoletes). So why are we having this deprecated object and object group at all?=20 OK, OK, I see in DESCRIPTION clause why it was added. Mmm... Not exactly right... maybe I can live with it. But possibly this would be added to some (new) deprecated = MODULE-COMPLIANCE. I guess it could even be added as optional group to the deprecated docsDevBasicCompliance, since it does not make old claims for that MODULE-COMPLIANCE invalid.... (borderline I think) So maybe accept the warning that the group is not used. [RW] I made no changes. Nits: - "IPSec" (I know it was incorrect in the mib security template too, = I just fixed it) should be spelled "IPsec" [RW] Done. Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, August 10, 2005 16:29 To: Wijnen, Bert (Bert); Jean-Francois Mule Cc: Woundy, Richard Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews OK, that would be terrific, thanks! -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 10, 2005 10:07 AM To: Woundy, Richard; Wijnen, Bert (Bert); Jean-Francois Mule Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews So hwo about me reviewing=20 = http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.t= xt.=20 and assuming you will fix the 4 issues we discussed at the WG session = last week. If I indeed do keep my promise (I have a bda track record) = then by the 15th you can incorporate all comments in to the next = official revision. Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, August 10, 2005 15:24 To: Wijnen, Bert (Bert); Jean-Francois Mule Cc: Woundy, Richard Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews Bert, Jean-Francois, About this one review: 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 =20 # AD review by Bert due by August 15 As you know from last week's working group meeting, this draft is = undergoing editing to address Randy's comments. There are three versions that could undergo AD review: The officially posted draft-ietf-ipcdn-device-mibv2-09 version. Randy = sent a number of emails to the IPCDN mailing list with numerous MIB = doctor comments against this version.=20 I generated an interim version, = http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.t= xt. This is the draft version that was the basis of the review in the = working group (e.g. the "four issues").=20 I would like to submit a real draft-ietf-ipcdn-device-mibv2-10 based on = the working group meeting discussions, but I cannot finish this before = August 15 at the earliest. This would be incompatible with your review = being due on August 15. Bert, if you choose to review the posted -09 = version, or the interim -10 "discussion", then I will wait for your = review comments before I post the real -10 version. If you want to review a posted -10 version, then I need to know soon, so = that I hurry up on incorporating the working group comments (and Randy's = email comments as well). Then we probably need to push back your review = date a week or two. For me, the ideal choice would be for you to review the interim version = http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.t= xt, and then I would incorporate your AD review comments into a posted = -10 version. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, August 09, 2005 5:21 AM To: Jean-Francois Mule; bwijnen@lucent.com Cc: Woundy, Richard Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews looks fine to me. Bert -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Monday, August 08, 2005 18:17 To: bwijnen@lucent.com Cc: Richard Woundy @ Comcast Subject: IPCDN wg - meeting minutes and dates for 3 AD reviews Bert, =20 I'm finishing up the meeting minutes from ipcdn and I just want to = make sure we have realistic dates for AD review. I snipped most of the = text from the draft minutes except for AD review lines. =20 Here's a recap, let me know what to change or if this still looks ok. = Just want to make sure we're in sync. =20 Thanks, Jean-Fran=E7ois =20 =20 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 =20 # AD review by Bert due by August 15 =20 =20 3.2/ RF MIB v2 draft-ietf-ipcdn-docs-rfmibv2-13.txt Editor: Eduardo Cardona = http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt =20 Not discussed due to time limit. # AD review by Bert due by August 15 =20 3.3/ IPCablecom/PacketCable MTA MIB draft-ietf-ipcdn-pktc-mtamib-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt Not discussed due to time limit. # AD review by Bert due by August 15 =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Nov 02 23:37:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXWr1-0005C9-5q; Wed, 02 Nov 2005 23:37:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXWqy-0005C4-S5 for ipcdn@megatron.ietf.org; Wed, 02 Nov 2005 23:37:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00675 for ; Wed, 2 Nov 2005 23:37:11 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXX5h-0001g5-AT for ipcdn@ietf.org; Wed, 02 Nov 2005 23:52:46 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id jA34bK8p026791 for ; Wed, 2 Nov 2005 21:37:20 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Nov 2005 21:37:20 -0700 Message-ID: Thread-Topic: Changes to draft-ietf-ipcdn-pktc-signaling-09.txt Thread-Index: AcXbCyqCMRF6/P7DTwad3bdLTMvBUwAKCpTAAT8lxUA= From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a9d8f61f7718176ef97b85bbcc64331 Subject: [ipcdn] Changes to draft-ietf-ipcdn-pktc-signaling-09.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1716610627==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1716610627== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E030.46ED6DCD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E030.46ED6DCD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 This email summarizes the comments received on SIG MIB draft - 08 and the changes made before submission as draft - 09. =20 regards Sumanth=20 =20 =20 Link to draft-09: (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-09.t xt ) =20 =20 Outstanding issues: - None =20 =20 Recommendations not included: - Comment from Jean-Francois via email on 9/15 in relation to the usage of 'E Line Package' as part of the 'pktcSigDevRingCadence' MIB Object =20 Reasoning: 'E line package' and 'L Line package' are defined for usage in the document and the MIB Objects are specific to them. =20 =20 =20 =20 Summary of Changes: =20 =20 Change Reason =20 Renamed 'pktcSigDevToneFrequencyNumber' as 'pktcSigDevToneNumber' Incorporated; as per draft editors' discussion on July 6, 2005 Renamed 'pktcSigDevToneFreqSecCompMode' as 'pktcSigDevToneFreqMode' =20 Incorporated; as per draft editors' discussion on July 6, 2005 Renamed 'pktcSigDevToneFreqSecCompPrtg' as 'pktcSigDevToneFreqAmpModePrtg' =20 Incorporated; as per draft editors' discussion on July 6, 2005 Deleted 'pktcNcsEndPntConfigTxGain' and 'pktcNcsEndPntConfigRxGain' =20 Incorporated; as per draft editors' discussion on July 6, 2005 Modified Description of 'pktcSigDevToneDbLevel' =20 Incorporated; as per draft editors' discussion on July 6, 2005 (Phillip proposed new text for this MIB Object) 'pktcSigDevToneNumber' -> changed the cardinality from 5..16 to 1..8 =20 Incorporated; as per draft editors' discussion on July 6. 2005 =20 Moved 'pktcSigDevToneType' to the Tone Table Incorporated; as per MIB doctor suggestion Removed 'pktcSigDevToneNumFrequencies'=20 =20 Incorporated; as per draft editors' discussion on July 6, 2005 Recommendation: 'pktcSigDevToneNumber' was recommended to be made 'not-accessible' Incorporated Entries in the 'MultiFreqTable' were recommended to be made 'read-only' Incorporated 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'. Incorporated Moved =20 "pktcSigDevToneDbLevel" from SigDevToneTable to MultiFreqTable Incorporated; as per Phillip's email on 8/9=20 Change to the range for the MIB Object' pktcNcsEndPntConfigMaxHookFlash' Incorporated; as per Eugene's email on 8/30 Follow-up by Phillip, consensus 9/2 Comments from Jean-Francois via email 09/15 =20 http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01775.html =20 =20 Except the comment mentioned earlier, the rest were incorporated. =20 =20 =20 ------_=_NextPart_001_01C5E030.46ED6DCD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
This email summarizes the comments =
received on SIG MIB draft - 08 =
and the changes made before submission as draft - 09.

 

regards

Sumanth 

 

 

Link to draft-09: (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-= signaling-09.txt)

 

 

Outstanding=20 issues:

- = None

 

 

Recommendations = not=20 included:

- Comment from = Jean-Francois=20 via email on 9/15 in relation to the usage of 'E Line Package' as part = of the=20 'pktcSigDevRingCadence' MIB Object

 

Reasoning:

'E line package' = and 'L Line=20 package' are defined for usage in the document and the MIB Objects are = specific=20 to them.

 

 

 

 

Summary of=20 Changes:

 

 

Change

Reason

 

Renamed = ‘pktcSigDevToneFrequencyNumber’ as=20 = ‘pktcSigDevToneNumber’

Incorporated; as per draft editors' discussion on = July 6,=20 2005

Renamed = ‘pktcSigDevToneFreqSecCompMode’ as=20 ‘pktcSigDevToneFreqMode’

 

Incorporated; as per draft editors' discussion on = July 6,=20 2005

Renamed = ‘pktcSigDevToneFreqSecCompPrtg’ as=20 = ‘pktcSigDevToneFreqAmpModePrtg’

 

Incorporated; as per draft editors' discussion on = July 6,=20 2005

Deleted ‘pktcNcsEndPntConfigTxGain’ = and=20 = ‘pktcNcsEndPntConfigRxGain’

 

Incorporated; as per draft editors' discussion on = July 6,=20 2005

Modified Description of=20 ‘pktcSigDevToneDbLevel’

 

Incorporated; as per draft editors' discussion on = July 6,=20 2005

(Phillip proposed new text for this MIB=20 Object)

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

 

Incorporated; as per draft editors' discussion on = July 6.=20 2005

 

Moved ‘pktcSigDevToneType’ to the Tone = Table

Incorporated; as per MIB doctor=20 suggestion

Removed =20 ‘pktcSigDevToneNumFrequencies’ =

 

Incorporated; as per draft editors' discussion on = July 6,=20 2005

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

Incorporated

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

Incorporated

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

Incorporated

Moved   =20

“pktcSigDevToneDbLevel” from = SigDevToneTable to=20 MultiFreqTable

Incorporated; as per Phillip’s email on 8/9=20

Change to the range for the MIB Object‘=20 pktcNcsEndPntConfigMaxHookFlash’ =

Incorporated; as per Eugene’s email on=20 8/30

Follow-up by Phillip, consensus=20 9/2

Comments from Jean-Francois via email=20 09/15

 

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01= 775.html

 

Except the comment mentioned earlier, the rest = were=20 = incorporated.

 

 

 

------_=_NextPart_001_01C5E030.46ED6DCD-- --===============1716610627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1716610627==-- From ipcdn-bounces@ietf.org Wed Nov 02 23:54:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXX7I-0005RJ-TF; Wed, 02 Nov 2005 23:54:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXX7F-0005MW-Ej for ipcdn@megatron.ietf.org; Wed, 02 Nov 2005 23:54:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01633 for ; Wed, 2 Nov 2005 23:54:00 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXXLy-0002eB-JG for ipcdn@ietf.org; Thu, 03 Nov 2005 00:09:34 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id jA34sBdq029416 for ; Wed, 2 Nov 2005 21:54:12 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2005 21:54:11 -0700 Message-ID: Thread-Topic: Changes to draft-ietf-ipcdn-pktc-eventmess-05.txt Thread-Index: AcWh/HKIom44+HHgQGa23DAUEop9nw+NasHQ From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Changes to draft-ietf-ipcdn-pktc-eventmess-05.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org All, =20 This email summarizes the comments received on eventmess-draft-04 and the changes made before submission as draft-05. =20 regards Sumanth=20 Link: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-05.tx t Outstanding issues: None Recommendations not incorporated: - Recommendation to include throttling of local events,=20 #1: Origin (comment 8a and 9): http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01691.html Further discussion: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01791.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01792.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01793.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01795.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01796.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01797.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01798.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01799.html Reasoning/Final resolution: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01801.html #2: Origin (comment 14): http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01691.html pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write. It seems odd to me that these objects would be writable. Is it really intended that these are writable objects? Reasoning/Resolution: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01782.html Comments incorporated -------- ------------ 1) I suggest "PacketCable" and "IPCablecom" be defined in the Terminology section. 2) There are a number of places in the document that makes reference to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom device"? Or more simply "MTA device". 3) The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs. So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB". 4) I think the ORGANIZATION clause should be IPCDN rather than CableLabs. 5) The DESCRIPTION clause is missing the mandatory copyright notice. 6) The OID layout doesn't conform to the recommended layout given in "Guidelines for MIB Documents", Appendix D. 7) pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default." Should this just PacketCable or PacketCable and IPCablecom. 8b) pktcDevEvThrottleAdminStatus - "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages? 10) pktcDevEvThrottleInterval - The DEFVAL clause should be on a separate line for readability. 11) pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"? 12) pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined. 13) pktcDevEventDescrReporting - Should define what each one of the bit values mean. 15) pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" Reference [3] doesn't exist in the references section. pktcDevEvLogCorrelationId "This MIB Object contains the correlation ID=20 generated by the MTA during the initiation of the last provisioning flow, within or following which the event occurred.=20 For information on the generation of correlation ids, refer to the corresponding PacketCable/IPCableCom Device Provisioning specifications." 16) [PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable" 17) Reference section - There are number of reference in the body of the text that do not exist in the references section. Need to make sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. 18) Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object. - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Nov 21 16:40:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJOO-0007ah-QE; Mon, 21 Nov 2005 16:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJOM-0007Zv-Qh for ipcdn@megatron.ietf.org; Mon, 21 Nov 2005 16:40:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15675 for ; Mon, 21 Nov 2005 16:39:25 -0500 (EST) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeJgs-0003Y6-Mx for ipcdn@ietf.org; Mon, 21 Nov 2005 16:59:11 -0500 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 21 Nov 2005 13:39:43 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 21 Nov 2005 13:39:42 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CGB57051; Mon, 21 Nov 2005 13:39:41 -0800 (PST) Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA00371; Mon, 21 Nov 2005 13:39:40 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id jALLdeox029338; Mon, 21 Nov 2005 13:39:40 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Nov 2005 13:39:21 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F4856413C820@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Thread-Index: AcXu4uGjomuuwvp5R/SYr2ZJUz4lpgAAHU4g From: "Eugene Nechamkin" To: "Ipcdn (E-mail)" X-WSS-ID: 6F9CE11548G336132-01-01 X-Spam-Score: 0.2 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1941262114==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1941262114== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EEE4.13CA3771" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EEE4.13CA3771 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: =20 - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=3D' = in the Organization Name. =20 The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX SnmpAdminString(SIZE (1..255))=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute as defined in the subject name of the service provider =20 certificate. The value of the organization name includes=20 the prefix 'O=3D'."=20 REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 }=20 =20 =20 To address these two comments, co-authors are proposing the following: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20 characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as=20 specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant=20 devices must support a maximum size of 384 octets for=20 pktcMtaDevRealmOrgName." =20 =20 Please feel free to provide comments on proposed modifications. =20 Regards, =20 Eugene Nechamkin. =20 ------_=_NextPart_001_01C5EEE4.13CA3771 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
 
During the presentation of the=20 draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the = following=20 comments made on the presented = material:
 
    - the max length of the = "pktcMtaDevRealmOrgName" currently defined as being 255 does not = correspond to=20 the actual number of octets the MIB object may contain which is = calculated as=20 max number of UTF-8 characters (64) each of which may consist of up to 6 = octets.
    - the value of the MIB = object=20 should not include the prefix 'O=3D' in the Organization=20 Name.
 
The current definition of the = "pktcMtaDevRealmOrgName"=20 in the draft-07 is as follows:
 
   pktcMtaDevRealmOrgName  = OBJECT-TYPE=20
       = SYNTAX     =20 SnmpAdminString(SIZE (1..255))
      =20 MAX-ACCESS  read-create
      =20 STATUS      current=20
       DESCRIPTION=20
           " This = object=20 contains the X.500 organization name attribute =20
           &nb= sp; as=20 defined in the subject name of the service provider =20
           &nb= sp;=20 certificate. The value of the organization name includes=20
           &nb= sp; the=20 prefix 'O=3D'."
       REFERENCE=20
           " = PacketCable=20 Security Specification."
       ::=3D = {=20 pktcMtaDevRealmEntry 5 }
 
 
To address these two comments, = co-authors=20 are proposing the following:
 
=
1. Add the following to the = IMPORTS section=20 of the MTA MIB:
 
    LongUtf8String =20
           =20 FROM=20 SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify the definition of the = pktcMtaDevRealmOrgName=20 to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE=20
    SYNTAX LongUtf8String=20
         ^^^^^^^^^^^
    MAX-ACCESS read-create=20
    STATUS current=20
    DESCRIPTION=20
        = " This=20 object contains the X.500 organization name attribute=20
        = as defined=20 in the subject name of the service provider
        = X.509=20 certificate."
    REFERENCE=20
        = "=20 PacketCable Security Specification."
    ::=3D { = pktcMtaDevRealmEntry 5=20 }
 
3. Add the following compliance statement = to the MTA=20 MIB compliance section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String = (SIZE=20 (1..384))
   =20 DESCRIPTION
        = " Compliant=20 devices are only required to support
        = pktcMtaDevRealmOrgName values of 64 UTF-8 encoded =
        = characters.
        = The=20 Organization Name of the X.509 certificate = can
        = contain up=20 to 64 UTF-8 encoded characters as
        = specified=20 in RFC 2459.
        = Given that,=20 in UTF-8, characters are encoded using
        = sequences=20 of 1 to 6 octets (RFC 2279), compliant
        = devices=20 must support a maximum size of 384 octets for =
        = pktcMtaDevRealmOrgName."
 
 
Please = feel free to=20 provide comments on proposed = modifications.
 
Regards,
 
Eugene = Nechamkin.
 
------_=_NextPart_001_01C5EEE4.13CA3771-- --===============1941262114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1941262114==-- From ipcdn-bounces@ietf.org Mon Nov 21 20:28:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeMxG-0005Tw-HG; Mon, 21 Nov 2005 20:28:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeMxF-0005Tj-KA for ipcdn@megatron.ietf.org; Mon, 21 Nov 2005 20:28:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14283 for ; Mon, 21 Nov 2005 20:27:38 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeNFm-0005Sg-BG for ipcdn@ietf.org; Mon, 21 Nov 2005 20:47:28 -0500 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 21 Nov 2005 17:27:49 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com for ; Mon, 21 Nov 2005 17:27:48 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CGC09190; Mon, 21 Nov 2005 17:27:43 -0800 (PST) Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA07314 for ; Mon, 21 Nov 2005 17:27:43 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id jAM1Rgov019580 for ; Mon, 21 Nov 2005 17:27:43 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Nov 2005 17:27:42 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F4856413C8E5@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: One Issue in the draft-ietf-ipcdn-pktc-signaling-09.txt Thread-Index: AcWvwVGoRsfcYdiKQQ6CNjezZTHfMw/QUn0g From: "Eugene Nechamkin" To: ipcdn@ietf.org X-WSS-ID: 6F9CAB9F2JW356553-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] One Issue in the draft-ietf-ipcdn-pktc-signaling-09.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org I noticed that the curent version of the Signaling MIB draft does not preserve countigous numbering space for the MIB Objects' OIDs in one instance: the OID of the "pktcSigDevToneTable" is defined as "{ pktcSigDevConfigObjects 32 }" while the next MIB Object off of the "pktcSigDevConfigObjects" node (pktcSigDevMultiFreqToneTable) is defined as "{pktcSigDevConfigObjects 35}". I would suggest changing the latter to be defined as follows: pktcSigDevMultiFreqToneTable OBJECT-TYPE =20 SYNTAX SEQUENCE OF PktcSigDevMultiFreqToneEntry=20 ...... ...... ::=3D { pktcSigDevConfigObjects 33 } =20 Regards, Eugene Nechamkin _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Nov 21 20:46:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNFB-0004WJ-Kv; Mon, 21 Nov 2005 20:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNFA-0004WE-N0 for ipcdn@megatron.ietf.org; Mon, 21 Nov 2005 20:46:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15885 for ; Mon, 21 Nov 2005 20:46:09 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeNXg-00064S-T9 for ipcdn@ietf.org; Mon, 21 Nov 2005 21:05:59 -0500 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.15170945; Mon, 21 Nov 2005 20:46:12 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 20:46:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Nov 2005 20:46:10 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73016B14C5@PACDCEXCMB01.cable.comcast.com> Thread-Topic: IETF64 - IPCDN meeting minutes (preliminary) Thread-Index: AcXvBocb4zTemIp+RFOsqiR8vTxb4A== From: "Woundy, Richard" To: "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 22 Nov 2005 01:46:12.0728 (UTC) FILETIME=[84D45F80:01C5EF06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e Cc: "Wijnen, Bert \(Bert\)" , Jean-Francois Mule , "Woundy, Richard" Subject: [ipcdn] IETF64 - IPCDN meeting minutes (preliminary) X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0561830631==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0561830631== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EF06.83978A75" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EF06.83978A75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Below is my working copy of the meeting minutes from our WG session in Vancouver. =20 Please send corrections to the mailing list and to myself -- especially concerning the WG recommendations and next steps. =20 Thanks. =20 -- Rich =20 IETF IPCDN Meeting Vancouver, British Columbia Thursday November 10, 2005 Reported by Richard Woundy (richard_woundy@cable.comcast.com)=20 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.=20 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.=20 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.=20 There is a strong desire by the WG to conclude all DOCSIS and PacketCable/IPCablecom MIB drafts by December 2005.=20 There were about ten attendees at the WG session in Vancouver. Total meeting time was one hour.=20 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 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).=20 The WG discussion was centered on the proper MIB object SYNTAX for Kerberos realm names and Kerberos realm organization names.=20 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)).=20 The WG recommends to change the pktcMtaDevRealmOrgName object as follows:=20 1. Remove the sentence referring to the "o=3D" prefix in the DESCRIPTION clause. Do not include the "o=3D" prefix in the value of = this MIB object.=20 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).=20 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.=20 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.=20 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.=20 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.=20 The next steps for this internet-draft are:=20 1. Bert Wijnen will respond to the author's email and confirm whether or not the draft addresses the AD review comments.=20 2. The authors will incorporate the recommended changes to the pktcMtaDevRealmOrgName MIB object.=20 3. Bert Wijnen will put the draft into the 'Publication Requested' state.=20 PacketCable/IPCableCom NCS Signaling MIB 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 on the mailing list.=20 Significant updates included changes to a number of MIB objects in the pktcSigDevMultiFreqToneTable, and the removal of the pktcNcsEndPntConfigTxGain and pktcNcsEndPntConfigRxGain objects.=20 There were no comments concerning this internet-draft in this meeting.=20 The next steps for this internet-draft are:=20 1. The WG co-chairs will review this draft.=20 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?)=20 PacketCable/IPCableCom Management Event MIB 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 on the mailing list.=20 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.=20 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."=20 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.=20 pktcDevEvLogType OBJECT-TYPE=20 SYNTAX BITS {=20 local(0),=20 syslog (1),=20 trap (2),=20 inform (3)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This MIB Object contains the kind of actions taken by =20 the MTA when the event under consideration occurred.=20 =20 A bit with a value of 1 indicates the corresponding=20 action was taken. Setting it to a value of 0 indicates =20 that the corresponding action was not taken.=20 =20 An event may trigger one or more actions (e.g.: Syslog =20 and SNMP) or may remain as a local event since =20 transmissions could be disabled or inhibited as defined by the Throttle MIB Objects."=20 =20 ::=3D { pktcDevEventLogEntry 7 }=20 The next steps for this internet-draft are:=20 1. The WG co-chairs will review this draft.=20 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?)=20 DOCSIS Cable Device MIB (replacing RFC2669) 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 on the mailing list. Most comments were resolved with simple editorial fixes.=20 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.=20 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.=20 DOCSIS RFIv2 MIB (replacing RFC2670) Eduardo Cardona produced version 14 of the DOCSIS RFIv2 MIB, in response to comments from the AD review (Bert Wijnen).=20 There were no comments concerning this internet-draft in this meeting.=20 The next steps for this internet-draft are:=20 1. The WG co-chairs will review this draft.=20 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?)=20 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.=20 Co-chairs: Richard Woundy Jean-Francois Mule' =20 ------_=_NextPart_001_01C5EF06.83978A75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Folks,
 
Below = is my working=20 copy of the meeting minutes from our WG session in=20 Vancouver.
 
Please = send=20 corrections to the mailing list and to myself -- = especially concerning the=20 WG recommendations and next steps.
 
Thanks.
 
--=20 Rich
 

IETF IPCDN Meeting
Vancouver, British=20 Columbia
Thursday November 10, 2005

Reported by = Richard=20 Woundy (richard_woundy@cable.comcast.com)

WG Meeting Summary and Administration

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

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

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

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

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

PacketCable/IPCableCom MTA MIB

Eugene Nechamkin and Jean-Francois Mule produced version 07 of the = MTA MIB=20 draft, to address comments from the AD review (Bert Wijnen) and from the = IPCDN=20 mailing list. The resolution of these comments were posted=20 on the mailing list. Most comments were resolved with simple editorial = fixes.=20 One significant addition is specification of the same encryption = algorithms as=20 the BPI+ MIB (RFC 4131, ref: DocsBpkmDataEncryptAlg).

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

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

The WG recommends to change the pktcMtaDevRealmOrgName object as = follows:=20

  1. Remove the sentence referring to the "o=3D" prefix in the = DESCRIPTION=20 clause. Do not include the "o=3D" prefix in the value of this MIB = object.=20
  2. Change the SYNTAX of this object to LongUtf8String, imported from = the=20 SYSAPPL-MIB defined in RFC 2287. This enables a maximum size of 1024 = octets=20 (for future growth).=20
  3. Add a compliance statement for this object to limit the maximum = size of=20 the object to 384 octets, and include justification, e.g. each UTF-8 = character=20 can be up to 6 octets long, and the organization name may contain up = to 64=20 UTF-8 characters.

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

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

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

The next steps for this internet-draft are:=20

  1. Bert Wijnen will respond to the author's email=20 and confirm whether or not the draft addresses the AD review comments. =
  2. The authors will incorporate the recommended changes to the=20 pktcMtaDevRealmOrgName MIB object.=20
  3. Bert Wijnen will put the draft into the 'Publication Requested' = state.=20

PacketCable/IPCableCom NCS Signaling = MIB

Gordon Beacham, Satish Kumar, and Sumanth Channabasappa submitted = version 09=20 of the NCS Signaling MIB draft, to address comments from the MIB doctor = and=20 various WG participants. The resolution of these comments were posted=20 on the mailing list.

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

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

The next steps for this internet-draft are:=20

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

PacketCable/IPCableCom Management Event = MIB

Wim De Ketelaere, Eugene Nechamkin, and Sumanth Channabasappa = submitted=20 version 05 of the PacketCable/IPCableCom Management Event MIB draft, = responding=20 to comments from a review by Greg Nakanishi and additional feedback from = Randy=20 Presuhn. The resolution of these comments were posted=20 on the mailing list.

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

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

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

<FONT face=3D"Times New Roman" size=3D3> = pktcDevEvLogType OBJECT-TYPE=20 SYNTAX BITS {=20 local(0),=20 syslog (1),=20 trap (2),=20 inform (3)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "This MIB Object contains the kind of actions taken by =20 the MTA when the event under consideration occurred.=20 =20 A bit with a value of 1 indicates the corresponding=20 action was taken. Setting it to a value of 0 indicates =20 that the corresponding action was not taken.=20 =20 An event may trigger one or more actions (e.g.: Syslog =20 and SNMP) or may remain as a local event since =20 transmissions could be disabled or inhibited as defined = by the Throttle MIB Objects."=20 =20 ::=3D { pktcDevEventLogEntry 7 }=20 </FONT>

The next steps for this internet-draft are:=20

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

DOCSIS Cable Device MIB (replacing RFC2669)

Kevin Marez and Richard Woundy produced version 10 of the DOCSIS = Cable Device=20 MIB draft, to address comments from the AD review (Bert Wijnen) and from = the MIB=20 doctor review. The resolution of the AD review comments were posted=20 on the mailing list. Most comments were resolved with simple editorial = fixes.=20

Two significant changes in version 10 discussed in the meeting were = the new=20 narrative text for MIB module IMPORTs and REFERENCE clauses (section = 3.1.1), and=20 the new narrative text discussing the persistance model for cable modem = MIB=20 objects (section 3.1.2). There were no significant comments on the=20 IMPORT/REFERENCE narrative text, although this is different from the = approach=20 taken by other IPCDN internet-drafts. Bert noted that there was no MUST=20 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=20 particular case, Jean-Francois Mule) to write a "Protocol Write-Up" to = prepare=20 for the IESG review process.

DOCSIS RFIv2 MIB (replacing RFC2670)

Eduardo Cardona produced version 14 of the DOCSIS RFIv2 MIB, in = response to=20 comments from the AD=20 review (Bert Wijnen).

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

The next steps for this internet-draft are:=20

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

IPCDN Next Steps

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

Co-chairs:

Richard Woundy = <Richard_Woundy@cable.comcast.com>
Jean-Francois=20 Mule' <jf.mule@cablelabs.com> =

------_=_NextPart_001_01C5EF06.83978A75-- --===============0561830631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0561830631==-- From ipcdn-bounces@ietf.org Mon Nov 21 20:48:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNGU-0004kj-66; Mon, 21 Nov 2005 20:48:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNGS-0004ke-8k for ipcdn@megatron.ietf.org; Mon, 21 Nov 2005 20:48:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15938 for ; Mon, 21 Nov 2005 20:47:29 -0500 (EST) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeNZ1-000661-3o for ipcdn@ietf.org; Mon, 21 Nov 2005 21:07:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Date: Mon, 21 Nov 2005 20:47:40 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73016B14C6@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Thread-Index: AcXu4uGjomuuwvp5R/SYr2ZJUz4lpgAAHU4gAAjVzgA= From: "Woundy, Richard" To: "Eugene Nechamkin" X-OriginalArrivalTime: 22 Nov 2005 01:47:42.0627 (UTC) FILETIME=[BA69DF30:01C5EF06] X-Spam-Score: 0.2 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Cc: Jean-Francois Mule , "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0237314173==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0237314173== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EF06.B92775D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EF06.B92775D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eugene, =20 I agree. =20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 4:39 PM To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 =20 During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: =20 - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=3D' in the Organization Name. =20 The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX SnmpAdminString(SIZE (1..255))=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute =20 as defined in the subject name of the service provider =20 certificate. The value of the organization name includes=20 the prefix 'O=3D'."=20 REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 }=20 =09 =09 =20 =20 To address these two comments, co-authors are proposing the following: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20 characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as=20 specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant=20 devices must support a maximum size of 384 octets for=20 pktcMtaDevRealmOrgName." =20 =20 Please feel free to provide comments on proposed modifications. =20 Regards, =20 Eugene Nechamkin. =20 ------_=_NextPart_001_01C5EF06.B92775D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Eugene,
 
I=20 agree.
 
--=20 Rich
-----Original Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of = Eugene Nechamkin
Sent: Monday, November 21, 2005 4:39=20 PM
To: Ipcdn (E-mail)
Cc: Jean-Francois=20 Mule
Subject: [ipcdn] Comments on = draft-ietf-ipcdn-pktc-mtamib-07=20 during the IETF-64 meeting

 
During the presentation of the=20 draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the = following=20 comments made on the presented = material:
 
    - the max length of = the=20 "pktcMtaDevRealmOrgName" currently defined as being 255 does not = correspond to=20 the actual number of octets the MIB object may contain which is = calculated as=20 max number of UTF-8 characters (64) each of which may consist of up to = 6=20 octets.
    - the value of the = MIB object=20 should not include the prefix 'O=3D' in the Organization=20 Name.
 
The current definition of the=20 "pktcMtaDevRealmOrgName" in the draft-07 is as=20 follows:
 
   = pktcMtaDevRealmOrgName =20 OBJECT-TYPE
      =20 SYNTAX      SnmpAdminString(SIZE (1..255))=20
       MAX-ACCESS  read-create=20
       = STATUS     =20 current
       DESCRIPTION=20
           " = This object=20 contains the X.500 organization name attribute =20 =
           &nb= sp;=20 as defined in the subject name of the service provider =20 =
           &nb= sp;=20 certificate. The value of the organization name includes=20 =
           &nb= sp;=20 the prefix 'O=3D'."
       REFERENCE =
           " = PacketCable=20 Security Specification."
       = ::=3D {=20 pktcMtaDevRealmEntry 5 }
 
 
To address these two = comments,=20 co-authors are proposing the = following:
 
=
1. Add the following to the = IMPORTS=20 section of the MTA MIB:
 
    LongUtf8String =20
           =20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify the definition of the = pktcMtaDevRealmOrgName=20 to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE=20
    SYNTAX LongUtf8String =
         ^^^^^^^^^^^
    MAX-ACCESS = read-create=20
    STATUS current=20
    DESCRIPTION=20
        " This=20 object contains the X.500 organization name attribute=20
        as=20 defined in the subject name of the service provider=20
        X.509=20 certificate."
    REFERENCE=20
        "=20 PacketCable Security Specification."
    ::=3D { = pktcMtaDevRealmEntry=20 5 }
 
3. Add the following compliance = statement to the MTA=20 MIB compliance section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String = (SIZE=20 (1..384))
   =20 DESCRIPTION
        "=20 Compliant devices are only required to = support
       =20 pktcMtaDevRealmOrgName values of 64 UTF-8 encoded =
       =20 characters.
        The=20 Organization Name of the X.509 certificate = can
        contain=20 up to 64 UTF-8 encoded characters as
        specified=20 in RFC 2459.
        Given=20 that, in UTF-8, characters are encoded = using
        sequences=20 of 1 to 6 octets (RFC 2279), compliant
        devices=20 must support a maximum size of 384 octets for =
       =20 pktcMtaDevRealmOrgName."
 
 
Please = feel free to=20 provide comments on proposed = modifications.
 
Regards,
 
Eugene = Nechamkin.
 
= ------_=_NextPart_001_01C5EF06.B92775D6-- --===============0237314173== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0237314173==-- From ipcdn-bounces@ietf.org Tue Nov 22 09:00:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYh5-000434-6U; Tue, 22 Nov 2005 09:00:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYh3-00042a-3H for ipcdn@megatron.ietf.org; Tue, 22 Nov 2005 09:00:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19864 for ; Tue, 22 Nov 2005 08:59:41 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeYzi-0004hM-6D for ipcdn@ietf.org; Tue, 22 Nov 2005 09:19:38 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAME06RK026593; Tue, 22 Nov 2005 08:00:07 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Nov 2005 14:59:43 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A4769F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eugene Nechamkin , "Ipcdn (E-mail)" Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Tue, 22 Nov 2005 14:59:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: Jean-Francois Mule X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1663932936==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1663932936== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EF6D.0490B6D6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5EF6D.0490B6D6 Content-Type: text/plain RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=' in the Organization Name. The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE (1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider certificate. The value of the organization name includes the prefix 'O='." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } To address these two comments, co-authors are proposing the following: 1. Add the following to the IMPORTS section of the MTA MIB: LongUtf8String FROM SYSAPPL-MIB -- [RFC2287] 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8String ^^^^^^^^^^^ MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider X.509 certificate." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } 3. Add the following compliance statement to the MTA MIB compliance section: OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant devices must support a maximum size of 384 octets for pktcMtaDevRealmOrgName." Please feel free to provide comments on proposed modifications. Regards, Eugene Nechamkin. ------_=_NextPart_001_01C5EF6D.0490B6D6 Content-Type: text/html
RFC2279 has been obsoleted by RFC3629. So I suggest you refer to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better to refer to
the new RFC!?
 
Bert
-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin
Sent: Monday, November 21, 2005 22:39
To: Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

 
During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material:
 
    - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets.
    - the value of the MIB object should not include the prefix 'O=' in the Organization Name.
 
The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows:
 
   pktcMtaDevRealmOrgName  OBJECT-TYPE
       SYNTAX      SnmpAdminString(SIZE (1..255))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           " This object contains the X.500 organization name attribute 
             as defined in the subject name of the service provider 
             certificate. The value of the organization name includes
             the prefix 'O='."
       REFERENCE
           " PacketCable Security Specification."
       ::= { pktcMtaDevRealmEntry 5 }
 
 
To address these two comments, co-authors are proposing the following:
 
1. Add the following to the IMPORTS section of the MTA MIB:
 
    LongUtf8String 
            FROM SYSAPPL-MIB                 -- [RFC2287]
 
2. Modify the definition of the pktcMtaDevRealmOrgName to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE
    SYNTAX LongUtf8String
         ^^^^^^^^^^^
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION
        " This object contains the X.500 organization name attribute
        as defined in the subject name of the service provider
        X.509 certificate."
    REFERENCE
        " PacketCable Security Specification."
    ::= { pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance statement to the MTA MIB compliance section:
 
    OBJECT pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE (1..384))
    DESCRIPTION
        " Compliant devices are only required to support
        pktcMtaDevRealmOrgName values of 64 UTF-8 encoded
        characters.
        The Organization Name of the X.509 certificate can
        contain up to 64 UTF-8 encoded characters as
        specified in RFC 2459.
        Given that, in UTF-8, characters are encoded using
        sequences of 1 to 6 octets (RFC 2279), compliant
        devices must support a maximum size of 384 octets for
        pktcMtaDevRealmOrgName."
 
 
Please feel free to provide comments on proposed modifications.
 
Regards,
 
Eugene Nechamkin.
 
------_=_NextPart_001_01C5EF6D.0490B6D6-- --===============1663932936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1663932936==-- From ipcdn-bounces@ietf.org Tue Nov 22 09:15:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYvW-0002R6-M5; Tue, 22 Nov 2005 09:15:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYvQ-0002Jy-Ag for ipcdn@megatron.ietf.org; Tue, 22 Nov 2005 09:15:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21520 for ; Tue, 22 Nov 2005 09:14:32 -0500 (EST) Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZE5-0005KI-8t for ipcdn@ietf.org; Tue, 22 Nov 2005 09:34:29 -0500 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.15082057; Tue, 22 Nov 2005 09:14:46 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 09:14:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Date: Tue, 22 Nov 2005 09:14:44 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73016B14C8@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Thread-Index: AcXvbaUc87HgdEfNQ4i1dO6ZiTP8mwAAFpoA From: "Woundy, Richard" To: "Wijnen, Bert \(Bert\)" , "Eugene Nechamkin" , "Ipcdn \(E-mail\)" X-OriginalArrivalTime: 22 Nov 2005 14:14:45.0204 (UTC) FILETIME=[16C05940:01C5EF6F] X-Spam-Score: 0.3 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Cc: Jean-Francois Mule , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1123414753==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1123414753== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EF6F.1642D3F7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EF6F.1642D3F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert, =20 I agree. =20 But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) =20 Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). =20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. =20 RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? =20 Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 =20 During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: =20 - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=3D' in the Organization Name. =20 The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX SnmpAdminString(SIZE (1..255))=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute =20 as defined in the subject name of the service provider =20 certificate. The value of the organization name includes=20 the prefix 'O=3D'."=20 REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 }=20 =09 =09 =20 =20 To address these two comments, co-authors are proposing the following: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20 characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as=20 specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant devices must support a maximum size of 384 octets for=20 pktcMtaDevRealmOrgName." =20 =20 Please feel free to provide comments on proposed modifications. =20 Regards, =20 Eugene Nechamkin. =20 ------_=_NextPart_001_01C5EF6F.1642D3F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Bert,
 
I=20 agree.
 
But=20 you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also=20 refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the = reason=20 why I referred to RFC2287 in my IPCDN meeting notes too, which is = something I=20 should correct.)
 
Looking quickly at the rest of the TC webpage, you might also = update=20 INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 = instead=20 of RFC2737bis).
 
--=20 Rich
-----Original Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of = Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 = 9:00=20 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc: = Jean-Francois=20 Mule
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you refer = to
the=20 newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better to = refer=20 to
the=20 new RFC!?
 
Bert
-----Original Message-----
From: = ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene=20 Nechamkin
Sent: Monday, November 21, 2005 = 22:39
To:=20 Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: = [ipcdn]=20 Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

 
During the presentation of the=20 draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the = following=20 comments made on the presented = material:
 
    - the max length of = the=20 "pktcMtaDevRealmOrgName" currently defined as being 255 does not = correspond=20 to the actual number of octets the MIB object may contain which is=20 calculated as max number of UTF-8 characters (64) each of which may = consist=20 of up to 6 octets.
    - the value of the = MIB object=20 should not include the prefix 'O=3D' in the Organization=20 Name.
 
The current definition of the=20 "pktcMtaDevRealmOrgName" in the draft-07 is as=20 follows:
 
   = pktcMtaDevRealmOrgName =20 OBJECT-TYPE
      =20 SYNTAX      SnmpAdminString(SIZE (1..255))=20
       MAX-ACCESS  = read-create=20
      =20 STATUS      current=20
       DESCRIPTION=20
           " = This=20 object contains the X.500 organization name attribute =20 =
           &nb= sp;=20 as defined in the subject name of the service provider =20 =
           &nb= sp;=20 certificate. The value of the organization name includes=20 =
           &nb= sp;=20 the prefix 'O=3D'."
       = REFERENCE=20
           "=20 PacketCable Security Specification."=20
       ::=3D { = pktcMtaDevRealmEntry 5 }=20
 
 
To address these two = comments,=20 co-authors are proposing the = following:
 
=
1. Add=20 the following to the IMPORTS section of the MTA=20 MIB:
 
    = LongUtf8String =20
           =20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify the definition of the = pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE=20
    SYNTAX = LongUtf8String=20
         ^^^^^^^^^^^
    MAX-ACCESS = read-create=20
    STATUS current=20
    DESCRIPTION=20
        " This=20 object contains the X.500 organization name attribute=20
        as=20 defined in the subject name of the service provider=20
        X.509=20 certificate."
    REFERENCE=20
        "=20 PacketCable Security Specification."
    ::=3D {=20 pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance = statement to the=20 MTA MIB compliance section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX = LongUtf8String (SIZE=20 (1..384))
   =20 DESCRIPTION
        "=20 Compliant devices are only required to = support
       =20 pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20
       =20 characters.
        The=20 Organization Name of the X.509 certificate = can
        contain=20 up to 64 UTF-8 encoded characters as
       =20 specified in RFC 2459.
        Given=20 that, in UTF-8, characters are encoded = using
       =20 sequences of 1 to 6 octets (RFC 2279), compliant =
        devices=20 must support a maximum size of 384 octets for =
       =20 pktcMtaDevRealmOrgName."
 
 
Please feel free to=20 provide comments on proposed=20 modifications.
 
Regards,
 
Eugene = Nechamkin.
 
------_=_NextPart_001_01C5EF6F.1642D3F7-- --===============1123414753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1123414753==-- From ipcdn-bounces@ietf.org Tue Nov 22 11:05:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeaec-0004xd-0D; Tue, 22 Nov 2005 11:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeaea-0004xV-DF for ipcdn@megatron.ietf.org; Tue, 22 Nov 2005 11:05:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05635 for ; Tue, 22 Nov 2005 11:05:18 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeaxG-00038d-Hb for ipcdn@ietf.org; Tue, 22 Nov 2005 11:25:15 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAMG5d1t021950; Tue, 22 Nov 2005 10:05:40 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Nov 2005 17:05:16 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47769@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Tue, 22 Nov 2005 17:05:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0084042158==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0084042158== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EF7E.8DB52E4A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5EF7E.8DB52E4A Content-Type: text/plain Mmm... 2287 is still ip to date. The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the TCs w.r.t. UTF-8. I have done the 4001 and 4133. Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, November 22, 2005 15:15 To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule; Woundy, Richard Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Bert, I agree. But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=' in the Organization Name. The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE (1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider certificate. The value of the organization name includes the prefix 'O='." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } To address these two comments, co-authors are proposing the following: 1. Add the following to the IMPORTS section of the MTA MIB: LongUtf8String FROM SYSAPPL-MIB -- [RFC2287] 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8String ^^^^^^^^^^^ MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider X.509 certificate." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } 3. Add the following compliance statement to the MTA MIB compliance section: OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant devices must support a maximum size of 384 octets for pktcMtaDevRealmOrgName." Please feel free to provide comments on proposed modifications. Regards, Eugene Nechamkin. ------_=_NextPart_001_01C5EF7E.8DB52E4A Content-Type: text/html Message
Mmm... 2287 is still ip to date.
The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the
TCs w.r.t. UTF-8.
 
I have done the 4001 and 4133.
 
Bert
 
 
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, November 22, 2005 15:15
To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule; Woundy, Richard
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

Bert,
 
I agree.
 
But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.)
 
Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis).
 
-- Rich
-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 9:00 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you refer to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better to refer to
the new RFC!?
 
Bert
-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin
Sent: Monday, November 21, 2005 22:39
To: Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

 
During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material:
 
    - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets.
    - the value of the MIB object should not include the prefix 'O=' in the Organization Name.
 
The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows:
 
   pktcMtaDevRealmOrgName  OBJECT-TYPE
       SYNTAX      SnmpAdminString(SIZE (1..255))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           " This object contains the X.500 organization name attribute 
             as defined in the subject name of the service provider 
             certificate. The value of the organization name includes
             the prefix 'O='."
       REFERENCE
           " PacketCable Security Specification."
       ::= { pktcMtaDevRealmEntry 5 }
 
 
To address these two comments, co-authors are proposing the following:
 
1. Add the following to the IMPORTS section of the MTA MIB:
 
    LongUtf8String 
            FROM SYSAPPL-MIB                 -- [RFC2287]
 
2. Modify the definition of the pktcMtaDevRealmOrgName to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE
    SYNTAX LongUtf8String
         ^^^^^^^^^^^
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION
        " This object contains the X.500 organization name attribute
        as defined in the subject name of the service provider
        X.509 certificate."
    REFERENCE
        " PacketCable Security Specification."
    ::= { pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance statement to the MTA MIB compliance section:
 
    OBJECT pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE (1..384))
    DESCRIPTION
        " Compliant devices are only required to support
        pktcMtaDevRealmOrgName values of 64 UTF-8 encoded
        characters.
        The Organization Name of the X.509 certificate can
        contain up to 64 UTF-8 encoded characters as
        specified in RFC 2459.
        Given that, in UTF-8, characters are encoded using
        sequences of 1 to 6 octets (RFC 2279), compliant
        devices must support a maximum size of 384 octets for
        pktcMtaDevRealmOrgName."
 
 
Please feel free to provide comments on proposed modifications.
 
Regards,
 
Eugene Nechamkin.
 
------_=_NextPart_001_01C5EF7E.8DB52E4A-- --===============0084042158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0084042158==-- From ipcdn-bounces@ietf.org Tue Nov 22 16:54:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeg68-0004gI-8Z; Tue, 22 Nov 2005 16:54:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeg65-0004fn-LS for ipcdn@megatron.ietf.org; Tue, 22 Nov 2005 16:54:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17522 for ; Tue, 22 Nov 2005 16:54:03 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EegOn-0007BR-MN for ipcdn@ietf.org; Tue, 22 Nov 2005 17:14:03 -0500 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 22 Nov 2005 13:54:16 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 22 Nov 2005 13:54:15 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CGE34407; Tue, 22 Nov 2005 13:54:10 -0800 (PST) Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA10336; Tue, 22 Nov 2005 13:54:09 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id jAMLs9ov021940; Tue, 22 Nov 2005 13:54:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Tue, 22 Nov 2005 13:54:13 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F4856413CA70@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Thread-Index: AcXvf0tlHSLiB8DHSUipv56Pfa5cdgAJdVZA From: "Eugene Nechamkin" To: "Wijnen, Bert (Bert)" , "Woundy, Richard" X-WSS-ID: 6F9D4C022JW780531-01-01 X-Spam-Score: 0.2 (/) X-Scan-Signature: 36fb8971d71ebf57e085db19461624e6 Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0531693938==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0531693938== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EFAF.442A12B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EFAF.442A12B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 Bert/Rich, =20 Thanks for your comments on the RFC updates - the RFC references should be updated. =20 However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets). =20 To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required). =20 =20 Therefore, the proposed modifications to the MTA draft would be as follows: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " As per RFC3280, Organization Name field in X.509=20 certificates can contain up to 64 UTF-8 encoded =20 characters. Therefore, compliant devices are only=20 required to support Organization Name values=20 of up to 64 UTF-8 characters. Given that the RFC3280 defines the UTF-8 encoding=20 per RFC2279, the compliant devices must support the maximum size of 384 octets for=20 pktcMtaDevRealmOrgName. The calculation of 384 octets=20 comes from the RFC2279 UTF-8 encoding definition whereby the UTF-8 characters are encoded as sequences of 1=20 to 6 octets." =20 =20 Eugene. =20 ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 8:05 AM To: Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Mmm... 2287 is still ip to date. The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the TCs w.r.t. UTF-8. =20 I have done the 4001 and 4133. =20 Bert =20 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, November 22, 2005 15:15 To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule; Woundy, Richard Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 Bert, =20 I agree. =20 But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) =20 Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). =20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. =20 RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? =20 Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 =20 During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: =20 - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=3D' in the Organization Name. =20 The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX SnmpAdminString(SIZE (1..255))=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute =20 as defined in the subject name of the service provider =20 certificate. The value of the organization name includes=20 the prefix 'O=3D'."=20 REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 }=20 =09 =09 =20 =20 To address these two comments, co-authors are proposing the following: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20 characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as=20 specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant=20 devices must support a maximum size of 384 octets for=20 pktcMtaDevRealmOrgName." =20 =20 Please feel free to provide comments on proposed modifications. =20 Regards, =20 Eugene Nechamkin. =20 ------_=_NextPart_001_01C5EFAF.442A12B5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
 
Bert/Rich,
 
Thanks for your comments on the RFC updates - = the RFC=20 references should be updated.
 
However, there is a caviat to that. The RFC3280 = itself is=20 still using the "obsolete" reference to the RFC2279 for UTF-8 definition = instead=20 of refering to the RFC3629. From the MTA MIB draft's prospective, = this=20 creates a potential compatibility problem for the MTAs, as RFC3629 = defines the=20 UTF-8 characters as being encoded into the sequencies of 1 to 4 octets = (instead=20 of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max = size of=20 the OrganizationName in X.509 certificates to be 384 octets (64 chars x = 6=20 octets), the MTA MIB would restrict the OrganizationName by 256 octets = (64 chars=20 x 4 octets).
 
To resolve this inconsistency, it might still = be worthwhile=20 to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of = changing it to=20 256. When RFC3280 is updated with the new reference to RFC3629, we'll be = able to=20 update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that = such an=20 update is=20 required).
 
 
Therefore, the proposed modifications to the = MTA draft=20 would be as follows:
 
1. Add the = following to=20 the IMPORTS section of the MTA = MIB:
 
    = LongUtf8String =20
          &nbs= p; FROM=20 SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify the = definition of=20 the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName = OBJECT-TYPE=20
    SYNTAX = LongUtf8String=20
         ^^^^^^^^^^= ^
    = MAX-ACCESS=20 read-create
    STATUS = current=20
    = DESCRIPTION=20
        " This object = contains the=20 X.500 organization name attribute
        as defined in the = subject name=20 of the service provider
        X.509=20 certificate."
    = REFERENCE=20
        " PacketCable = Security=20 Specification."
    ::=3D { = pktcMtaDevRealmEntry 5 }
 
3. Add the following = compliance=20 statement to the MTA MIB compliance section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX = LongUtf8String=20 (SIZE (1..384))
   =20 DESCRIPTION
        " As per RFC3280, Organization Name field in X.509
        certificates = can contain up to 64 UTF-8 = encoded =20
       =20 characters. Therefore, compliant = devices are=20 only
       =20 required to = support Organization Name values=20
       &nbs= p;of up to 64 UTF-8=20 characters<= SPAN=20 class=3D768370221-21112005>.
        Given that the = RFC3280 defines the UTF-8 encoding=20
       &nbs= p;per=20 RFC2279, the compliant devices=20 must
        support the maximum size of 384 octets for=20
        = pktcMtaDevRealmOrgName. The calculation of 384 octets=20
        comes from the RFC2279 UTF-8 encoding definition=20 whereby
       &nbs= p;the=20 UTF-8=20 characters are encoded as=20 sequences of 1=20
       &nbs= p;to=20 6 octets."
 
 
Eugene.
 

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert=20 (Bert)
Sent: Tuesday, November 22, 2005 8:05 AM
To: = Woundy,=20 Richard
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] = Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 = meeting

Mmm...=20 2287 is still ip to date.
The=20 RFC2279 has=20 been obsoleted by RFC3629, that is about UTF-8 itself, not about=20 the
TCs w.r.t. UTF-8.
 
I have done the 4001 and=20 4133.
 
Bert
 
 
-----Original Message-----
From: Woundy, Richard=20 [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, = November=20 22, 2005 15:15
To: Wijnen, Bert (Bert); Eugene Nechamkin; = Ipcdn=20 (E-mail)
Cc: Jean-Francois Mule; Woundy, = Richard
Subject:=20 RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the = IETF-64=20 meeting

Bert,
 
I=20 agree.
 
But=20 you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to = RFC2287 (instead of=20 RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to = RFC2287 in=20 my IPCDN meeting notes too, which is something I should=20 correct.)
 
Looking quickly at the rest of the TC webpage, you might also = update=20 INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB = (RFC4133=20 instead of RFC2737bis).
 
--=20 Rich
-----Original Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf = Of=20 Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 = 9:00=20 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc:=20 Jean-Francois Mule
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you = refer=20 to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better to = refer=20 to
the new RFC!?
 
Bert
-----Original Message-----
From: = ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene=20 Nechamkin
Sent: Monday, November 21, 2005 = 22:39
To:=20 Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: = [ipcdn]=20 Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

 
During the presentation of the = draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the = following comments made on the presented=20 material:
 
    - the max length = of the=20 "pktcMtaDevRealmOrgName" currently defined as being 255 does not=20 correspond to the actual number of octets the MIB object may = contain which=20 is calculated as max number of UTF-8 characters (64) each of which = may=20 consist of up to 6 octets.
    - the value of = the MIB object=20 should not include the prefix 'O=3D' in the Organization=20 Name.
 
The current definition of the=20 "pktcMtaDevRealmOrgName" in the draft-07 is as=20 follows:
 
   = pktcMtaDevRealmOrgName =20 OBJECT-TYPE
      =20 SYNTAX      SnmpAdminString(SIZE = (1..255))=20
       MAX-ACCESS  = read-create=20
      =20 STATUS      current=20
       DESCRIPTION=20
           " = This=20 object contains the X.500 organization name attribute =20 =
           &nb= sp;=20 as defined in the subject name of the service provider =20 =
           &nb= sp;=20 certificate. The value of the organization name includes=20 =
           &nb= sp;=20 the prefix 'O=3D'."
       = REFERENCE=20
           " = PacketCable Security Specification."=20
       ::=3D { = pktcMtaDevRealmEntry 5 }=20
 
 
To address these two = comments,=20 co-authors are proposing the = following:
 
=
1. Add=20 the following to the IMPORTS section of the MTA=20 MIB:
 
    = LongUtf8String =20
           =20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify the definition of = the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE=20
    SYNTAX = LongUtf8String=20
         ^^^^^^^^^^^
    MAX-ACCESS = read-create=20
    STATUS current=20
    DESCRIPTION=20
        "=20 This object contains the X.500 organization name attribute=20
        as=20 defined in the subject name of the service provider=20
        X.509=20 certificate."
    REFERENCE=20
        "=20 PacketCable Security Specification."
    ::=3D {=20 pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance = statement to the=20 MTA MIB compliance section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX = LongUtf8String (SIZE=20 (1..384))
   =20 DESCRIPTION
        "=20 Compliant devices are only required to = support
       =20 pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20
       =20 characters.
        The=20 Organization Name of the X.509 certificate = can
       =20 contain up to 64 UTF-8 encoded characters as =
       =20 specified in RFC 2459.
        Given=20 that, in UTF-8, characters are encoded = using
       =20 sequences of 1 to 6 octets (RFC 2279), compliant=20
       =20 devices must support a maximum size of 384 octets for=20
       =20 pktcMtaDevRealmOrgName."
 
 
Please feel free=20 to provide comments on proposed=20 modifications.
 
Regards,
 
Eugene = Nechamkin.
 
------_=_NextPart_001_01C5EFAF.442A12B5-- --===============0531693938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0531693938==-- From ipcdn-bounces@ietf.org Tue Nov 22 17:30:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EegfA-0005yh-BF; Tue, 22 Nov 2005 17:30:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eegf8-0005yW-53 for ipcdn@megatron.ietf.org; Tue, 22 Nov 2005 17:30:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21734 for ; Tue, 22 Nov 2005 17:30:15 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eegxr-0000eQ-99 for ipcdn@ietf.org; Tue, 22 Nov 2005 17:50:16 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAMMUVFx007680; Tue, 22 Nov 2005 16:30:31 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Nov 2005 23:30:06 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47828@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eugene Nechamkin , "Woundy, Richard" Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Tue, 22 Nov 2005 23:30:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.2 (/) X-Scan-Signature: f27aa5169a850f4f07ecb12d54c20028 Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1354384905==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1354384905== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EFB4.50E78D92" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5EFB4.50E78D92 Content-Type: text/plain You may want to check the wording a bit. I do not think it is valid to speak of "UTF-8 characters". You an speak of "UTF-8 encoded characters". Bert -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Tuesday, November 22, 2005 22:54 To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Bert/Rich, Thanks for your comments on the RFC updates - the RFC references should be updated. However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets). To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required). Therefore, the proposed modifications to the MTA draft would be as follows: 1. Add the following to the IMPORTS section of the MTA MIB: LongUtf8String FROM SYSAPPL-MIB -- [RFC2287] 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8String ^^^^^^^^^^^ MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider X.509 certificate." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } 3. Add the following compliance statement to the MTA MIB compliance section: OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " As per RFC3280, Organization Name field in X.509 certificates can contain up to 64 UTF-8 encoded characters. Therefore, compliant devices are only required to support Organization Name values of up to 64 UTF-8 characters. Given that the RFC3280 defines the UTF-8 encoding per RFC2279, the compliant devices must support the maximum size of 384 octets for pktcMtaDevRealmOrgName. The calculation of 384 octets comes from the RFC2279 UTF-8 encoding definition whereby the UTF-8 characters are encoded as sequences of 1 to 6 octets." Eugene. _____ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 8:05 AM To: Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Mmm... 2287 is still ip to date. The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the TCs w.r.t. UTF-8. I have done the 4001 and 4133. Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, November 22, 2005 15:15 To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule; Woundy, Richard Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Bert, I agree. But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=' in the Organization Name. The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE (1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider certificate. The value of the organization name includes the prefix 'O='." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } To address these two comments, co-authors are proposing the following: 1. Add the following to the IMPORTS section of the MTA MIB: LongUtf8String FROM SYSAPPL-MIB -- [RFC2287] 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8String ^^^^^^^^^^^ MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider X.509 certificate." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } 3. Add the following compliance statement to the MTA MIB compliance section: OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant devices must support a maximum size of 384 octets for pktcMtaDevRealmOrgName." Please feel free to provide comments on proposed modifications. Regards, Eugene Nechamkin. ------_=_NextPart_001_01C5EFB4.50E78D92 Content-Type: text/html Message
You may want to check the wording a bit.
I do not think it is valid to speak of "UTF-8 characters".
You an speak of "UTF-8 encoded characters".
 
Bert
-----Original Message-----
From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November 22, 2005 22:54
To: Wijnen, Bert (Bert); Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

 
Bert/Rich,
 
Thanks for your comments on the RFC updates - the RFC references should be updated.
 
However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets).
 
To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required).
 
 
Therefore, the proposed modifications to the MTA draft would be as follows:
 
1. Add the following to the IMPORTS section of the MTA MIB:
 
    LongUtf8String 
            FROM SYSAPPL-MIB                 -- [RFC2287]
 
2. Modify the definition of the pktcMtaDevRealmOrgName to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE
    SYNTAX LongUtf8String
         ^^^^^^^^^^^
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION
        " This object contains the X.500 organization name attribute
        as defined in the subject name of the service provider
        X.509 certificate."
    REFERENCE
        " PacketCable Security Specification."
    ::= { pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance statement to the MTA MIB compliance section:
 
    OBJECT pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE (1..384))
    DESCRIPTION
        " As per RFC3280, Organization Name field in X.509
        certificates can contain up to 64 UTF-8 encoded 
        characters. Therefore, compliant devices are only
        required to support Organization Name values
        of up to 64 UTF-8 characters.
        Given that the RFC3280 defines the UTF-8 encoding
        per RFC2279, the compliant devices must
        support the maximum size of 384 octets for
        pktcMtaDevRealmOrgName. The calculation of 384 octets
        comes from the RFC2279 UTF-8 encoding definition whereby
        the UTF-8 characters are encoded as sequences of 1
        to 6 octets."
 
 
Eugene.
 

From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 8:05 AM
To: Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

Mmm... 2287 is still ip to date.
The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the
TCs w.r.t. UTF-8.
 
I have done the 4001 and 4133.
 
Bert
 
 
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, November 22, 2005 15:15
To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule; Woundy, Richard
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

Bert,
 
I agree.
 
But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.)
 
Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis).
 
-- Rich
-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 9:00 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you refer to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better to refer to
the new RFC!?
 
Bert
-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin
Sent: Monday, November 21, 2005 22:39
To: Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

 
During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material:
 
    - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets.
    - the value of the MIB object should not include the prefix 'O=' in the Organization Name.
 
The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows:
 
   pktcMtaDevRealmOrgName  OBJECT-TYPE
       SYNTAX      SnmpAdminString(SIZE (1..255))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           " This object contains the X.500 organization name attribute 
             as defined in the subject name of the service provider 
             certificate. The value of the organization name includes
             the prefix 'O='."
       REFERENCE
           " PacketCable Security Specification."
       ::= { pktcMtaDevRealmEntry 5 }
 
 
To address these two comments, co-authors are proposing the following:
 
1. Add the following to the IMPORTS section of the MTA MIB:
 
    LongUtf8String 
            FROM SYSAPPL-MIB                 -- [RFC2287]
 
2. Modify the definition of the pktcMtaDevRealmOrgName to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE
    SYNTAX LongUtf8String
         ^^^^^^^^^^^
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION
        " This object contains the X.500 organization name attribute
        as defined in the subject name of the service provider
        X.509 certificate."
    REFERENCE
        " PacketCable Security Specification."
    ::= { pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance statement to the MTA MIB compliance section:
 
    OBJECT pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE (1..384))
    DESCRIPTION
        " Compliant devices are only required to support
        pktcMtaDevRealmOrgName values of 64 UTF-8 encoded
        characters.
        The Organization Name of the X.509 certificate can
        contain up to 64 UTF-8 encoded characters as
        specified in RFC 2459.
        Given that, in UTF-8, characters are encoded using
        sequences of 1 to 6 octets (RFC 2279), compliant
        devices must support a maximum size of 384 octets for
        pktcMtaDevRealmOrgName."
 
 
Please feel free to provide comments on proposed modifications.
 
Regards,
 
Eugene Nechamkin.
 
------_=_NextPart_001_01C5EFB4.50E78D92-- --===============1354384905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1354384905==-- From ipcdn-bounces@ietf.org Tue Nov 22 17:47:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EegvW-0006F7-5b; Tue, 22 Nov 2005 17:47:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EegvU-0006DN-7y for ipcdn@megatron.ietf.org; Tue, 22 Nov 2005 17:47:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23766 for ; Tue, 22 Nov 2005 17:47:09 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EehEB-0001gC-4i for ipcdn@ietf.org; Tue, 22 Nov 2005 18:07:10 -0500 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 22 Nov 2005 14:47:26 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 22 Nov 2005 14:47:26 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CGE46572; Tue, 22 Nov 2005 14:47:23 -0800 (PST) Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA24994; Tue, 22 Nov 2005 14:47:22 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id jAMMlCox025736; Tue, 22 Nov 2005 14:47:16 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Tue, 22 Nov 2005 14:47:16 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F4856413CA96@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Thread-Index: AcXvtGiPXlTrcAyyQAKY91EFglIybAAAUlnQ From: "Eugene Nechamkin" To: "Wijnen, Bert (Bert)" , "Woundy, Richard" X-WSS-ID: 6F9D40742JW797844-01-01 X-Spam-Score: 0.3 (/) X-Scan-Signature: 654d8dea790bc7609adc97f133706ab1 Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1381957887==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1381957887== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EFB6.AF886456" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EFB6.AF886456 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:" =20 Unless there is some other supporting references, the existing wording in the proposed draft's modifications seems to be in-line with the RFC terminology and should be fine to use. =20 Eugene. ________________________________ From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, November 22, 2005 2:30 PM To: Eugene Nechamkin; Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting You may want to check the wording a bit. I do not think it is valid to speak of "UTF-8 characters". You an speak of "UTF-8 encoded characters". =20 Bert -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Tuesday, November 22, 2005 22:54 To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 =20 Bert/Rich, =20 Thanks for your comments on the RFC updates - the RFC references should be updated. =20 However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets). =20 To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required). =20 =20 Therefore, the proposed modifications to the MTA draft would be as follows: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " As per RFC3280, Organization Name field in X.509=20 certificates can contain up to 64 UTF-8 encoded =20 characters. Therefore, compliant devices are only=20 required to support Organization Name values=20 of up to 64 UTF-8 characters. Given that the RFC3280 defines the UTF-8 encoding=20 per RFC2279, the compliant devices must support the maximum size of 384 octets for=20 pktcMtaDevRealmOrgName. The calculation of 384 octets=20 =09 comes from the RFC2279 UTF-8 encoding definition whereby the UTF-8 characters are encoded as sequences of 1=20 to 6 octets." =20 =20 Eugene. =20 ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 8:05 AM To: Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 Mmm... 2287 is still ip to date. The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the TCs w.r.t. UTF-8. =20 I have done the 4001 and 4133. =20 Bert =20 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, November 22, 2005 15:15 To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule; Woundy, Richard Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 Bert, =20 I agree. =20 But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) =20 Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). =20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. =20 RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? =20 Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 =20 During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: =20 - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=3D' in the Organization Name. =20 The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX SnmpAdminString(SIZE (1..255))=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute =20 as defined in the subject name of the service provider =20 certificate. The value of the organization name includes=20 the prefix 'O=3D'."=20 REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 }=20 =09 =09 =20 =20 To address these two comments, co-authors are proposing the following: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20 characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as=20 specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant=20 devices must support a maximum size of 384 octets for=20 pktcMtaDevRealmOrgName." =20 =20 Please feel free to provide comments on proposed modifications. =20 Regards, =20 Eugene Nechamkin. =20 ------_=_NextPart_001_01C5EFB6.AF886456 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
 
Not sure about that... From the RFC-3629: = "Decoding a UTF-8 character proceeds as=20 follows:"
 
Unless=20 there is some other supporting references, the existing wording in the = proposed=20 draft's modifications seems to be in-line with the RFC terminology and = should be=20 fine to use.
 
Eugene.
From: Wijnen, Bert (Bert)=20 [mailto:bwijnen@lucent.com]
Sent: Tuesday, November 22, 2005 = 2:30=20 PM
To: Eugene Nechamkin; Woundy, Richard
Cc: Ipcdn=20 (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 = meeting

You=20 may want to check the wording a bit.
I do=20 not think it is valid to speak of "UTF-8 = characters".
You an=20 speak of "UTF-8 encoded characters".
 
Bert
-----Original Message-----
From: Eugene Nechamkin=20 [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November 22, = 2005=20 22:54
To: Wijnen, Bert (Bert); Woundy, Richard
Cc: = Ipcdn=20 (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

 
Bert/Rich,
 
Thanks for your comments = on the RFC=20 updates - the RFC references should be updated.
 
However, there is a = caviat to that.=20 The RFC3280 itself is still using the "obsolete" reference to the = RFC2279 for=20 UTF-8 definition instead of refering to the RFC3629. From the MTA = MIB=20 draft's prospective, this creates a potential compatibility problem = for the=20 MTAs, as RFC3629 defines the UTF-8 characters as being encoded into = the=20 sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in = RFC2279).=20 While RFC3280 would allow the max size of the OrganizationName in = X.509=20 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would = restrict the OrganizationName by 256 octets (64 chars x 4=20 octets).
 
To resolve this = inconsistency, it=20 might still be worthwhile to keep the 384 octets restriction on the = size of=20 the pktcMtaDevRealmOrgName = object instead=20 of changing it to 256. When RFC3280 is updated with the new reference = to=20 RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName = object (if=20 decided at this moment that such an update is=20 = required).
 
 
Therefore, the proposed = modifications=20 to the MTA draft would be as follows:
 
1. Add the = following to=20 the IMPORTS section of the MTA = MIB:
 
   =20 LongUtf8String 
          &nbs= p; FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify = the definition=20 of the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName = OBJECT-TYPE=20
    = SYNTAX=20 LongUtf8String
         ^^^^^^^^^^= ^
    = MAX-ACCESS=20 read-create
    = STATUS current=20
    = DESCRIPTION=20
        " This object = contains the=20 X.500 organization name attribute
        as defined in the = subject=20 name of the service provider
        X.509=20 certificate."
    = REFERENCE=20
        " PacketCable = Security=20 Specification."
    ::=3D = {=20 pktcMtaDevRealmEntry 5 }
 
3. Add the following = compliance=20 statement to the MTA MIB compliance = section:
 
    = OBJECT=20 pktcMtaDevRealmOrgName
    = SYNTAX=20 LongUtf8String (SIZE (1..384))
   =20 DESCRIPTION
        " As per RFC3280, Organization Name field in X.509=20
        certificates = can contain up to 64 UTF-8 = encoded =20
       =20 characters. Therefore, compliant = devices are=20 only
       =20 required to=20 support Organization Name values =
       &nbs= p;of up to 64 UTF-8=20 characters<= SPAN=20 class=3D768370221-21112005>.
        Given that = the RFC3280 defines the UTF-8 encoding=20
       &nbs= p;per=20 RFC2279, the compliant devices=20 must
        support the maximum size of 384 octets for=20
        = pktcMtaDevRealmOrgName. The calculation of 384 octets=20
        comes from the RFC2279 UTF-8 encoding definition=20 whereby
       &nbs= p;the=20 UTF-8=20 characters are encoded as = sequences of 1=20
       &nbs= p;to=20 6 octets."
 
 
Eugene.
 

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert=20 (Bert)
Sent: Tuesday, November 22, 2005 8:05 = AM
To:=20 Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: = [ipcdn]=20 Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

Mmm... 2287 is still ip to date.
The=20 RFC2279=20 has been obsoleted by RFC3629, that is about UTF-8 itself, not about=20 the
TCs w.r.t.=20 UTF-8.
 
I have done the 4001 and=20 4133.
 
Bert
 
 
-----Original Message-----
From: Woundy, Richard=20 [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, = November=20 22, 2005 15:15
To: Wijnen, Bert (Bert); Eugene Nechamkin; = Ipcdn=20 (E-mail)
Cc: Jean-Francois Mule; Woundy,=20 Richard
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

Bert,
 
I=20 agree.
 
But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It=20 also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. = (That's the=20 reason why I referred to RFC2287 in my IPCDN meeting notes too, = which is=20 something I should correct.)
 
Looking quickly at the rest of the TC webpage, you might = also update=20 INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB = (RFC4133=20 instead of RFC2737bis).
 
--=20 Rich
-----Original Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On = Behalf Of=20 Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 = 9:00=20 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc:=20 Jean-Francois Mule
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you = refer=20 to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better to = refer=20 to
the new RFC!?
 
Bert
-----Original Message-----
From: = ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene=20 Nechamkin
Sent: Monday, November 21, 2005 = 22:39
To:=20 Ipcdn (E-mail)
Cc: Jean-Francois = Mule
Subject:=20 [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the = IETF-64=20 meeting

 
During the presentation of = the=20 draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were = the=20 following comments made on the presented=20 material:
 
    - the max = length of the=20 "pktcMtaDevRealmOrgName" currently defined as being 255 does not = correspond to the actual number of octets the MIB object may = contain=20 which is calculated as max number of UTF-8 characters (64) each = of which=20 may consist of up to 6 octets.
    - the value of = the MIB=20 object should not include the prefix 'O=3D' in the Organization=20 Name.
 
The current definition of the=20 "pktcMtaDevRealmOrgName" in the draft-07 is as=20 follows:
 
   = pktcMtaDevRealmOrgName =20 OBJECT-TYPE
      =20 SYNTAX      SnmpAdminString(SIZE = (1..255))=20
       MAX-ACCESS  = read-create=20
      =20 STATUS      current=20
       DESCRIPTION=20
           = " This=20 object contains the X.500 organization name attribute =20 =
           &nb= sp;=20 as defined in the subject name of the service provider =20 =
           &nb= sp;=20 certificate. The value of the organization name includes=20 =
           &nb= sp;=20 the prefix 'O=3D'."
       = REFERENCE=20
           = "=20 PacketCable Security Specification."=20
       ::=3D { = pktcMtaDevRealmEntry 5 }=20
 
 
To address these two = comments,=20 co-authors are proposing the=20 following:
 
=
1.=20 Add the following to the IMPORTS section of the MTA=20 MIB:
 
    = LongUtf8String =20
           =20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify the definition of = the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE =
    SYNTAX = LongUtf8String=20
         ^^^^^^^^^^^
    MAX-ACCESS = read-create=20
    STATUS current=20
    DESCRIPTION=20
        "=20 This object contains the X.500 organization name attribute=20
        as=20 defined in the subject name of the service provider=20
       =20 X.509 certificate."
    REFERENCE=20
        "=20 PacketCable Security Specification."
    ::=3D {=20 pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance = statement to=20 the MTA MIB compliance section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX = LongUtf8String (SIZE=20 (1..384))
   =20 DESCRIPTION
        "=20 Compliant devices are only required to=20 support
       =20 pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20
       =20 characters.
        The=20 Organization Name of the X.509 certificate=20 can
       =20 contain up to 64 UTF-8 encoded characters as =
       =20 specified in RFC 2459.
       =20 Given that, in UTF-8, characters are encoded=20 using
       =20 sequences of 1 to 6 octets (RFC 2279), compliant=20
       =20 devices must support a maximum size of 384 octets for=20
       =20 pktcMtaDevRealmOrgName."
 
 
Please feel=20 free to provide comments on proposed=20 modifications.
 
Regards,
 
Eugene = Nechamkin.
 
------_=_NextPart_001_01C5EFB6.AF886456-- --===============1381957887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1381957887==-- From ipcdn-bounces@ietf.org Tue Nov 22 19:30:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeiWa-000364-3Q; Tue, 22 Nov 2005 19:30:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeiWY-00035U-68 for ipcdn@megatron.ietf.org; Tue, 22 Nov 2005 19:30:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07572 for ; Tue, 22 Nov 2005 19:29:31 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeipE-0000Ci-VW for ipcdn@ietf.org; Tue, 22 Nov 2005 19:49:30 -0500 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.15202102; Tue, 22 Nov 2005 19:29:28 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 19:29:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Tue, 22 Nov 2005 19:29:37 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73016B14E3@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Thread-Index: AcXvtGiPXlTrcAyyQAKY91EFglIybAAAUlnQAAN+2QA= From: "Woundy, Richard" To: "Eugene Nechamkin" , "Wijnen, Bert \(Bert\)" X-OriginalArrivalTime: 23 Nov 2005 00:29:35.0151 (UTC) FILETIME=[FADF8BF0:01C5EFC4] X-Spam-Score: 0.3 (/) X-Scan-Signature: fcb81a552e93de47ff406e53e992da89 Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0629833056==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0629833056== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EFC4.FC0B8728" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EFC4.FC0B8728 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:" =20 But also from RFC3629: "US-ASCII octet values do not appear otherwise in a UTF-8 encoded character stream." It doesn't say "UTF-8 character stream". =20 I personally like the phrase "UTF-8 encoded characters" but I know I am not an authority on this. =20 The ironic part is that the compliance DESCRIPTION below uses both forms. :^) =20 As per RFC3280, Organization Name field in X.509=20 certificates can contain up to 64 UTF-8 encoded =20 characters. Therefore, compliant devices are only=20 required to support Organization Name values=20 of up to 64 UTF-8 characters. =20 -- Rich -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Tuesday, November 22, 2005 5:47 PM To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 =20 Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:" =20 Unless there is some other supporting references, the existing wording in the proposed draft's modifications seems to be in-line with the RFC terminology and should be fine to use. =20 Eugene. =09 ________________________________ From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, November 22, 2005 2:30 PM To: Eugene Nechamkin; Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 You may want to check the wording a bit. I do not think it is valid to speak of "UTF-8 characters". You an speak of "UTF-8 encoded characters". =20 Bert -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Tuesday, November 22, 2005 22:54 To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 =20 Bert/Rich, =20 Thanks for your comments on the RFC updates - the RFC references should be updated. =20 However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets). =20 To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required). =20 =20 Therefore, the proposed modifications to the MTA draft would be as follows: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " As per RFC3280, Organization Name field in X.509=20 certificates can contain up to 64 UTF-8 encoded characters. Therefore, compliant devices are only=20 required to support Organization Name values=20 of up to 64 UTF-8 characters. Given that the RFC3280 defines the UTF-8 encoding=20 per RFC2279, the compliant devices must support the maximum size of 384 octets for=20 pktcMtaDevRealmOrgName. The calculation of 384 octets=20 =09 comes from the RFC2279 UTF-8 encoding definition whereby the UTF-8 characters are encoded as sequences of 1=20 to 6 octets." =20 =20 Eugene. =20 ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 8:05 AM To: Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 Mmm... 2287 is still ip to date. The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the TCs w.r.t. UTF-8. =20 I have done the 4001 and 4133. =20 Bert =20 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, November 22, 2005 15:15 To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule; Woundy, Richard Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 Bert, =20 I agree. =20 But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) =20 Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). =20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. =20 RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? =20 Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 =20 During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: =20 - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=3D' in the Organization Name. =20 The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX SnmpAdminString(SIZE (1..255))=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute =20 as defined in the subject name of the service provider =20 certificate. The value of the organization name includes=20 the prefix 'O=3D'."=20 REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 }=20 =09 =09 =20 =20 To address these two comments, co-authors are proposing the following: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20 characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as=20 specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant=20 devices must support a maximum size of 384 octets for=20 pktcMtaDevRealmOrgName." =20 =20 Please feel free to provide comments on proposed modifications. =20 Regards, =20 Eugene Nechamkin. =20 ------_=_NextPart_001_01C5EFC4.FC0B8728 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
>Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as=20 follows:"
 
But=20 also from RFC3629: "US-ASCII octet values = do not=20 appear otherwise in a UTF-8 encoded character stream." It = doesn't=20 say "UTF-8 character=20 stream".
 
I=20 personally like the phrase "UTF-8 encoded characters" but I = know I am=20 not an authority on this.
 
The=20 ironic part is that the compliance DESCRIPTION below uses = both=20 forms. :^)
 
        As per=20 RFC3280, Organization = Name field in X.509=20
        certificates = can contain up to 64 UTF-8 = encoded =20
       =20 characters. Therefore, compliant = devices are=20 only
       =20 required to support Organization Name values=20
       &nbs= p;of up to 64 UTF-8 = characters.
 
--=20 Rich
-----Original Message-----
From: = Eugene Nechamkin=20 [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November = 22, 2005=20 5:47 PM
To: Wijnen, Bert (Bert); Woundy, = Richard
Cc: Ipcdn=20 (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

 
Not sure about that... From the RFC-3629: = "Decoding a UTF-8 character proceeds as=20 follows:"
 
Unless there is some other supporting references, the = existing wording=20 in the proposed draft's modifications seems to be in-line with the RFC = terminology and should be fine to use.
 
Eugene.
From: Wijnen, Bert (Bert)=20 [mailto:bwijnen@lucent.com]
Sent: Tuesday, November 22, = 2005 2:30=20 PM
To: Eugene Nechamkin; Woundy, Richard
Cc: Ipcdn = (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

You=20 may want to check the wording a bit.
I do=20 not think it is valid to speak of "UTF-8 = characters".
You=20 an speak of "UTF-8 encoded characters".
 
Bert
-----Original Message-----
From: Eugene Nechamkin = [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November = 22, 2005=20 22:54
To: Wijnen, Bert (Bert); Woundy, = Richard
Cc: Ipcdn=20 (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

 
Bert/Rich,
 
Thanks for your = comments on the RFC=20 updates - the RFC references should be updated.
 
However, there is a = caviat to that.=20 The RFC3280 itself is still using the "obsolete" reference to the = RFC2279=20 for UTF-8 definition instead of refering to the RFC3629. From = the MTA=20 MIB draft's prospective, this creates a potential compatibility = problem for=20 the MTAs, as RFC3629 defines the UTF-8 characters as being encoded = into the=20 sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in = RFC2279).=20 While RFC3280 would allow the max size of the OrganizationName in = X.509=20 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB = would=20 restrict the OrganizationName by 256 octets (64 chars x 4=20 octets).
 
To resolve this = inconsistency, it=20 might still be worthwhile to keep the 384 octets restriction on the = size of=20 the pktcMtaDevRealmOrgName = object=20 instead of changing it to 256. When RFC3280 is updated with the new=20 reference to RFC3629, we'll be able to update the compliance = statement for=20 pktcMtaDevRealmOrgName = object (if=20 decided at this moment that such an update is=20 = required).
 
 
Therefore, the = proposed=20 modifications to the MTA draft would be as = follows:
 
1. Add the = following=20 to the IMPORTS section of the MTA=20 MIB:
 
   =20 LongUtf8String 
          &nbs= p;=20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify = the definition=20 of the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName = OBJECT-TYPE=20
    = SYNTAX=20 LongUtf8String
         ^^^^^^^^^^= ^
    = MAX-ACCESS=20 read-create
    = STATUS current=20
    = DESCRIPTION=20
        " This object = contains the=20 X.500 organization name attribute
        as defined in = the subject=20 name of the service provider
        X.509=20 certificate."
    = REFERENCE=20
        " PacketCable = Security=20 Specification."
    = ::=3D {=20 pktcMtaDevRealmEntry 5 }
 
3. Add the following = compliance=20 statement to the MTA MIB compliance = section:
 
    = OBJECT=20 pktcMtaDevRealmOrgName
    = SYNTAX=20 LongUtf8String (SIZE (1..384))
   =20 DESCRIPTION
        " As per RFC3280, Organization Name field in X.509=20
        certificates = can contain up to 64 = UTF-8=20 encoded 
       =20 characters. Therefore, compliant = devices=20 are only
       =20 required to=20 support Organization = Name values=20
       &nbs= p;of up to 64 UTF-8=20 characters<= SPAN=20 class=3D768370221-21112005>.
        Given that = the=20 RFC3280 defines the UTF-8 encoding=20
       &nbs= p;per=20 RFC2279, the compliant devices=20 must
        = support the maximum size of 384 octets for =
       =20 pktcMtaDevRealmOrgName. The = calculation of=20 384 octets
        comes from the RFC2279 UTF-8 encoding = definition=20 whereby
       &nbs= p;the=20 UTF-8=20 characters are encoded as=20 sequences of 1=20
       &nbs= p;to=20 6 octets."
 
 
Eugene.
 

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert=20 (Bert)
Sent: Tuesday, November 22, 2005 8:05 = AM
To:=20 Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: = [ipcdn]=20 Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

Mmm... 2287 is still ip to date.
The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 = itself,=20 not about the
TCs w.r.t.=20 UTF-8.
 
I have done the 4001 and=20 4133.
 
Bert
 
 
-----Original Message-----
From: Woundy, = Richard=20 [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, = November 22, 2005 15:15
To: Wijnen, Bert (Bert); Eugene=20 Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule; = Woundy,=20 Richard
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

Bert,
 
I agree.
 
But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It=20 also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. = (That's=20 the reason why I referred to RFC2287 in my IPCDN meeting notes = too, which=20 is something I should correct.)
 
Looking quickly at the rest of the TC webpage, you might = also=20 update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and = ENTITY-MIB=20 (RFC4133 instead of RFC2737bis).
 
-- Rich
-----Original = Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On = Behalf Of=20 Wijnen, Bert (Bert)
Sent: Tuesday, November 22, = 2005 9:00=20 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc:=20 Jean-Francois Mule
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you = refer=20 to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better = to refer=20 to
the new RFC!?
 
Bert
-----Original Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On = Behalf Of=20 Eugene Nechamkin
Sent: Monday, November 21, 2005 = 22:39
To: Ipcdn (E-mail)
Cc: Jean-Francois = Mule
Subject: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

 
During=20 the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at = IETF-64=20 meeting, there were the following comments made on the = presented=20 material:
 
    - the max length of the=20 "pktcMtaDevRealmOrgName" currently defined as being 255 does = not=20 correspond to the actual number of octets the MIB object may = contain=20 which is calculated as max number of UTF-8 characters (64) = each of=20 which may consist of up to 6 = octets.
    - the value of the MIB object = should not=20 include the prefix 'O=3D' in the Organization=20 Name.
 
The current=20 definition of the "pktcMtaDevRealmOrgName" in the draft-07 is = as=20 follows:
 
  =20 pktcMtaDevRealmOrgName  OBJECT-TYPE=20
      =20 SYNTAX      SnmpAdminString(SIZE = (1..255))=20
       MAX-ACCESS  = read-create=20
      =20 STATUS      current=20
       DESCRIPTION=20 =
           "=20 This object contains the X.500 organization name = attribute =20 =
           &nb= sp;=20 as defined in the subject name of the service provider =20 =
           &nb= sp;=20 certificate. The value of the organization name includes=20 =
           &nb= sp;=20 the prefix 'O=3D'."
       = REFERENCE=20 =
           "=20 PacketCable Security Specification."=20
       ::=3D { = pktcMtaDevRealmEntry 5=20 }
 
 
To address these two = comments,=20 co-authors are proposing the=20 following:
 
=
1.=20 Add the following to the IMPORTS section of the MTA=20 MIB:
 
    LongUtf8String =20
           =20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2.=20 Modify the definition of the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE =
    SYNTAX LongUtf8String=20
         ^^^^^^^^^^^
    MAX-ACCESS read-create=20
    STATUS current =
    DESCRIPTION =
        " This = object=20 contains the X.500 organization name attribute=20
        as defined = in the=20 subject name of the service provider =
        X.509=20 certificate."
    REFERENCE =
        " = PacketCable=20 Security Specification."
    ::=3D { = pktcMtaDevRealmEntry 5=20 }
 
3. Add the=20 following compliance statement to the MTA MIB compliance=20 section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE=20 (1..384))
    = DESCRIPTION
        " = Compliant devices=20 are only required to support
       =20 pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20
       =20 characters.
        The = Organization=20 Name of the X.509 certificate can
        contain up = to 64=20 UTF-8 encoded characters as
        specified = in RFC=20 2459.
        Given = that, in=20 UTF-8, characters are encoded using
        sequences = of 1 to 6=20 octets (RFC 2279), compliant
        devices = must support=20 a maximum size of 384 octets for
       =20 pktcMtaDevRealmOrgName."
 
 
Please feel free to provide = comments on=20 proposed modifications.
 
Regards,
 
Eugene=20 Nechamkin.
 
------_=_NextPart_001_01C5EFC4.FC0B8728-- --===============0629833056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0629833056==-- From ipcdn-bounces@ietf.org Wed Nov 23 05:55:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EesI5-0000zM-C5; Wed, 23 Nov 2005 05:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EesI3-0000uA-Dt for ipcdn@megatron.ietf.org; Wed, 23 Nov 2005 05:55:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12917 for ; Wed, 23 Nov 2005 05:55:12 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eesas-0001JR-RM for ipcdn@ietf.org; Wed, 23 Nov 2005 06:15:20 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jANAtEx1006205; Wed, 23 Nov 2005 04:55:15 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Nov 2005 11:54:47 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A47A03@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" , Eugene Nechamkin Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Wed, 23 Nov 2005 11:55:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: acbee687725127cbf106f41c48a81403 Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0361825980==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0361825980== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F01C.5EE1A988" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5F01C.5EE1A988 Content-Type: text/plain Right. And (if only for consistency) I would just use "UTF-8 encoded character" Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, November 23, 2005 01:30 To: Eugene Nechamkin; Wijnen, Bert (Bert) Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting >Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:" But also from RFC3629: "US-ASCII octet values do not appear otherwise in a UTF-8 encoded character stream." It doesn't say "UTF-8 character stream". I personally like the phrase "UTF-8 encoded characters" but I know I am not an authority on this. The ironic part is that the compliance DESCRIPTION below uses both forms. :^) As per RFC3280, Organization Name field in X.509 certificates can contain up to 64 UTF-8 encoded characters. Therefore, compliant devices are only required to support Organization Name values of up to 64 UTF-8 characters. -- Rich -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Tuesday, November 22, 2005 5:47 PM To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:" Unless there is some other supporting references, the existing wording in the proposed draft's modifications seems to be in-line with the RFC terminology and should be fine to use. Eugene. _____ From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, November 22, 2005 2:30 PM To: Eugene Nechamkin; Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting You may want to check the wording a bit. I do not think it is valid to speak of "UTF-8 characters". You an speak of "UTF-8 encoded characters". Bert -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Tuesday, November 22, 2005 22:54 To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Bert/Rich, Thanks for your comments on the RFC updates - the RFC references should be updated. However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets). To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required). Therefore, the proposed modifications to the MTA draft would be as follows: 1. Add the following to the IMPORTS section of the MTA MIB: LongUtf8String FROM SYSAPPL-MIB -- [RFC2287] 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8String ^^^^^^^^^^^ MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider X.509 certificate." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } 3. Add the following compliance statement to the MTA MIB compliance section: OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " As per RFC3280, Organization Name field in X.509 certificates can contain up to 64 UTF-8 encoded characters. Therefore, compliant devices are only required to support Organization Name values of up to 64 UTF-8 characters. Given that the RFC3280 defines the UTF-8 encoding per RFC2279, the compliant devices must support the maximum size of 384 octets for pktcMtaDevRealmOrgName. The calculation of 384 octets comes from the RFC2279 UTF-8 encoding definition whereby the UTF-8 characters are encoded as sequences of 1 to 6 octets." Eugene. _____ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 8:05 AM To: Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Mmm... 2287 is still ip to date. The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the TCs w.r.t. UTF-8. I have done the 4001 and 4133. Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, November 22, 2005 15:15 To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule; Woundy, Richard Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting Bert, I agree. But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=' in the Organization Name. The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE (1..255)) MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider certificate. The value of the organization name includes the prefix 'O='." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } To address these two comments, co-authors are proposing the following: 1. Add the following to the IMPORTS section of the MTA MIB: LongUtf8String FROM SYSAPPL-MIB -- [RFC2287] 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8String ^^^^^^^^^^^ MAX-ACCESS read-create STATUS current DESCRIPTION " This object contains the X.500 organization name attribute as defined in the subject name of the service provider X.509 certificate." REFERENCE " PacketCable Security Specification." ::= { pktcMtaDevRealmEntry 5 } 3. Add the following compliance statement to the MTA MIB compliance section: OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant devices must support a maximum size of 384 octets for pktcMtaDevRealmOrgName." Please feel free to provide comments on proposed modifications. Regards, Eugene Nechamkin. ------_=_NextPart_001_01C5F01C.5EE1A988 Content-Type: text/html Message
Right. And (if only for consistency) I would just use "UTF-8 encoded character"
 
Bert
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, November 23, 2005 01:30
To: Eugene Nechamkin; Wijnen, Bert (Bert)
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

>Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:"
 
But also from RFC3629: "US-ASCII octet values do not appear otherwise in a UTF-8 encoded character stream." It doesn't say "UTF-8 character stream".
 
I personally like the phrase "UTF-8 encoded characters" but I know I am not an authority on this.
 
The ironic part is that the compliance DESCRIPTION below uses both forms. :^)
 
        As per RFC3280, Organization Name field in X.509
        certificates can contain up to 64 UTF-8 encoded 
        characters. Therefore, compliant devices are only
        required to support Organization Name values
        of up to 64 UTF-8 characters.
 
-- Rich
-----Original Message-----
From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November 22, 2005 5:47 PM
To: Wijnen, Bert (Bert); Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

 
Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:"
 
Unless there is some other supporting references, the existing wording in the proposed draft's modifications seems to be in-line with the RFC terminology and should be fine to use.
 
Eugene.
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Tuesday, November 22, 2005 2:30 PM
To: Eugene Nechamkin; Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

You may want to check the wording a bit.
I do not think it is valid to speak of "UTF-8 characters".
You an speak of "UTF-8 encoded characters".
 
Bert
-----Original Message-----
From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November 22, 2005 22:54
To: Wijnen, Bert (Bert); Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

 
Bert/Rich,
 
Thanks for your comments on the RFC updates - the RFC references should be updated.
 
However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets).
 
To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required).
 
 
Therefore, the proposed modifications to the MTA draft would be as follows:
 
1. Add the following to the IMPORTS section of the MTA MIB:
 
    LongUtf8String 
            FROM SYSAPPL-MIB                 -- [RFC2287]
 
2. Modify the definition of the pktcMtaDevRealmOrgName to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE
    SYNTAX LongUtf8String
         ^^^^^^^^^^^
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION
        " This object contains the X.500 organization name attribute
        as defined in the subject name of the service provider
        X.509 certificate."
    REFERENCE
        " PacketCable Security Specification."
    ::= { pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance statement to the MTA MIB compliance section:
 
    OBJECT pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE (1..384))
    DESCRIPTION
        " As per RFC3280, Organization Name field in X.509
        certificates can contain up to 64 UTF-8 encoded 
        characters. Therefore, compliant devices are only
        required to support Organization Name values
        of up to 64 UTF-8 characters.
        Given that the RFC3280 defines the UTF-8 encoding
        per RFC2279, the compliant devices must
        support the maximum size of 384 octets for
        pktcMtaDevRealmOrgName. The calculation of 384 octets
        comes from the RFC2279 UTF-8 encoding definition whereby
        the UTF-8 characters are encoded as sequences of 1
        to 6 octets."
 
 
Eugene.
 

From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 8:05 AM
To: Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

Mmm... 2287 is still ip to date.
The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the
TCs w.r.t. UTF-8.
 
I have done the 4001 and 4133.
 
Bert
 
 
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, November 22, 2005 15:15
To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule; Woundy, Richard
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

Bert,
 
I agree.
 
But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.)
 
Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis).
 
-- Rich
-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert)
Sent: Tuesday, November 22, 2005 9:00 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you refer to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better to refer to
the new RFC!?
 
Bert
-----Original Message-----
From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin
Sent: Monday, November 21, 2005 22:39
To: Ipcdn (E-mail)
Cc: Jean-Francois Mule
Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting

 
During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material:
 
    - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets.
    - the value of the MIB object should not include the prefix 'O=' in the Organization Name.
 
The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows:
 
   pktcMtaDevRealmOrgName  OBJECT-TYPE
       SYNTAX      SnmpAdminString(SIZE (1..255))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           " This object contains the X.500 organization name attribute 
             as defined in the subject name of the service provider 
             certificate. The value of the organization name includes
             the prefix 'O='."
       REFERENCE
           " PacketCable Security Specification."
       ::= { pktcMtaDevRealmEntry 5 }
 
 
To address these two comments, co-authors are proposing the following:
 
1. Add the following to the IMPORTS section of the MTA MIB:
 
    LongUtf8String 
            FROM SYSAPPL-MIB                 -- [RFC2287]
 
2. Modify the definition of the pktcMtaDevRealmOrgName to be the following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE
    SYNTAX LongUtf8String
         ^^^^^^^^^^^
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION
        " This object contains the X.500 organization name attribute
        as defined in the subject name of the service provider
        X.509 certificate."
    REFERENCE
        " PacketCable Security Specification."
    ::= { pktcMtaDevRealmEntry 5 }
 
3. Add the following compliance statement to the MTA MIB compliance section:
 
    OBJECT pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE (1..384))
    DESCRIPTION
        " Compliant devices are only required to support
        pktcMtaDevRealmOrgName values of 64 UTF-8 encoded
        characters.
        The Organization Name of the X.509 certificate can
        contain up to 64 UTF-8 encoded characters as
        specified in RFC 2459.
        Given that, in UTF-8, characters are encoded using
        sequences of 1 to 6 octets (RFC 2279), compliant
        devices must support a maximum size of 384 octets for
        pktcMtaDevRealmOrgName."
 
 
Please feel free to provide comments on proposed modifications.
 
Regards,
 
Eugene Nechamkin.
 
------_=_NextPart_001_01C5F01C.5EE1A988-- --===============0361825980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0361825980==-- From ipcdn-bounces@ietf.org Wed Nov 23 13:35:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezSX-0006Mu-Dd; Wed, 23 Nov 2005 13:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EezSV-0006M3-7j for ipcdn@megatron.ietf.org; Wed, 23 Nov 2005 13:35:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08679 for ; Wed, 23 Nov 2005 13:34:27 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EezlO-0002Uk-1l for ipcdn@ietf.org; Wed, 23 Nov 2005 13:54:39 -0500 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 23 Nov 2005 10:34:40 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 23 Nov 2005 10:34:40 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CGG61480; Wed, 23 Nov 2005 10:34:36 -0800 (PST) Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA02795; Wed, 23 Nov 2005 10:34:35 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id jANIYUov029999; Wed, 23 Nov 2005 10:34:31 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Date: Wed, 23 Nov 2005 10:34:30 -0800 Message-ID: <9C5C578DD43AFD4EA7A9F0BDB2F4856413CC2C@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting Thread-Index: AcXvtGiPXlTrcAyyQAKY91EFglIybAAAUlnQAAN+2QAAJcl1wA== From: "Eugene Nechamkin" To: "Woundy, Richard" , "Wijnen, Bert (Bert)" X-WSS-ID: 6F9A69CA2JW1192610-01-01 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d3a2e64e2f60a3fa71b41e8f28d026e Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1118199174==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1118199174== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F05C.8AB2CBD8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F05C.8AB2CBD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 > The ironic part is that the compliance DESCRIPTION below uses both forms. :^) This is just a reflection of both forms to be equally acceptable by the RFC3629. Given the preference to using the "UTF-8 encoded characters" form in this group, the compliance DESCRIPTION will be adjusted accordingly: =20 DESCRIPTION " As per RFC3280, Organization Name field in X.509=20 certificates can contain up to 64 UTF-8 encoded =20 characters. Therefore, compliant devices are only=20 required to support Organization Name values=20 of up to 64 UTF-8 encoded characters. Given that the RFC3280 defines the UTF-8 encoding=20 per RFC2279, the compliant devices must support the maximum size of 384 octets for=20 pktcMtaDevRealmOrgName. The calculation of 384 octets=20 comes from the RFC2279 UTF-8 encoding definition whereby the UTF-8 characters are encoded as sequences of 1=20 to 6 octets." =20 Eugene. ________________________________ From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Tuesday, November 22, 2005 4:30 PM To: Eugene Nechamkin; Wijnen, Bert (Bert) Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting >Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:" =20 But also from RFC3629: "US-ASCII octet values do not appear otherwise in a UTF-8 encoded character stream." It doesn't say "UTF-8 character stream". =20 I personally like the phrase "UTF-8 encoded characters" but I know I am not an authority on this. =20 The ironic part is that the compliance DESCRIPTION below uses both forms. :^) =20 As per RFC3280, Organization Name field in X.509=20 certificates can contain up to 64 UTF-8 encoded =20 characters. Therefore, compliant devices are only=20 required to support Organization Name values=20 of up to 64 UTF-8 characters. =20 -- Rich -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Tuesday, November 22, 2005 5:47 PM To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 =20 Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as follows:" =20 Unless there is some other supporting references, the existing wording in the proposed draft's modifications seems to be in-line with the RFC terminology and should be fine to use. =20 Eugene. =09 ________________________________ From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, November 22, 2005 2:30 PM To: Eugene Nechamkin; Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 You may want to check the wording a bit. I do not think it is valid to speak of "UTF-8 characters". You an speak of "UTF-8 encoded characters". =20 Bert -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Tuesday, November 22, 2005 22:54 To: Wijnen, Bert (Bert); Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 =20 Bert/Rich, =20 Thanks for your comments on the RFC updates - the RFC references should be updated. =20 However, there is a caviat to that. The RFC3280 itself is still using the "obsolete" reference to the RFC2279 for UTF-8 definition instead of refering to the RFC3629. From the MTA MIB draft's prospective, this creates a potential compatibility problem for the MTAs, as RFC3629 defines the UTF-8 characters as being encoded into the sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in RFC2279). While RFC3280 would allow the max size of the OrganizationName in X.509 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB would restrict the OrganizationName by 256 octets (64 chars x 4 octets). =20 To resolve this inconsistency, it might still be worthwhile to keep the 384 octets restriction on the size of the pktcMtaDevRealmOrgName object instead of changing it to 256. When RFC3280 is updated with the new reference to RFC3629, we'll be able to update the compliance statement for pktcMtaDevRealmOrgName object (if decided at this moment that such an update is required). =20 =20 Therefore, the proposed modifications to the MTA draft would be as follows: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " As per RFC3280, Organization Name field in X.509=20 certificates can contain up to 64 UTF-8 encoded characters. Therefore, compliant devices are only=20 required to support Organization Name values=20 of up to 64 UTF-8 characters. Given that the RFC3280 defines the UTF-8 encoding=20 per RFC2279, the compliant devices must support the maximum size of 384 octets for=20 pktcMtaDevRealmOrgName. The calculation of 384 octets=20 =09 comes from the RFC2279 UTF-8 encoding definition whereby the UTF-8 characters are encoded as sequences of 1=20 to 6 octets." =20 =20 Eugene. =20 =09 =09 ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 8:05 AM To: Woundy, Richard Cc: Ipcdn (E-mail) Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting =09 =09 Mmm... 2287 is still ip to date. The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 itself, not about the TCs w.r.t. UTF-8. =20 I have done the 4001 and 4133. =20 Bert =20 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, November 22, 2005 15:15 To: Wijnen, Bert (Bert); Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule; Woundy, Richard Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 Bert, =20 I agree. =20 But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. (That's the reason why I referred to RFC2287 in my IPCDN meeting notes too, which is something I should correct.) =20 Looking quickly at the rest of the TC webpage, you might also update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and ENTITY-MIB (RFC4133 instead of RFC2737bis). =20 -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Tuesday, November 22, 2005 9:00 AM To: Eugene Nechamkin; Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 RFC2279 has been obsoleted by RFC3629. So I suggest you refer to the newer RFC. =20 RFC2459 has been obsoleted by RFC3280. Probably better to refer to the new RFC!? =20 Bert -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin Sent: Monday, November 21, 2005 22:39 To: Ipcdn (E-mail) Cc: Jean-Francois Mule Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64 meeting =09 =09 =20 During the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at IETF-64 meeting, there were the following comments made on the presented material: =20 - the max length of the "pktcMtaDevRealmOrgName" currently defined as being 255 does not correspond to the actual number of octets the MIB object may contain which is calculated as max number of UTF-8 characters (64) each of which may consist of up to 6 octets. - the value of the MIB object should not include the prefix 'O=3D' in the Organization Name. =20 The current definition of the "pktcMtaDevRealmOrgName" in the draft-07 is as follows: =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX SnmpAdminString(SIZE (1..255))=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute =20 as defined in the subject name of the service provider =20 certificate. The value of the organization name includes=20 the prefix 'O=3D'."=20 REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 }=20 =09 =09 =20 =20 To address these two comments, co-authors are proposing the following: =20 1. Add the following to the IMPORTS section of the MTA MIB: =20 LongUtf8String =20 FROM SYSAPPL-MIB -- [RFC2287] =20 2. Modify the definition of the pktcMtaDevRealmOrgName to be the following: =20 =20 pktcMtaDevRealmOrgName OBJECT-TYPE=20 SYNTAX LongUtf8String=20 ^^^^^^^^^^^ MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 " This object contains the X.500 organization name attribute=20 as defined in the subject name of the service provider=20 X.509 certificate." REFERENCE=20 " PacketCable Security Specification."=20 ::=3D { pktcMtaDevRealmEntry 5 } =20 3. Add the following compliance statement to the MTA MIB compliance section: =20 OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String (SIZE (1..384)) DESCRIPTION " Compliant devices are only required to support pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20 characters. The Organization Name of the X.509 certificate can contain up to 64 UTF-8 encoded characters as=20 specified in RFC 2459. Given that, in UTF-8, characters are encoded using sequences of 1 to 6 octets (RFC 2279), compliant=20 devices must support a maximum size of 384 octets for=20 pktcMtaDevRealmOrgName." =20 =20 Please feel free to provide comments on proposed modifications. =20 Regards, =20 Eugene Nechamkin. =20 ------_=_NextPart_001_01C5F05C.8AB2CBD8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
 
> The ironic part is = that=20 the compliance DESCRIPTION below uses both forms.=20 :^)
This is just a reflection of both = forms to be=20 equally acceptable by the RFC3629. Given the preference to using the "UTF-8 = encoded=20 characters" form in this group, the compliance DESCRIPTION will = be=20 adjusted accordingly:
 
   =20 DESCRIPTION
        " As per RFC3280, Organization Name field in X.509=20
        certificates = can contain up to 64 UTF-8 = encoded =20
       =20 characters. Therefore, compliant = devices are=20 only
       =20 required to = support=20 Organization Name values=20
       &nbs= p;of up to 64 UTF-8 encoded characters.
        Given = that the=20 RFC3280 defines the UTF-8 encoding=20
        per RFC2279, the=20 compliant devices=20 must
       =20 support the maximum size of = 384=20 octets for
       =20 pktcMtaDevRealmOrgName. The calculation = of 384=20 octets
        comes = from the RFC2279 UTF-8 encoding definition=20 whereby
       &nbs= p;the=20 UTF-8 = characters=20 are encoded as = sequences of = 1=20
       &nbs= p;to=20 6 octets."
 
Eugene.

From: Woundy, Richard=20 [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, = November 22,=20 2005 4:30 PM
To: Eugene Nechamkin; Wijnen, Bert = (Bert)
Cc:=20 Ipcdn (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 = meeting

>Not sure about that... From the RFC-3629: "Decoding a UTF-8 character proceeds as=20 follows:"
 
But=20 also from RFC3629: "US-ASCII octet values = do not=20 appear otherwise in a UTF-8 encoded character stream." It = doesn't=20 say "UTF-8 character=20 stream".
 
I=20 personally like the phrase "UTF-8 encoded characters" but I = know I am=20 not an authority on this.
 
The=20 ironic part is that the compliance DESCRIPTION below uses = both=20 forms. :^)
 
        As per=20 RFC3280, Organization = Name field in X.509=20
        certificates = can contain up to 64 UTF-8 = encoded =20
       =20 characters. Therefore, compliant = devices are=20 only
       =20 required to support Organization Name values=20
       &nbs= p;of up to 64 UTF-8 = characters.
 
--=20 Rich
-----Original Message-----
From: = Eugene Nechamkin=20 [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November = 22, 2005=20 5:47 PM
To: Wijnen, Bert (Bert); Woundy, = Richard
Cc: Ipcdn=20 (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

 
Not sure about that... From the RFC-3629: = "Decoding a UTF-8 character proceeds as=20 follows:"
 
Unless there is some other supporting references, the = existing wording=20 in the proposed draft's modifications seems to be in-line with the RFC = terminology and should be fine to use.
 
Eugene.
From: Wijnen, Bert (Bert)=20 [mailto:bwijnen@lucent.com]
Sent: Tuesday, November 22, = 2005 2:30=20 PM
To: Eugene Nechamkin; Woundy, Richard
Cc: Ipcdn = (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

You=20 may want to check the wording a bit.
I do=20 not think it is valid to speak of "UTF-8 = characters".
You=20 an speak of "UTF-8 encoded characters".
 
Bert
-----Original Message-----
From: Eugene Nechamkin = [mailto:enechamkin@broadcom.com]
Sent: Tuesday, November = 22, 2005=20 22:54
To: Wijnen, Bert (Bert); Woundy, = Richard
Cc: Ipcdn=20 (E-mail)
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

 
Bert/Rich,
 
Thanks for your = comments on the RFC=20 updates - the RFC references should be updated.
 
However, there is a = caviat to that.=20 The RFC3280 itself is still using the "obsolete" reference to the = RFC2279=20 for UTF-8 definition instead of refering to the RFC3629. From = the MTA=20 MIB draft's prospective, this creates a potential compatibility = problem for=20 the MTAs, as RFC3629 defines the UTF-8 characters as being encoded = into the=20 sequencies of 1 to 4 octets (instead of 1 to 6 octets defined in = RFC2279).=20 While RFC3280 would allow the max size of the OrganizationName in = X.509=20 certificates to be 384 octets (64 chars x 6 octets), the MTA MIB = would=20 restrict the OrganizationName by 256 octets (64 chars x 4=20 octets).
 
To resolve this = inconsistency, it=20 might still be worthwhile to keep the 384 octets restriction on the = size of=20 the pktcMtaDevRealmOrgName = object=20 instead of changing it to 256. When RFC3280 is updated with the new=20 reference to RFC3629, we'll be able to update the compliance = statement for=20 pktcMtaDevRealmOrgName = object (if=20 decided at this moment that such an update is=20 = required).
 
 
Therefore, the = proposed=20 modifications to the MTA draft would be as = follows:
 
1. Add the = following=20 to the IMPORTS section of the MTA=20 MIB:
 
   =20 LongUtf8String 
          &nbs= p;=20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2. Modify = the definition=20 of the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName = OBJECT-TYPE=20
    = SYNTAX=20 LongUtf8String
         ^^^^^^^^^^= ^
    = MAX-ACCESS=20 read-create
    = STATUS current=20
    = DESCRIPTION=20
        " This object = contains the=20 X.500 organization name attribute
        as defined in = the subject=20 name of the service provider
        X.509=20 certificate."
    = REFERENCE=20
        " PacketCable = Security=20 Specification."
    = ::=3D {=20 pktcMtaDevRealmEntry 5 }
 
3. Add the following = compliance=20 statement to the MTA MIB compliance = section:
 
    = OBJECT=20 pktcMtaDevRealmOrgName
    = SYNTAX=20 LongUtf8String (SIZE (1..384))
   =20 DESCRIPTION
        " As per RFC3280, Organization Name field in X.509=20
        certificates = can contain up to 64 = UTF-8=20 encoded 
       =20 characters. Therefore, compliant = devices=20 are only
       =20 required to=20 support Organization = Name values=20
       &nbs= p;of up to 64 UTF-8=20 characters<= SPAN=20 class=3D768370221-21112005>.
        Given that = the=20 RFC3280 defines the UTF-8 encoding=20
       &nbs= p;per=20 RFC2279, the compliant devices=20 must
        = support the maximum size of 384 octets for =
       =20 pktcMtaDevRealmOrgName. The = calculation of=20 384 octets
        comes from the RFC2279 UTF-8 encoding = definition=20 whereby
       &nbs= p;the=20 UTF-8=20 characters are encoded as=20 sequences of 1=20
       &nbs= p;to=20 6 octets."
 
 
Eugene.
 

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Wijnen, Bert=20 (Bert)
Sent: Tuesday, November 22, 2005 8:05 = AM
To:=20 Woundy, Richard
Cc: Ipcdn (E-mail)
Subject: RE: = [ipcdn]=20 Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64=20 meeting

Mmm... 2287 is still ip to date.
The RFC2279 has been obsoleted by RFC3629, that is about UTF-8 = itself,=20 not about the
TCs w.r.t.=20 UTF-8.
 
I have done the 4001 and=20 4133.
 
Bert
 
 
-----Original Message-----
From: Woundy, = Richard=20 [mailto:Richard_Woundy@cable.comcast.com]
Sent: Tuesday, = November 22, 2005 15:15
To: Wijnen, Bert (Bert); Eugene=20 Nechamkin; Ipcdn (E-mail)
Cc: Jean-Francois Mule; = Woundy,=20 Richard
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

Bert,
 
I agree.
 
But you also may want to update http://www.ops.ietf.org/mib-common-tcs.html as well. It=20 also refers to RFC2287 (instead of RFC3629) for the SYSAPPL-MIB. = (That's=20 the reason why I referred to RFC2287 in my IPCDN meeting notes = too, which=20 is something I should correct.)
 
Looking quickly at the rest of the TC webpage, you might = also=20 update INET-ADDRESS-MIB (RFC4001 instead of RFC3291bis) and = ENTITY-MIB=20 (RFC4133 instead of RFC2737bis).
 
-- Rich
-----Original = Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On = Behalf Of=20 Wijnen, Bert (Bert)
Sent: Tuesday, November 22, = 2005 9:00=20 AM
To: Eugene Nechamkin; Ipcdn (E-mail)
Cc:=20 Jean-Francois Mule
Subject: RE: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

RFC2279 has been obsoleted by RFC3629. So I suggest you = refer=20 to
the newer RFC.
 
RFC2459 has been obsoleted by RFC3280. Probably better = to refer=20 to
the new RFC!?
 
Bert
-----Original Message-----
From:=20 ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On = Behalf Of=20 Eugene Nechamkin
Sent: Monday, November 21, 2005 = 22:39
To: Ipcdn (E-mail)
Cc: Jean-Francois = Mule
Subject: [ipcdn] Comments on=20 draft-ietf-ipcdn-pktc-mtamib-07 during the IETF-64=20 meeting

 
During=20 the presentation of the draft-ietf-ipcdn-pktc-mtamib-07 at = IETF-64=20 meeting, there were the following comments made on the = presented=20 material:
 
    - the max length of the=20 "pktcMtaDevRealmOrgName" currently defined as being 255 does = not=20 correspond to the actual number of octets the MIB object may = contain=20 which is calculated as max number of UTF-8 characters (64) = each of=20 which may consist of up to 6 = octets.
    - the value of the MIB object = should not=20 include the prefix 'O=3D' in the Organization=20 Name.
 
The current=20 definition of the "pktcMtaDevRealmOrgName" in the draft-07 is = as=20 follows:
 
  =20 pktcMtaDevRealmOrgName  OBJECT-TYPE=20
      =20 SYNTAX      SnmpAdminString(SIZE = (1..255))=20
       MAX-ACCESS  = read-create=20
      =20 STATUS      current=20
       DESCRIPTION=20 =
           "=20 This object contains the X.500 organization name = attribute =20 =
           &nb= sp;=20 as defined in the subject name of the service provider =20 =
           &nb= sp;=20 certificate. The value of the organization name includes=20 =
           &nb= sp;=20 the prefix 'O=3D'."
       = REFERENCE=20 =
           "=20 PacketCable Security Specification."=20
       ::=3D { = pktcMtaDevRealmEntry 5=20 }
 
 
To address these two = comments,=20 co-authors are proposing the=20 following:
 
=
1.=20 Add the following to the IMPORTS section of the MTA=20 MIB:
 
    LongUtf8String =20
           =20 FROM=20 = SYSAPPL-MIB          &n= bsp;     =20 -- [RFC2287]
 
2.=20 Modify the definition of the pktcMtaDevRealmOrgName to be the=20 following:
 
 
pktcMtaDevRealmOrgName OBJECT-TYPE =
    SYNTAX LongUtf8String=20
         ^^^^^^^^^^^
    MAX-ACCESS read-create=20
    STATUS current =
    DESCRIPTION =
        " This = object=20 contains the X.500 organization name attribute=20
        as defined = in the=20 subject name of the service provider =
        X.509=20 certificate."
    REFERENCE =
        " = PacketCable=20 Security Specification."
    ::=3D { = pktcMtaDevRealmEntry 5=20 }
 
3. Add the=20 following compliance statement to the MTA MIB compliance=20 section:
 
    OBJECT=20 pktcMtaDevRealmOrgName
    SYNTAX LongUtf8String (SIZE=20 (1..384))
    = DESCRIPTION
        " = Compliant devices=20 are only required to support
       =20 pktcMtaDevRealmOrgName values of 64 UTF-8 encoded=20
       =20 characters.
        The = Organization=20 Name of the X.509 certificate can
        contain up = to 64=20 UTF-8 encoded characters as
        specified = in RFC=20 2459.
        Given = that, in=20 UTF-8, characters are encoded using
        sequences = of 1 to 6=20 octets (RFC 2279), compliant
        devices = must support=20 a maximum size of 384 octets for
       =20 pktcMtaDevRealmOrgName."
 
 
Please feel free to provide = comments on=20 proposed modifications.
 
Regards,
 
Eugene=20 Nechamkin.
 
------_=_NextPart_001_01C5F05C.8AB2CBD8-- --===============1118199174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1118199174==-- From ipcdn-bounces@ietf.org Fri Nov 25 05:10:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaXc-0003ye-7S; Fri, 25 Nov 2005 05:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaXa-0003yZ-Fd for ipcdn@megatron.ietf.org; Fri, 25 Nov 2005 05:10:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05780 for ; Fri, 25 Nov 2005 05:10:09 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efaqn-00081P-LB for ipcdn@ietf.org; Fri, 25 Nov 2005 05:30:44 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id jAPAATb0008232; Fri, 25 Nov 2005 03:10:30 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Nov 2005 03:10:29 -0700 Message-ID: Thread-Topic: Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the standards track Thread-Index: AcXgBqy5efGaxNheS1Gp+6o0bBi/dARoIiRw From: "Jean-Francois Mule" To: "Richard Woundy @ Comcast" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: Bert Wijnen Subject: [ipcdn] RE: Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the standards track X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Rich and all, Based on our November IETF64 meeting, the draft is considered complete = and there were no additional comments in the past 2 weeks. I'm almost done doing the PROTO write-up for the CDmibv2. The PROTO = process is defined in draft-ietf-proto-wgchair-doc-shepherding-05.txt. There are a couple of questions we need to answer as a wg. See below = my proposed responses which I think represent the wg status. If my = responses are not representative of the wg consensus or incorrect, or if = you have any comments, questions or concerns, please let me know by = Friday 12/2/2005. This is for: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt 1.b) Has the document had adequate review from both key WG members and key non-WG members? Yes, reviews from both subject-matter experts that are WG members and = MIB doctors who provided valuable comments to improve the quality of the = MIB module. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document represents the WG consensus as a whole: the WG as a whole understands and agrees with it. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. Sending this draft on some of the PROTO write-up questions for WG = knowledge and to ask if anyone would appeal - please let me know = (jfm@cablelabs.com). Jean-Fran=E7ois PROTO shepherd for draft-ietf-ipcdn-device-mibv2-10.txt > -----Original Message----- > From: Richard Woundy @ Comcast > Sent: Wednesday, November 02, 2005 4:40 PM > To: Jean-Francois Mule > Cc: Bert Wijnen; ipcdn@ietf.org > Subject: Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the > standards track >=20 > Jean-Francois, >=20 > I have posted an updated version of the DOCSIS Cable Device MIB, > 10.tx > t>, which I believe is ready to be forwarded to the IESG for > publication > as an RFC with the status of Proposed Standard. >=20 > I believe this draft incorporates the resolutions of the four open > issues raised in > , > as > clarified by > . I > will send details in a separate email. >=20 > I also believe this draft satisfies the AD review concerns raised in > . I > will send details in another separate email. >=20 > Please approve this draft for advancement. >=20 > -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Nov 25 18:12:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efmjg-0002LW-Bx; Fri, 25 Nov 2005 18:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efmje-0002Kc-Vf for ipcdn@megatron.ietf.org; Fri, 25 Nov 2005 18:12:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00202 for ; Fri, 25 Nov 2005 18:11:25 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efn30-00021a-RY for ipcdn@ietf.org; Fri, 25 Nov 2005 18:32:07 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jAPNBmRQ027181; Fri, 25 Nov 2005 17:11:48 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 26 Nov 2005 00:11:06 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508A4828B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule , "Richard Woundy @ Comcast" , ipcdn@ietf.org Date: Sat, 26 Nov 2005 00:11:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: Subject: [ipcdn] RE: Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the standar ds track X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org I did a last check of the document. - In the DESCRIPTION clause of the MODULE-IDENTITY you state: Copyright (C) The Internet Society (2005). The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." Those last two lines can go away. This is not an IANA maintained MIB module, so their copyrights have nothing to do with this. You can consider that as an early IETF Last Call comment, and we can=20 fix it with a note to RFC-Editor if this is all that gets reported. So I am ready for IETF Last Call as soon as I get the PROTO report, which comes with a "request to publish as Proposed Standard" (and plx send to iesg-secretary@ietf.org and copy me). Bert > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, November 25, 2005 11:10 > To: Richard Woundy @ Comcast; ipcdn@ietf.org > Cc: Bert Wijnen > Subject: RE: Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the > standards track >=20 >=20 > Rich and all, >=20 > Based on our November IETF64 meeting, the draft is=20 > considered complete and there were no additional comments in=20 > the past 2 weeks. >=20 > I'm almost done doing the PROTO write-up for the CDmibv2.=20 > The PROTO process is defined in=20 > draft-ietf-proto-wgchair-doc-shepherding-05.txt. >=20 > There are a couple of questions we need to answer as a wg.=20 > See below my proposed responses which I think represent the=20 > wg status. If my responses are not representative of the wg=20 > consensus or incorrect, or if you have any comments,=20 > questions or concerns, please let me know by Friday 12/2/2005. >=20 > This is for: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mib > v2-10.txt >=20 > 1.b) Has the document had adequate review from both key WG members > and key non-WG members? > Yes, reviews from both subject-matter experts that are WG=20 > members and MIB doctors who provided valuable comments to=20 > improve the quality of the MIB module. >=20 > 1.c) Do you have concerns that the document needs more=20 > review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? >=20 > No. >=20 > 1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? >=20 > This document represents the WG consensus as a whole: the WG=20 > as a whole > understands and agrees with it. >=20 >=20 > 1.f) Has anyone threatened an appeal or otherwise indicated = extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. >=20 > Sending this draft on some of the PROTO write-up questions=20 > for WG knowledge and to ask if anyone would appeal - please=20 > let me know (jfm@cablelabs.com). >=20 >=20 > Jean-Fran=E7ois > PROTO shepherd for draft-ietf-ipcdn-device-mibv2-10.txt >=20 > > -----Original Message----- > > From: Richard Woundy @ Comcast > > Sent: Wednesday, November 02, 2005 4:40 PM > > To: Jean-Francois Mule > > Cc: Bert Wijnen; ipcdn@ietf.org > > Subject: Advancing draft-ietf-ipcdn-device-mibv2-10.txt on the > > standards track > >=20 > > Jean-Francois, > >=20 > > I have posted an updated version of the DOCSIS Cable Device MIB, > > > 10.tx > > t>, which I believe is ready to be forwarded to the IESG for > > publication > > as an RFC with the status of Proposed Standard. > >=20 > > I believe this draft incorporates the resolutions of the four open > > issues raised in > > = , > > as > > clarified by > >=20 > . = I > > will send details in a separate email. > >=20 > > I also believe this draft satisfies the AD review concerns raised = in > >=20 > . = I > > will send details in another separate email. > >=20 > > Please approve this draft for advancement. > >=20 > > -- Rich >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Nov 28 08:41:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgjGU-0005wi-DB; Mon, 28 Nov 2005 08:41:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgjGS-0005wc-MK for ipcdn@megatron.ietf.org; Mon, 28 Nov 2005 08:41:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05468 for ; Mon, 28 Nov 2005 08:41:08 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgjaJ-00065y-Ti for ipcdn@ietf.org; Mon, 28 Nov 2005 09:02:25 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jASDfVgh002860; Mon, 28 Nov 2005 07:41:31 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Nov 2005 14:40:35 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508B44476@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" , "Ipcdn (E-mail)" Date: Mon, 28 Nov 2005 14:41:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: f45599941caef2d9ac4ed98df73589d5 Cc: "Wijnen, Bert \(Bert\)" , Jean-Francois Mule Subject: [ipcdn] RE: IETF64 - IPCDN meeting minutes (preliminary) X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213875076==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1213875076== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F421.6C4E2B4C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5F421.6C4E2B4C Content-Type: text/plain Inline -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] 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 (richard_woundy@cable.comcast.com) summaryWG 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. mtamibPacketCable/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 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 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 iesg-secretary@ietf.org 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. ncssignalingmibPacketCable/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 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. memmibPacketCable/IPCableCom Management Event MIB I'dd add that this is document: 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 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. 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 } 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. 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 cdmibDOCSIS Cable Device MIB (replacing RFC2669) I would add: this is document: draft-ietf-ipcdn-device-mibv2-10.txt 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 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 iesg-secretary@ietf.org and cc: myself. rfimibDOCSIS RFIv2 MIB (replacing RFC2670) This is document: draft-ietf-ipcdn-docs-rfmibv2-14.txt Eduardo Cardona produced version 14 of the DOCSIS RFIv2 MIB, in response to comments from the AD 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 nextstepsIPCDN 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 Jean-Francois Mule' ------_=_NextPart_001_01C5F421.6C4E2B4C Content-Type: text/html Message
Inline
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
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 (richard_woundy@cable.comcast.com)

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 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 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.  
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 iesg-secretary@ietf.org 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 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

 

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 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?)  
Yes 

DOCSIS Cable Device MIB (replacing RFC2669) 

 

I would add: this is document: draft-ietf-ipcdn-device-mibv2-10.txt 

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 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 iesg-secretary@ietf.org and cc: myself.

 

DOCSIS RFIv2 MIB (replacing RFC2670) 

This is document: draft-ietf-ipcdn-docs-rfmibv2-14.txt 

Eduardo Cardona produced version 14 of the DOCSIS RFIv2 MIB, in response to comments from the AD 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?)  
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 <Richard_Woundy@cable.comcast.com>
Jean-Francois Mule' <jf.mule@cablelabs.com>

------_=_NextPart_001_01C5F421.6C4E2B4C-- --===============1213875076== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1213875076==--