Hi folks,
Please note this important piece of SLPv2 - standard method for
avoiding naming collisions in private namespaces - this will now be
incorporated into the revised SLPv2 Protocol (updates to RFC 2608
now in progress) along with other extensions and clarifications.
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Erik Guttman [mailto:erikg at germany.sun.com]
Sent: Tuesday, November 27, 2001 6:39 AM
To: SLP standardization project
Subject: [Srvloc-discuss] Protocol Action: Vendor Extensions for Service
Location Protocol, Version 2 to Proposed Standard (Fwd)
Folks,
Another SLP document to standards track. This one updates RFC2608
by changing the recommendation for how to do nonstandard attributes
and naming authorities so that there are no name collisions in the
SLP user community.
Based on past experience, I believe it will take something like
2 months before an RFC will appear.
Erik
---------- Forwarded message ----------
Date: Mon, 26 Nov 2001 18:45:36 -0500
From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>,
Internet Architecture Board <iab at isi.edu>
Subject: Protocol Action: Vendor Extensions for Service Location Protocol,
Version 2 to Proposed Standard
The IESG has approved the Internet-Draft 'Vendor Extensions for Service
Location Protocol, Version 2' <draft-guttman-svrloc-vendor-ext-07.txt>
as a Proposed Standard.
This has been reviewed in the IETF but is not the product of an IETF
Working Group. The IESG contact persons Thomas Narten and Erik
Nordmark.
Technical Summary
The Service Location Protocol, Version 2 [RFC 2608] allows for
vendor extensibility. This document clarifies how to make use of
such vendor extensions in order to minimize the chances of name
space collisions. This document also defines a Vendor Opaque
Extension, which makes it possible for a vendor to extend SLP
independently, once the vendor has registered itself with IANA and
obtained an Enterprise Number.
Working Group Summary
There were no issues raised during the Last Call period.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
Note to RFC Editor:
Please change references [4] and [8] to reference
<http://www.iana.org/numbers.html>
_______________________________________________
Srvloc-discuss mailing list
Srvloc-discuss at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/srvloc-discuss