RE: CSN Status & IETF Last Call (was: RE: Precondition for WGLast Call of the First Document Grouping
"Chris Apple" <[email protected]> Tue, 18 Nov 2003 11:14:33 -0500
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <003f01c3adef$0f8836c0$0300a8c0@D7ST2111> |
This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C3ADC5.26B22EC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks - that changes things a bit. =20 Rather than label it as Experimental though, it would seem better to = keep the Informational designation of the information model document giving rise to it. =20 I still need to hear from the editors of the Information Model document about being able to revise it in a timely manner. =20 Chris. -----Original Message----- From: Jim Sermersheim [mailto:[email protected]]=20 Sent: Tuesday, November 18, 2003 10:57 AM To: [email protected]; [email protected] Cc: [email protected] Subject: CSN Status & IETF Last Call (was: RE: Precondition for WGLast = Call of the First Document Grouping 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 = interdependency 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 = publication 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 <http://www.dsi-consulting.com/> =20 ------=_NextPart_000_0040_01C3ADC5.26B22EC0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Microsoft Sans Serif"> <DIV><SPAN class=3D064221216-18112003>Thanks - that changes things a=20 bit.</SPAN></DIV> <DIV><SPAN class=3D064221216-18112003></SPAN> </DIV> <DIV><SPAN class=3D064221216-18112003>Rather than label it as = Experimental though,=20 it would seem better to keep the Informational designation of the = information=20 model</SPAN></DIV> <DIV><SPAN class=3D064221216-18112003>document giving rise to = it.</SPAN></DIV> <DIV><SPAN class=3D064221216-18112003></SPAN> </DIV> <DIV><SPAN class=3D064221216-18112003>I still need to hear from the = editors of the=20 Information Model document about being able to revise it in a timely=20 manner.</SPAN></DIV> <DIV><SPAN class=3D064221216-18112003></SPAN> </DIV> <DIV><SPAN class=3D064221216-18112003>Chris.</SPAN></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma>-----Original Message-----<BR><B>From:</B> Jim = Sermersheim=20 [mailto:[email protected]] <BR><B>Sent:</B> Tuesday, November 18, 2003 = 10:57=20 AM<BR><B>To:</B> [email protected]; = [email protected]<BR><B>Cc:</B>=20 [email protected]<BR><B>Subject:</B> CSN Status & IETF Last Call = (was: RE:=20 Precondition for WGLast Call of the First Document=20 Grouping<BR><BR></FONT></DIV> <DIV>The more I think about it, it seems fine to be published as = experimental.=20 Mostly I just wanted to pull the syntax definition into a = standalone I-D=20 which can be toyed with on its own — I can't remember why I = specified=20 standards track. The real motivation is that we want to start = publishing these=20 types of values in operational attributes, and may want to start using = them=20 with synchronization-like mechanisms. When looking at the way its = currently=20 defined, there are some things I'd like to see changed, and felt that=20 segregating it would be easier than trying to affect the info model=20 draft.</DIV> <DIV> </DIV> <DIV>Jim<BR><BR>>>> "Chris Apple" = <[email protected]>=20 11/18/03 7:28:23 AM >>><BR><BR>Jim S: Please note the request = for=20 your input on CSN status near the bottom<BR>of this=20 e-mail.<BR><BR>-----Original Message-----<BR>From: <U><A=20 = href=3D"mailto:[email protected]">[email protected]= </A></U>=20 <U><A=20 = href=3D"mailto:[mailto:[email protected]]">[mailto:owner-ietf-= [email protected]]</A></U>=20 On<BR>Behalf Of Kurt D. Zeilenga<BR>Sent: Saturday, November 15, 2003 = 7:20=20 PM<BR>To: <U><A=20 = href=3D"mailto:[email protected]">[email protected]</A></= U>=20 <BR>Cc: <U><A = href=3D"mailto:[email protected]">[email protected]</A></U>=20 <BR>Subject: Re: Precondition for WG Last Call of the First Document=20 Grouping<BR><BR><BR><BR>I recommend:<BR>LDAP Replication I-Ds be = subject to=20 IETF Last Call before being<BR>considered by the IESG.<BR><BR>LDAP = Replication=20 I-Ds be progressed (IETF Last Called, IESG<BR>consideration) as a=20 set.<BR><BR>The former because LDAP Replication may have impact upon=20 LDAP<BR>implementations<BR>which are not participating in the LDAP = Replication=20 experiment. The latter<BR>because the individual I-Ds have a great = deal of=20 interdependencies.<BR><BR>CHRIS> Points duly noted. I do not = personally see=20 any harm in either<BR>putting Informational and Experimental documents = through=20 an IETF Last Call<BR>or not doing so. John and I would need to see = others=20 indicate that they<BR>wish to proceed this way to make the request of = our=20 ADs.<BR><BR>CHRIS> Personally, I am conflicted about expressing = support for=20 waiting<BR>until all I-Ds are ready for IETF Last Call. I recognize = the=20 interdependency<BR>issues, but also believe that the way the co-chairs = proposed that the<BR>documents to be staged through the publication = process=20 limits various<BR>risks involved in not waiting for a balloon-style = IETF Last=20 Call for all<BR>documents. As a Co-Chair, I view this staging as = consistent=20 with the WG<BR>Charter,<BR>despite the slip in dates. I suppose that = the IESG=20 could decide to hold the<BR>LDUP<BR>documents until they are all ready = for=20 IETF Last Call. But that is a<BR>decision they would have to make = regardless=20 of any request that John and I<BR>might relay to them. And Since Ted = is=20 watching the LDUP list, I'm sure he'll<BR>take your input into account = when=20 deciding what he should recommend to the<BR>IESG. As usual, John and I = would=20 need to see others indicate that they wish<BR>to proceed this way. = Otherwise,=20 we'll be sticking with our original intent<BR>of<BR>sending documents = to our=20 Ads as they are ready for IESG Consideration.<BR><BR>On the CSN = discussion, I=20 am in favor of splitting it out so that it can be<BR>more easily = referenced by=20 other specifications. (On the technical side, I<BR>concur that CSN = should be=20 defined in ASN.1 terms with LDAP-specific string<BR>encodings.) = However, I am=20 not yet convinced that standard track would be<BR>appropriate for this = CSN=20 specification, especially given previous consensus<BR>(as reflected in = the=20 current charter) to pursue LDAP Replication off the<BR>standards = track.=20 <BR><BR>Kurt<BR><BR>CHRIS> The rationale I recall from prior = discussion=20 about the CSN split-out<BR>is that the CSN concept has a broader = applicability=20 than LDUP. That seems to<BR>me to be sufficient justification for = pursuing a=20 standards-track publication<BR>path. I view this issue as one that is=20 separable from the general concept of<BR>LDUP being an Experimental=20 concept/protocol. LDUP needs CSN to work even in<BR>an experimental = way. I=20 certainly agree that this is not a = sufficient<BR>justification<BR>alone for a=20 standards-track path. But...perhaps Jim S. can shed some light<BR>on = the=20 specific reasons he had for suggesting standards track for CSN? = And<BR>if=20 others could chime in as well that would help us sort this = out.<BR><BR>Chris=20 Apple - Principal Architect<BR><BR>DSI Consulting, Inc.<BR><BR><U><A=20 = href=3D"mailto:[email protected]">mailto:[email protected]= t</A></U>=20 <BR><BR><U><A=20 = href=3D"http://www.dsi-consulting.com/">http://www.dsi-consulting.com</A>= </U>=20 <BR><BR><BR><BR></DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0040_01C3ADC5.26B22EC0--