Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-mtamib-07 during th e IETF-64 meeting

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 22 Nov 2005 14:59:56 +0100

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: [email-masked] [mailto:[email-masked]]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.

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 22 Nov 2005 17:05:27 +0100

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:[email-masked]]
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> 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: [email-masked] [mailto:[email-masked]] 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

 
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]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

 

 

 
    LongUtf8String  

 

 
Regards,
 
Eugene Nechamkin.

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 22 Nov 2005 13:54:13 -0800

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:

    LongUtf8String  
 
2. Modify the definition of the pktcMtaDevRealmOrgName to be the
following:

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: [email-masked] [mailto:[email-masked]] 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.

Bert

	-----Original Message-----
	From: Woundy, Richard [mailto:[email-masked]]
	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
<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: [email-masked]
[mailto:[email-masked]] 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: [email-masked]
[mailto:[email-masked]]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.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 22 Nov 2005 23:30:19 +0100

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:[email-masked]]
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:

    LongUtf8String  

 

Eugene.

  _____  

From: [email-masked] [mailto:[email-masked]] 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

 
Bert

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
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.

 
-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

 
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]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

 

 

 
    LongUtf8String  

 

 
Regards,
 
Eugene Nechamkin.

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 22 Nov 2005 14:47:16 -0800

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:[email-masked]] 
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

Bert

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	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:

	    LongUtf8String  

	        " This object contains the X.500 organization name
attribute 
	 
	3. Add the following compliance statement to the MTA MIB
compliance section:

	Eugene.

	From: [email-masked] [mailto:[email-masked]] 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.

	Bert

		-----Original Message-----
		From: Woundy, Richard
[mailto:[email-masked]]
		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.

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

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

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

				   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]

				        as defined in the subject name
of the service provider 
				 
				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.

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 22 Nov 2005 19:29:37 -0500

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

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]] 
	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

	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.

	 
	Bert

		-----Original Message-----
		From: Eugene Nechamkin [mailto:[email-masked]]
		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 }

		    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.

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.

		Bert

			-----Original Message-----
			From: Woundy, Richard

			Bert,
			 
			I agree.

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

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

				 
				    - the max length of the

				 

				 
				    LongUtf8String  
				            FROM SYSAPPL-MIB
-- [RFC2287]

				 

				 
				Regards,
				 
				Eugene Nechamkin.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 23 Nov 2005 11:55:10 +0100

Right. And (if only for consistency) I would just use "UTF-8 encoded character"
 
Bert

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
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. :^)

-- Rich

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]] 
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.

  _____  

 
Bert

-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
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,

 

 
    LongUtf8String  

 

Eugene.

  _____  

 
 
Bert

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
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.

 
-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

 
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]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

 

 

 
    LongUtf8String  

 

 
Regards,
 
Eugene Nechamkin.

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 23 Nov 2005 10:34:30 -0800

> 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:
 
    DESCRIPTION
        of up to 64 UTF-8 encoded characters.
 
Eugene.

From: Woundy, Richard [mailto:[email-masked]] 
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

proceeds as follows:"

 

-- Rich

	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]] 
	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

	 
	 
	Eugene.

	 
	Bert

		-----Original Message-----
		From: Eugene Nechamkin [mailto:[email-masked]]
		Sent: Tuesday, November 22, 2005 22:54
		To: Wijnen, Bert (Bert); Woundy, Richard
		Cc: Ipcdn (E-mail)
		Subject: RE: [ipcdn] Comments on

		Bert/Rich,

		 

		 
		    LongUtf8String  
		            FROM SYSAPPL-MIB                 --
[RFC2287]

		 

		

		Eugene.

		 
		 
		Bert

			-----Original Message-----
			From: Woundy, Richard

			Bert,
			 
			I agree.

			 
			-- Rich

				-----Original Message-----

				 
				Bert

				-----Original Message-----

				 
				    - the max length of the

				 

				 
				    LongUtf8String  
				            FROM SYSAPPL-MIB
-- [RFC2287]

				 

				 
				Regards,
				 
				Eugene Nechamkin.