Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkBA-0001LD-DX; Thu, 18 May 2006 11:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkB9-0001L8-5R for dhcwg@ietf.org; Thu, 18 May 2006 11:12:43 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgkB7-0007gw-N2 for dhcwg@ietf.org; Thu, 18 May 2006 11:12:43 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 5723D20093; Thu, 18 May 2006 11:12:41 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04600-02; Thu, 18 May 2006 11:12:40 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 29F392001D; Thu, 18 May 2006 11:12:40 -0400 (EDT) To: "David W. Hankins" Subject: Re: [dhcwg] VIV*O options. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Thu, 18 May 2006 11:12:39 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/18/2006 11:12:39 AM Content-Type: multipart/mixed; boundary="=_mixed 005392AF85257172_=" X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --=_mixed 005392AF85257172_= Content-Type: multipart/alternative; boundary="=_alternative 005392AF85257172_=" --=_alternative 005392AF85257172_= Content-Type: text/plain; charset="us-ascii" > Does anyone know of a client or server that has implemented VIV*O (RFC3925)? > I'm looking for targets for interoperability testing. Yes, we implemented option 124/125 interaction (also 60/43) as part of our updating of VoIP clients and servers due to RFC 3942 Options Reclassification. If interested in interop testing, please contact me directly (off list). Peter Blatherwick Sr. Solutions Architect, Mitel Networks peter_blatherwick@mitel.com 613-592-5660, x-1553 "David W. Hankins" 17.05.06 14:57 To: dhcwg@ietf.org cc: Subject: [dhcwg] VIV*O options. Does anyone know of a client or server that has implemented VIV*O (RFC3925)? I'm looking for targets for interoperability testing. RFC4243 relay agents would be interesting too. While looking at this, I had to come to grips with a minor code reuse problem I'd like to solicit opinions on. We currently use the same code to dissect the options buffer as we do any encapsulated space (so, VIV*O would use this as well). This loop that traverses options looks for PAD and END options, which RFC 3925 explicitly states are not special cases, with no special handling. Unless I'm mistaken, RFC 4243 makes no mention. That means I get to add more instructions to this loop, or write a new loop, neither of which I particularly fancy. However, enterprise id 0 is reserved according to IANA, which I take to mean is an illegal value, so it shouldn't appear in packets at all. My most-code-reused solution, then, is to use 0x00000000 as both PAD and END options for this encapsulated space (END trumps PAD, so this causes the server to stop processing the buffer if it's encountered - a zero is effectively an error condition). That would be true for any encapsulated space with no defined END option. What are folks opinions on this approach, not just for VIV*O, but for encapsulated spaces in general? -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --=_alternative 005392AF85257172_= Content-Type: text/html; charset="us-ascii"
> Does anyone know of a client or server that has implemented VIV*O (RFC3925)?
> I'm looking for targets for interoperability testing.
Yes, we implemented option 124/125 interaction (also 60/43) as part of our updating of VoIP clients and servers due to RFC 3942 Options Reclassification.  If interested in interop testing, please contact me directly (off list).

Peter Blatherwick
Sr. Solutions Architect, Mitel Networks
peter_blatherwick@mitel.com
613-592-5660, x-1553




"David W. Hankins" <David_Hankins@isc.org>

17.05.06 14:57

       
        To:        dhcwg@ietf.org
        cc:        
        Subject:        [dhcwg] VIV*O options.



Does anyone know of a client or server that has implemented VIV*O (RFC3925)?
I'm looking for targets for interoperability testing.

RFC4243 relay agents would be interesting too.


While looking at this, I had to come to grips with a minor code reuse
problem I'd like to solicit opinions on.

We currently use the same code to dissect the options buffer as we do
any encapsulated space (so, VIV*O would use this as well).

This loop that traverses options looks for PAD and END options, which
RFC 3925 explicitly states are not special cases, with no special
handling.  Unless I'm mistaken, RFC 4243 makes no mention.

That means I get to add more instructions to this loop, or write a new
loop, neither of which I particularly fancy.

However, enterprise id 0 is reserved according to IANA, which I take to
mean is an illegal value, so it shouldn't appear in packets at all.

My most-code-reused solution, then, is to use 0x00000000 as both PAD
and END options for this encapsulated space (END trumps PAD, so this
causes the server to stop processing the buffer if it's encountered -
a zero is effectively an error condition).

That would be true for any encapsulated space with no defined END option.

What are folks opinions on this approach, not just for VIV*O, but for
encapsulated spaces in general?

--
David W. Hankins                                  "If you don't do it right the first time,
Software Engineer                                                   you'll just have to do it again."
Internet Systems Consortium, Inc.                                  -- Jack T. Hankins
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

--=_alternative 005392AF85257172_=-- --=_mixed 005392AF85257172_= Content-Type: application/octet-stream; name="attlihxs.dat" Content-Disposition: attachment; filename="attlihxs.dat" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMiAoR05V L0xpbnV4KQ0KDQppRDhEQlFGRWEzSXFjWGVMZVd1MnZtb1JBdEZkQUo0NW1mSk9QMXhaU1BrdDFF bkpYWTgrTHNTRXRBQ2ZTWDdVDQoya3ZwUGpLdHRKUmZ0NUZKeWxNYk9qST0NCj1kdE1CDQotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 005392AF85257172_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --=_mixed 005392AF85257172_=--