CSN Status & IETF Last Call (was: RE: Precondition for WG Last Call of the First Document Grouping

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartDD835571.1__=
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The more I think about it, it seems fine to be published as experimental. =
Mostly I just wanted to pull the syntax definition into a standalone I-D =
which can be toyed with on its own * I can't remember why I specified =
standards track. The real motivation is that we want to start publishing =
these types of values in operational attributes, and may want to start =
using them with synchronization-like mechanisms. When looking at the way =
its currently defined, there are some things I'd like to see changed, and =
felt that segregating it would be easier than trying to affect the info =
model draft.
=20
Jim

>>> "Chris Apple" <[email protected]> 11/18/03 7:28:23 AM >>>

Jim S: Please note the request for your input on CSN status near the =
bottom
of this e-mail.

-----Original Message-----
From: [email protected] [mailto:[email protected]] =
On
Behalf Of Kurt D. Zeilenga
Sent: Saturday, November 15, 2003 7:20 PM
To: [email protected]=20
Cc: [email protected]=20
Subject: Re: Precondition for WG Last Call of the First Document Grouping



I recommend:
LDAP Replication I-Ds be subject to IETF Last Call before being
considered by the IESG.

LDAP Replication I-Ds be progressed (IETF Last Called, IESG
consideration) as a set.

The former because LDAP Replication may have impact upon LDAP
implementations
which are not participating in the LDAP Replication experiment. The latter
because the individual I-Ds have a great deal of interdependencies.

CHRIS> Points duly noted. I do not personally see any harm in either
putting Informational and Experimental documents through an IETF Last Call
or not doing so. John and I would need to see others indicate that they
wish to proceed this way to make the request of our ADs.

CHRIS> Personally, I am conflicted about expressing support for waiting
until all I-Ds are ready for IETF Last Call. I recognize the interdependenc=
y
issues, but also believe that the way the co-chairs proposed that the
documents to be staged through the publication process limits various
risks involved in not waiting for a balloon-style IETF Last Call for all
documents. As a Co-Chair, I view this staging as consistent with the WG
Charter,
despite the slip in dates. I suppose that the IESG could decide to hold =
the
LDUP
documents until they are all ready for IETF Last Call. But that is a
decision they would have to make regardless of any request that John and I
might relay to them. And Since Ted is watching the LDUP list, I'm sure =
he'll
take your input into account when deciding what he should recommend to the
IESG. As usual, John and I would need to see others indicate that they =
wish
to proceed this way. Otherwise, we'll be sticking with our original intent
of
sending documents to our Ads as they are ready for IESG Consideration.

On the CSN discussion, I am in favor of splitting it out so that it can be
more easily referenced by other specifications. (On the technical side, I
concur that CSN should be defined in ASN.1 terms with LDAP-specific string
encodings.) However, I am not yet convinced that standard track would be
appropriate for this CSN specification, especially given previous =
consensus
(as reflected in the current charter) to pursue LDAP Replication off the
standards track.=20

Kurt

CHRIS> The rationale I recall from prior discussion about the CSN =
split-out
is that the CSN concept has a broader applicability than LDUP. That seems =
to
me to be sufficient justification for pursuing a standards-track publicatio=
n
path. I view this issue as one that is separable from the general concept =
of
LDUP being an Experimental concept/protocol. LDUP needs CSN to work even =
in
an experimental way. I certainly agree that this is not a sufficient
justification
alone for a standards-track path. But...perhaps Jim S. can shed some light
on the specific reasons he had for suggesting standards track for CSN? And
if others could chime in as well that would help us sort this out.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email protected]=20

http://www.dsi-consulting.com=20






--=__PartDD835571.1__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 5.50.4934.1600" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Microsoft Sans Serif">
<DIV>The more I think about it, it seems fine to be published as experiment=
al. Mostly I just wanted to pull the syntax&nbsp;definition into a =
standalone I-D which can be toyed with on its own =97 I can't remember why =
I specified standards track. The real motivation is that we want to start =
publishing these types of values in operational attributes, and may want =
to start using them with synchronization-like mechanisms. When looking at =
the way its currently defined, there are some things I'd like to see =
changed, and felt that segregating it would be easier than trying to =
affect the info model draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jim<BR><BR>&gt;&gt;&gt; "Chris Apple" &lt;[email protected]&gt=
; 11/18/03 7:28:23 AM &gt;&gt;&gt;<BR><BR>Jim S: Please note the request =
for your input on CSN status near the bottom<BR>of this e-mail.<BR><BR>----=
-Original Message-----<BR>From: <U><A href=3D"mailto:[email protected]=
mc.org">[email protected]</A></U> <U><A href=3D"mailto:[mailto:o=
[email protected]]">[mailto:[email protected]]</A></U>=
 On<BR>Behalf Of Kurt D. Zeilenga<BR>Sent: Saturday, November 15, 2003 =
