Re: J0/J1 encoding issues

[[e-mail]]

i agree with john concerning its analysis of the situation and 
it gets even more difficult to solve when i see the following 
(from G.831, i have emphasized the MAY in this paragraph):

"The remainder of the API characters that follow the country code shall
be a
matter for the organization to whom the country code has been assigned,
provided
that uniqueness is guaranteed. These characters **MAY** be any
alphanumeric
characters as defined in ITU-T T.50 (International Reference Version -
7-bit
coded character set for information interchange)." 

and this is what it is said in G.7714.1:

"This recommendation adds a third format, which is identified 
by placing a non-E.164 and non-alphabetic character in the 
first byte of the message. [...] The remaining 14 bytes can 
be used for carrying the information required by G.7714, namely 
the control entity ID and SNTP-ID. 

As per IETF RFC2045, Base64 encoding provides a relatively 
efficient method to represent 6-bits of information in a 
printable character. This yields 3 nibbles or 12 bits for 
every 2 printable characters."

thus i think here G.7714.1 "moves" the printability requirement
in another dimension here it is not the printability referred
in the previous e-mail exchanges

but as far as i know characters are not printed on the wire, 
and the control entity ID nor the SNTP-ID is in the list 
mentioned in G.831 concerning the information to be exchanged 
within the pattern thus draft-lang-ccamp-lmp-bootstrap follows 
the same principle except it doesn't deliver the way to "print" 
the character since imho a purely internal system issue.

thus the only difference is that G.7714.1 requires the changes 
of the existing applications since it delivers the older ones
as well (or say it at follows it brings a new application that 
covers the previous ones - defined in G.831 - and the one which 
is defined in the bootstrap just delivers an application for 
the sake of what it intends to deliver), this said it is also 
mentioned in G.831 "the access point identifier should not 
change while the access point remains in existence;" thus i 
don't see here any strict incompatibility with respect to the 
bootstrap procedure if one desires to send the pattern only 
for discovery purposes and keep the existing applications for 
steady state use of the link.

thus, i would like a have clarification here because imho the
requirements that would be provided by responsible entities
concerning the sonet/sdh overhead encoding and related should
apply equivalently to any solution that are trying to deliver
a solution for sending an in-band pattern,

thanks,
- dimitri.

