Subject: [ipcdn] RE: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-08.txt

From: "Eugene Nechamkin" <[email-masked]>
Date: Thu, 15 Dec 2005 15:26:12 -0800

Bert,

Thanks for your comments. Here is the reasoning behind having the RFC2279 mentioned in the DESCRIPTION clause of the complience statement for the pktcMtaDevRealmOrgName object.

As per PacketCable requirements, pktcMtaDevRealmOrgName MIB Object should contain OrganizationName attribute in the X.509 certificate of the Telephony Service Provider. As per RFC3280, the X.509 attributes should be defined as "UTF8String" for all certificates issued after December 31, 2003. Also, RFC3280 reffers to RFC2279 for the definition of the "UTF8String" type. Further, as per RFC2279, each "UTF8String" encoded character may contain up to 6 octets, whereas RFC3629 defines up to 4 octests per each "UTF8String" encoded character. To stay consistant with RFC3280, we also have to define the length of the pktcMtaDevRealmOrgName MIB Object based on RFC2279 rather than on RFC3629. Hence - the reference to the obsolete RFC2279 instead of refering to RFC3629 in the DESCRIPTION clause you are rightly pointing to.

To reflect these issues in the MTA MIB, co-authors are proposing the following modifications of the MTA draft:

1. Add the following sub-section to the Section 3 "Introduction" with neccessary additional citations and explanations:

====================
   3.7 X.509 Certificates Dependencies

As per PacketCable Security Specification [PKT-SP-SEC], EMTA must 
use the authentication mechanism based on the X.509 Public Key 
Infrastructure Certificates as defined in RFC 3280 [RFC3280].

The pktcMtaDevRealmOrgName MIB Object, defined in this document, 
should contain OrganizationName attribute in the X.509 certificate of 
the Telephony Service Provider. As per RFC 3280 [RFC3280], X.509 
attributes are defined as "UTF8String" for all certificates issued 
after December 31, 2003. RFC 3280 refers to RFC 2279 [RFC2279] 
for the definition of the "UTF8String" type. Further, currently obsolete 
RFC 2279 requires that each "UTF8String" encoded character may contain 
up to 6 octets, whereas the currently active RFC 3629 [RFC3629] requires 
up to 4 octets for each "UTF8String" encoded character. To stay consistent 
with RFC 3280, this document defines the length of the 
pktcMtaDevRealmOrgName MIB Object based on RFC 2279 rather than based 
on RFC 3629.
====================

2. Add to Section 7 "Informative References" the following reference (in front of all other references in this section):