7:20 PM<BR>To: <U><A href=3D"mailto:[email protected]">capple@dsi-c=
onsulting.net</A></U> <BR>Cc: <U><A href=3D"mailto:[email protected]">ietf-=
[email protected]</A></U> <BR>Subject: Re: Precondition for WG Last Call of the =
First Document Grouping<BR><BR><BR><BR>I recommend:<BR>LDAP Replication =
I-Ds be subject to IETF Last Call before being<BR>considered by the =
IESG.<BR><BR>LDAP Replication I-Ds be progressed (IETF Last Called, =
IESG<BR>consideration) as a set.<BR><BR>The former because LDAP Replication=
 may have impact upon LDAP<BR>implementations<BR>which are not participatin=
g in the LDAP Replication experiment. The latter<BR>because the individual =
I-Ds have a great deal of interdependencies.<BR><BR>CHRIS&gt; Points duly =
noted. I do not personally see any harm in either<BR>putting Informational =
and Experimental documents through an IETF Last Call<BR>or not doing so. =
John and I would need to see others indicate that they<BR>wish to proceed =
this way to make the request of our ADs.<BR><BR>CHRIS&gt; Personally, I am =
conflicted about expressing support for waiting<BR>until all I-Ds are =
ready for IETF Last Call. I recognize the interdependency<BR>issues, but =
also believe that the way the co-chairs proposed that the<BR>documents to =
be staged through the publication process limits various<BR>risks involved =
in not waiting for a balloon-style IETF Last Call for all<BR>documents. As =
a Co-Chair, I view this staging as consistent with the WG<BR>Charter,<BR>de=
spite the slip in dates. I suppose that the IESG could decide to hold =
the<BR>LDUP<BR>documents until they are all ready for IETF Last Call. But =
that is a<BR>decision they would have to make regardless of any request =
that John and I<BR>might relay to them. And Since Ted is watching the LDUP =
list, I'm sure he'll<BR>take your input into account when deciding what he =
should recommend to the<BR>IESG. As usual, John and I would need to see =
others indicate that they wish<BR>to proceed this way. Otherwise, we'll be =
sticking with our original intent<BR>of<BR>sending documents to our Ads as =
they are ready for IESG Consideration.<BR><BR>On the CSN discussion, I am =
in favor of splitting it out so that it can be<BR>more easily referenced =
by other specifications. (On the technical side, I<BR>concur that CSN =
should be defined in ASN.1 terms with LDAP-specific string<BR>encodings.) =
However, I am not yet convinced that standard track would be<BR>appropriate=
 for this CSN specification, especially given previous consensus<BR>(as =
reflected in the current charter) to pursue LDAP Replication off the<BR>sta=
ndards track. <BR><BR>Kurt<BR><BR>CHRIS&gt; The rationale I recall from =
prior discussion about the CSN split-out<BR>is that the CSN concept has a =
broader applicability than LDUP. That seems to<BR>me to be sufficient =
justification for pursuing a standards-track publication<BR>path. I view =
this issue as one that is separable from the general concept of<BR>LDUP =
being an Experimental concept/protocol. LDUP needs CSN to work even =
in<BR>an experimental way. I certainly agree that this is not a sufficient<=
BR>justification<BR>alone for a standards-track path. But...perhaps Jim S. =
can shed some light<BR>on the specific reasons he had for suggesting =
standards track for CSN? And<BR>if others could chime in as well that =
would help us sort this out.<BR><BR>Chris Apple - Principal Architect<BR><B=
R>DSI Consulting, Inc.<BR><BR><U><A href=3D"mailto:[email protected]=
t">mailto:[email protected]</A></U> <BR><BR><U><A href=3D"http://ww=
w.dsi-consulting.com/">http://www.dsi-consulting.com</A></U> <BR><BR><BR><B=
R></DIV></BODY></HTML>

--=__PartDD835571.1__=--