Greg Bernstein wrote:
> 
> Printable doesn't usually include control characters of which there are
> a fair amount in T.50.
> If you want the widest compatibility (i.e., all those existing ADMs too)
> you need readable/typeable characters. That way folks don't need to
> change the embedded software on existing equipment. Hence why a base64
> encoding is so nice.  This is was also a thrust in the LCP
> Identification extension (RFC1570).
> 
> Greg B.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of John Drake
> Sent: Wednesday, December 04, 2002 6:36 PM
> To: '[e-mail]'
> Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> 'ccamp '
> Subject: RE: J0/J1 encoding issues
> 
> Jonathan S,
> 
> Okay, now you've really confused me.
> 
> In this e-mail, you seem to be saying that any T.50 character is valid
> in
> J0/J1/J2.  However, in your earlier e-mail, which is included way down
> at
> the bottom of this e-mail, you say "The requirements for J0/J1/J2 (found
> in G.707) state the trace message payload must utilize the printable
> characters
> defined in T.50".
> 
> Which is the real requirement?
> 
> If it is the former, then there is no issue with
> draft-lang-ccamp-lmp-bootstrap.
> I.e., T.50 defines all possible 7 bit values and
> draft-lang-ccamp-lmp-bootstrap
> specifies that 7 bits of information are to be carried in each octet, so
> by
> definition every possible seven bit value is a valid T.50 character.
> 
> If it is the latter, then it doesn't sound as though the latest draft
> G.7714.1
> is any more conformant than draft-lang-ccamp-lmp-bootstrap is.
> 
> Thanks,
> 
> John
> 
> 
> -----Original Message-----
> From: Jonathan Sadler [mailto:[e-mail]]
> Sent: Tuesday, November 26, 2002 8:49 AM
> To: John Drake
> Cc: Razdan, Rajender; Jonathan Lang; 'Brungard, Deborah A, ALASO ';
> 'ccamp '
> Subject: Re: J0/J1 encoding issues
> 
> John,
> 
> There are a number of T.50 characters that are non-E.164 and
> non-alphabetic.  The use of a non-E.164 and non-alphabetic character in
> the format defined by draft G.7714.1 is to provide backward
> compatability with the country-specific and carrier-specific encodings
> described in G.831.
> 
> Jonathan Sadler
> 
> John Drake wrote:
> >
> > Rajender,
> >
> > Why don't you send a pointer to the draft, so that any interested
> party
> can
> > take a look at it and decide for themselves?
> >
> > As I understand it, the  version presented at the Experts Meeting in
> Ottawa
> > did not comply with T.50 requirements, and it is only the newest draft
> > version that attempts to address the T.50 requirements.  It does so by
> > re-defining current Jx processing with a new format that "uses a
> non-E.164
> > and non-alphabetic character in the first byte of the message".
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Razdan, Rajender [mailto:[e-mail]]
> > Sent: Monday, November 25, 2002 8:55 AM
> > To: John Drake; [e-mail]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > John,
> >
> >     I don't subscribe to the ccamp mailing list, and so haven't had a
> chance
> > to comment on the LMP drafts till now. The discussion on J0/J1 issues
> was
> > forwarded to me by Jonathan Sadler. As the editor of Draft G.7714.1, I
> was
> > quite distressed to read about your understanding that none of the
> work
> > aimed
> > at G.7714.1 is compatible with the T.50 requirement. I don't know how
> you
> > got
> > that absolutely wrong impression. In fact, compatibility with the T.50
> > requirement, as dictated by ITU Rec. G.707, has been the most
> important
> > consideration for us in our defining J0/J1/J2 discovery mechanisms.
> The
> > current
> > draft of G.7714.1 clearly states this. I FULLY agree with Jonathan
> Sadler
> > that
> > the LMP work should also be consistent with this requirement.
> >
> > Regards,
> > Rajender Razdan
> >
> > -----Original Message-----
> > From: John Drake [mailto:[e-mail]]
> > Sent: Monday, November 25, 2002 11:24 AM
> > To: [e-mail]
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: RE: J0/J1 encoding issues
> >
> > Jonathan,
> >
> > The various Test transport mechanisms that are currently defined in
> > draft-ietf-ccamp-lmp-test-sonet-sdh were added in response to input
> from
> > various carriers and organizations such as the OIF.  The fact that the
> > individual carriers have different requirements for the contents of
> the
> > various SDH/SONET overheads is also consistent with my reading of
> Deborah's
> > recent e-mail on this topic.
> >
> > Since one of the transport mechanisms, the J0/J1/J2 trace correlation,
> > allows the transport of T.50 characters, I think we're done wrt
> > draft-ietf-ccamp-lmp-test-sonet-sdh.
> >
> > Wrt draft-lang-ccamp-lmp-bootstrap, it's my understanding that none of
> the
> > work aimed at G.7714.1 is compatible with the T.50 requirement.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Jonathan Sadler [mailto:[e-mail]]
> > Sent: Thursday, November 21, 2002 8:23 PM
> > To: John Drake
> > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > Subject: Re: J0/J1 encoding issues
> >
> > John -
> >
> > I think you forgot what my original message said.  It stated:
> >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh
> &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> >
> > I fail to see what is incorrect with the above.
> >
> > While draft-ietf-ccamp-lmp-test-sonet-sdh does describe methods for
> > J0/J1/J2 that fall within the requirements of G.707, it also includes
> > methods that don't.  This situation SHOULD be resolved to provide the
> > greatest amount of interoperability while reducing the number of trace
> > methods that need to be implemented.
> >
> > I'm glad to see we agree on the fact that
> draft-lang-ccamp-lmp-bootstrap
> > only provides methods that fall outside the requirements of G.707.
> This
> > situation MUST be resolved.
> >
> > Jonathan Sadler
> >
> > John Drake wrote:
> > >
> > > Wouldn't it be more precise to say that it is an issue with
> > > draft-lang-ccamp-lmp-bootstrap, and that it is NOT an issue with
> > > draft-ietf-ccamp-lmp-test-sonet-sdh?
> > >
> > > -----Original Message-----
> > > From: Jonathan Sadler [mailto:[e-mail]]
> > > Sent: Thursday, November 21, 2002 12:49 PM
> > > To: John Drake
> > > Cc: Jonathan Lang; 'Brungard, Deborah A, ALASO '; 'ccamp '
> > > Subject: Re: J0/J1 encoding issues
> > >
> > > John -
> > >
> > > draft-lang-ccamp-lmp-bootstrap does not support Trace Correlation.
> > > Therefore, it is an issue.
> > >
> > > Jonathan Sadler
> > >
> > > John Drake wrote:
> > > >
> > > > Is it the case that if one chooses to use J0/J1/J2 Trace
> Correlation,
> > then
> > > > Jonathan Sadler's issue is a non-issue?
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Lang
> > > > Sent: Thursday, November 21, 2002 8:56 AM
> > > > To: 'Brungard, Deborah A, ALASO '; '[e-mail] ';
> > > > 'ccamp '
> > > > Subject: FW: J0/J1 encoding issues
> > > >
> > > > Deborah,
> > > >   Thanks for the note. The option that Jonathan mentioned is one
> of a
> > > couple
> > > > options we define for Jx. We defined other options to
> > > > interwork with existing equipment without requiring any changes to
> > > > existing encodings (this would support both C1 and T.50
> requirements).
> > > > These mechanisms are defined in Section 3.1 as J0/J1/J2 Trace
> > > > Correlation. We welcome additional comments from you and others at
> > > > T1X1.5/ITU.
> > > >
> > > > Thanks,
> > > > Jonathan
> > > >
> > > > -----Original Message-----
> > > > From: Brungard, Deborah A, ALASO
> > > > To: [e-mail]; ccamp
> > > > Sent: 11/21/2002 5:22 AM
> > > > Subject: RE: J0/J1 encoding issues
> > > >
> > > > As Jonathan says, the current G.707 is using T.50. And there's
> more.
> > > > Example, for J0, one currently needs to support:
> > > > - previously defined C1 (repeating one-byte)
> > > > - T.50 (with format of G.707)
> > > > - no J0 (for equipment not supporting).
> > > >
> > > > So already we have defined multiple applications for this byte.
> Not to
> > > > say, there will be not any new ones. Even ITU knows, it never is
> > > > final;-)
> > > >
> > > > For supporting LMP's use, we need to understand the scenarios of
> use
> > > > (sounds familiar to T1X1.5 participants?) e.g. intra-operator,
> > > > inter-operator, applied for equipment installation verification or
> > > > service connection verification, etc. And hardware implications.
> > > >
> > > > Actually, G.831 defines multiple uses depending if inter or intra
> -
> > > > including for intra-operator, support of routing/path set-up (and
> G.831
> > > > was done years ago).
> > > >
> > > > Suggest, for timing, as a T1X1.5 meeting is dec 4-dec 5,
> contribute
> the
> > > > proposal for the meeting and we can start the discussion. The next
> ITU-T
> > > > meeting is in January. If the LMP editors need help on our T1X1.5
> > > > process, just ask.
> > > >
> > > > Deborah
> > > >
> > > > -----Original Message-----
> > > > From: Jonathan Sadler [mailto:[e-mail]]
> > > > Sent: Monday, November 18, 2002 7:59 PM
> > > > To: ccamp
> > > > Subject: J0/J1 encoding issues
> > > >
> > > > All -
> > > >
> > > > As mentioned at the CCAMP meeting, the SDH trace bytes (J0/J1/J2)
> > > > have restrictions not only on the length of a trace message and on
> > > > the bits usable in a octet, but also on whether the payload in the
> > > > message uses printable ASCII characters.
> > > >
> > > > The requirements for J0/J1/J2 (found in G.707) state the trace
> > > > message payload must utilize the printable characters defined in
> > > > T.50.  Two current LMP drafts (draft-ietf-ccamp-lmp-test-sonet-sdh
> &
> > > > draft-lang-ccamp-lmp-bootstrap) utilize encodings that are not
> > > > consistant with this requirement.
> > > >
> > > > This message is being sent to document this issue.  It is not a
> > > > statement that no other issues exist -- I expect that the
> appropriate
> > > > experts in the ITU will review the rest of these two drafts and
> > > > provide appropriate comment.
> > > >
> > > > Jonathan Sadler
> >
> > (I disclaim the disclaimer that follows this message.)
> > ===========================================================
> > The information contained in this message may be privileged
> > and confidential and protected from disclosure.  If the
> > reader of this message is not the intended recipient, or an
> > employee or agent responsible for delivering this message to
> > the intended recipient, you are hereby notified that any
> > reproduction, dissemination or distribution of this
> > communication is strictly prohibited. If you have received
> > this communication in error, please notify us immediately by
> > replying to the message and deleting it from your computer.
> >
> > Thank you.
> > Tellabs
> > ===========================================================
> ===========================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ===========================================================

-- 
Papadimitriou Dimitri 
E-mail : [e-mail] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [e-mail]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: [phone] - Home: [phone]