========================
   [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
             RFC 2279, January 1998. 
========================

If there are no objections during today, we'll modify the MTA draft-08 with two modifications proposed above and submit a new revision 09.

Regards,

Jean-Francois & Eugene.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Wednesday, December 14, 2005 5:29 AM
To: Jean-Francois Mule; [email-masked]; Richard Woundy @ Comcast
Cc: Eugene Nechamkin; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-08.txt

I still get:

  !! Missing citation for Informative reference:
  P055 L050:    [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO

I see use of RFC2279 inside the MIB module. There is no reference to 2279.
I think you want to replace 2279 with 3629 in the text inside the MIB module and probably add a citation (outside the MIB module) to RFC3629.

Let us consider that an IETF Last Call comment.

Pls send [email-masked] (and copy me) a reuqest to publis, pls do include a PROTO writeup for that.
If you can do so today, we may still be able to get this on Jan 5 telechat

Bert

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Monday, December 12, 2005 19:06
> To: [email-masked]; Richard Woundy @ Comcast
> Cc: [email-masked]; [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-08.txt
> 
> 
> Rich and all,
> 
>    Eugene and I submitted a new version of the MTA MIB. It addresses 
> all the comments raised during the IETF 64 meeting in November and 
> some additional feedback received from Bert.
>    See the diff at:
> http://tools.ietf.org/wg/ipcdn/draft-ietf-ipcdn-pktc-mtamib/dr
> aft-ietf-ipcdn-pktc-mtamib-08-from-07.diff.html
> 
>    We would like to request formal publication of this ID.
> 
> Eugene and Jean-François
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, December 09, 2005 4:50 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-08.txt
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the IP over Cable Data Network Working 
> > Group of the IETF.
> > 
> > 	Title		: Multimedia Terminal Adapter (MTA) Management
> >                           Information Base for PacketCable and
> >                           IPCablecom compliant devices
> > 	Author(s)	: E. Nechamkin, J. Mule
> > 	Filename	: draft-ietf-ipcdn-pktc-mtamib-08.txt
> > 	Pages		: 61
> > 	Date		: 2005-12-9
> > 
> > This memo defines a portion of the Management Information Base (MIB)
> >    for use with network management protocols in the
> Internet community.
> >    In particular, it defines a basic set of managed objects for
> >    SNMP-based management of PacketCable and IPCablecom compliant
> >    Multimedia Terminal Adapter devices.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-
> > 08.txt
> > 
> > To remove yourself from the I-D Announcement list, send a message to 
> > [email-masked] with the word unsubscribe in
> the body of
> > the message.
> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-ipcdn-pktc-mtamib-08.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-08.txt".
> 
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 15 Dec 2005 16:28:02 -0800

Hi -

No IS 10646 or Unicode code points have ever been (or ever will be)
assigned that require more than 4 octets to encode in UTF-8.
For details, see section C.2 in
http://www.unicode.org/versions/Unicode4.0.0/appC.pdf

Although the TCs defined in various IETF MIBs can handle any
code point that ever has been or will be defined, ones that are
based on RFC 2279 rather 3629 will permit zillions of invalid code
points.  In my opinion, an implementor would be unwise to use
the RFC 2269 definition rather than the RFC 3629, since it would
permit invalid stuff into his instrumentation,.

For example, despite the RFC 3411 SnmpAdminString TC's reference
to 2269, if I were implementing it today, I'd use the RFC 3629 definition
of UTF-8.  Although the very explicit language in 3411 for SnmpAdminString
says:

|                 Since additional code points are added by
|                 amendments to the 10646 standard from time
|                 to time, implementations must be prepared to
|                 encounter any code point from 0x00000000 to
|                 0x7fffffff.  Byte sequences that do not
|                 correspond to the valid UTF-8 encoding of a
|                 code point or are outside this range are
|                 prohibited.

We should keep in mind that the Unicode and ISO 10646 specifications
have BOTH reduced the upper bound from 7ffffffff to10ffff, and NEVER
assigned any code points above 10ffff.

Randy

----- Original Message ----- 
From: "Eugene Nechamkin" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>; <[email-masked]>
Cc: "Jean-Francois Mule" <[email-masked]>; "Richard Woundy @ Comcast" <[email-masked]>
Sent: Thursday, December 15, 2005 3:26 PM
Subject: [ipcdn] RE: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-08.txt

Bert,

Thanks for your comments. Here is the reasoning behind having the RFC2279 mentioned in the DESCRIPTION clause of the complience
statement for the pktcMtaDevRealmOrgName object.

As per PacketCable requirements, pktcMtaDevRealmOrgName MIB Object should contain OrganizationName attribute in the X.509
certificate of the Telephony Service Provider. As per RFC3280, the X.509 attributes should be defined as "UTF8String" for all
certificates issued after December 31, 2003. Also, RFC3280 reffers to RFC2279 for the definition of the "UTF8String" type. Further,
as per RFC2279, each "UTF8String" encoded character may contain up to 6 octets, whereas RFC3629 defines up to 4 octests per each
"UTF8String" encoded character. To stay consistant with RFC3280, we also have to define the length of the pktcMtaDevRealmOrgName MIB
Object based on RFC2279 rather than on RFC3629. Hence - the reference to the obsolete RFC2279 instead of refering to RFC3629 in the
DESCRIPTION clause you are rightly pointing to.

====================

========================

If there are no objections during today, we'll modify the MTA draft-08 with two modifications proposed above and submit a new
revision 09.

Regards,

Jean-Francois & Eugene.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Wednesday, December 14, 2005 5:29 AM
To: Jean-Francois Mule; [email-masked]; Richard Woundy @ Comcast
Cc: Eugene Nechamkin; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-08.txt

I still get:

I see use of RFC2279 inside the MIB module. There is no reference to 2279.
I think you want to replace 2279 with 3629 in the text inside the MIB module and probably add a citation (outside the MIB module) to
RFC3629.

Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 15 Dec 2005 16:51:18 -0800

Hi -

Completing my thought...

In  the places where the document currently says things like:
             "The calculation of 
               384 octets comes from the RFC2279 UTF-8 encoding 
               definition whereby the UTF-8 encoded characters 
               are encoded as sequences of 1 to 6 octets." 

We might do something like
             "The calculation of 
               384 octets came from the RFC2279 UTF-8 encoding 
               definition whereby the UTF-8 encoded characters 
               were encoded as sequences of 1 to 6 octets, based on the
               the assumption that code points as high as 0x7ffffffff might
               be used.  Subsequent versions of Unicode and ISO 10646
               have limited the upper bound to 0x10ffff.  Consequently,
               the current version of UTF-8, defined in RFC 3629,
               will never require more than four octets to encode a valid
               code point." 

This would effectively make the RFC 2279 reference informative,
and the RFC 3629 reference normative.

If we wanted to be *really* rigorous, we'd identify a normalization form
as well, but I think that is overkill here, since these aren't used for
indexing.

Randy