Subject: Re: [Capwap] [Fwd: Informational RFC to be:draft-narasimhan-ietf-slapp-01.txt]

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 8 Feb 2007 20:22:22 -0800

I disagree. Having over 15 years of ietf experience, i've seen it happen over and over again.

PatC

 -----Original Message-----
From: 	Hong Cheng [mailto:[email-masked]]
Sent:	Thursday, February 08, 2007 08:18 PM Pacific Standard Time
To:	Pat Calhoun (pacalhou)
Cc:	Behcet Sarikaya; Margaret Wasserman; Romascanu, Dan ((Dan)); capwap
Subject:	Re: [Capwap] [Fwd: Informational RFC to	be:draft-narasimhan-ietf-slapp-01.txt]

Hi Pat,

Your concern is not a valid reason for NOT publishing the draft. I think 
the proper way to go is placing a clear disclaimer in the informational 
RFC.

If people can adopt an informational RFC without really reading through 
it carefully, it cannot be helped. Even if we public those RFCs after 
the WG standard track RFC, they may take them as CAPWAP-v2 and use those 
instead of the WG *standard* RFC.

As your email pointed out, these informational RFCs are defining 
different protocols (with different names than the *standard* CAPWAP 
protocol), I don't think people would be confused.

cheers

Cheng

Pat Calhoun (pacalhou) wrote:
> I disagree. These are separate protocols and do not need to be referenced.
>  
> I also agree that the RFC publication should be held back. There is a 
> large class of customers out there that do not understand the difference 
> between standards and informational RFCs. To them, an RFC is an RFC 
> and since it is published by IETF, it good enough for adoption. I 
> believe that the IETF would best serve the Internet Community by making 
> sure that the first RFC published by the WG is *the* standard.
>  
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
>     ------------------------------------------------------------------------
>     *From:* Behcet Sarikaya [mailto:[email-masked]]
>     *Sent:* Wednesday, February 07, 2007 8:33 AM
>     *To:* Margaret Wasserman; Romascanu, Dan ((Dan))
>     *Cc:* capwap
>     *Subject:* Re: [Capwap] [Fwd: Informational RFC to
>     be:draft-narasimhan-ietf-slapp-01.txt]
> 
>     As a member of the eval team, I favor referencing RFC 4565 in CAPWAP
>     RFCs. I believe that should be it. RFC 4565 clearly explains all
>     four protocols (by the way there was one more, i.e. three documents
>     that were not recommended not two) and makes recommendations on the
>     way to go which is what is happening now.
>      
>     For historical purposes, the expired drafts can always be found in
>     the draft repositories.
>      
>     Regards,
>      
>     Behcet
> 
>     ----- Original Message ----
>     From: Margaret Wasserman <[email-masked]>
>     To: "Romascanu, Dan ((Dan))" <[email-masked]>
>     Cc: capwap <[email-masked]>
>     Sent: Tuesday, February 6, 2007 1:33:08 PM
>     Subject: Re: [Capwap] [Fwd: Informational RFC to be:
>     draft-narasimhan-ietf-slapp-01.txt]
> 
>     Hi Dan,
> 
>     Yes, I was expressing my personal opinion.  I personally think that  
>     publication of these drafts should be delayed until after the CAPWAP  
>     RFCs are published.  Other members of the WG are encouraged to share  
>     their opinions, so that we can see if any WG consensus exists on this  
>     topic.
> 
>     For WG members who may not be familiar with this process, the  
>     documents in question were submitted as individual submissions to the  
>     RFC editor.  The authors have requested that they be published as RFC  
>     Editor Informational documents, and the guidelines for publication of  
>     such documents are described in RFC 3932, which can be found here:
> 
>     http://www.ietf.org/rfc/rfc3932.txt?number=3932
> 
>     As RFC 3932 indicates, the RFC editor has already conducted a  
>     technical review of these documents, and they are not requesting  
>     further technical review.  The RFC editor is now asking the IESG to  
>     review the documents for conflicts with the IETF standards process or  
>     work being done in the IETF community.
> 
>     Here is a description from RFC 3932 of a situation in which the IESG  
>     may claim that a document conflicts with ongoing work:
> 
>         Rejected Alternative Bypass: A WG is working on a solution to a
>         problem, and a participant decides to ask for publication of a
>         solution that the WG has rejected.  Publication of the document will
>         give the publishing party an RFC number to refer to before the WG is
>         finished.  It seems better to have the WG product published first,
>         and have the non-adopted document published later, with a clear
>         disclaimer note saying that "the IETF technology for this  
>     function is
>         X".
> 
>     As input to the IESG's decision, Dan has asked for the CAPWAP WG's  
>     opinion about whether these two drafts (draft-narasimhan-ietf-
>     slapp-01.txt and draft-iino-capwap-wicop-02.txt) interfere with work  
>     being done in the CAPWAP WG.
> 
>     So, what do you all think about this situation?  Would the  
>     publication of these documents as RFCs at this time conflict with the  
>     work of the CAPWAP WG, as described above?  Or should the IESG return  
>     a response that indicates that these documents are related to our  
>     work, but that they do not conflict with it?
> 
>     Thanks,
>     Margaret
> 
>     On Feb 6, 2007, at 1:56 PM, Romascanu, Dan ((Dan)) wrote:
> 
>      > Margaret,
>      >
>      > As you probably know according to RFC 3932 the final decision for
>      > publication of these documents belongs to the RFC Editor. The
>     IESG has
>      > an advisory role concerning the relation of the documents to work  
>      > being
>      > done in the IETF. The IESG may still decide to publish the documents
>      > despite a negative recommendation from the IESG, with an appropriate
>      > IESG note.
>      >
>      > Is this you opinion as an individual?
>      >
>      > You may want to check the consensus of the WG, you still have until  
>      > 2/19
>      > for this purpose, and a position backed by WG consensus may have more
>      > weight in the recommendation that the iESG will make.
>      >
>      > Dan
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >> -----Original Message-----
>      >> From: Margaret Wasserman [mailto:[email-masked]]
>      >> Sent: Tuesday, February 06, 2007 3:14 PM
>      >> To: Romascanu, Dan (Dan)
>      >> Cc: capwap
>      >> Subject: Re: [Capwap] [Fwd: Informational RFC to be:
>      >> draft-narasimhan-ietf-slapp-01.txt]
>      >>
>      >>
>      >> Hi Dan,
>      >>
>      >> Don't we usually hold-off on publishing alternative
>      >> proprietary protocols until after the IETF standard protocol
>      >> is published?
>      >>
>      >> I'd prefer to see publication of this draft and the one you
>      >> mentioned in your previous message
>      >> (draft-iino-capwap-wicop-02.txt) delayed until after the
>      >> standards-track CAPWAP RFC is published.
>      >>
>      >> Thanks,
>      >> Margaret
>      >>
>      >>
>      >> On Feb 6, 2007, at 5:17 AM, Romascanu, Dan (Dan) wrote:
>      >>
>      >>>
>      >>>
>      >>> The following request to publish draft-narasimhan-ietf-slapp as an
>      >>> Informational RFC was submitted to the RFC Editor. Please
>      >> let me know
>      >>> if there are any issues or comments.
>      >>>
>      >>> Dan
>      >>>
>      >>>
>      >>>
>      >>>>>
>      >>>>> IESG,
>      >>>>>
>      >>>>> This RFC-to-be was submitted to the RFC Editor to be published as
>      >>>>> Informational: draft-narasimhan-ietf-slapp-01.txt.
>      >>>>>
>      >>>>> Please let us know if this document conflicts with the IETF
>      >>>>> standards
>      >>>
>      >>>>> process or other work being done in the IETF community.
>      >>>>>
>      >>>>> Four week timeout expires on 20 February 2007.
>      >>>>>
>      >>>>> _________________________________________________________________
>      >>>>>
>      >>>>> NOTE to IESG about:  draft-narasimhan-ietf-slapp-01.txt
>      >>>>>
>      >>>>> This document, submitted to the RFC Editor as an independent
>      >>>>> submission by the WG chair, was a partial product of the CAPWAP
>      >>>>> working group.
>      >>>>> Its publication now is intended to be provide historical
>      >> record of
>      >>>>> input to the WG product, and as such the RFC Editor is exercising
>      >>>>> minimal editorial control over it.
>      >>>>>
>      >>>>> The RFC Editorial Board raised considerable issue with
>      >> the principle
>      >>>>> of publishing such a "WG spinoff" document as an independent
>      >>>>> submission, rather than as a WG or individual submission.
>      >>  This led
>      >>>>> the RFC
>      >>>> Editor
>      >>>>> to request a policy opinion from the IAB, but no such
>      >> policy opinion
>      >>>>> was provided.
>      >>>>>
>      >>>>> We do not regard publication of this document as an independent
>      >>>>> submission to be a precedent.  However, we would REALLY like to
>      >>>>> clear
>      >>>
>      >>>>> our ISR queue, and so we are proceeding with its publication.
>      >>>>>
>      >>>>> We intend to include the following RFC Editor Note, in
>      >> addition to
>      >>>>> any note requested by the IESG:
>      >>>>>
>      >>>>>
>      >>>>>     "RFC Editor Note:
>      >>>>>
>      >>>>>     This document was originally submitted to the CAPWAP Working
>      >>>>>     Group.  It is being published now as a historical record
>     of the
>      >>>>>     development of CAPWAP ideas; it is not an official Working
>      >>>>>     Group product."
>      >>>>>
>      >>>>> ___________________________________________________
>      >>>>>
>      >>>>>                  SLAPP : Secure Light Access Point Protocol
>      >>>>>
>      >>>>>    The CAPWAP problem statement [3] describes a problem
>      >> that needs
>      >>>>> to
>      >>>
>      >>>>> be
>      >>>>>    addressed before a wireless LAN (WLAN) network designer can
>      >>>>>    construct a solution composed of Wireless Termination Points
>      >>>>> (WTP)
>      >>>>>    and Access Controllers (AC) from multiple, different
>      >> vendors.
>      >>>>> One
>      >>>>>    of the primary goals is to find a solution that solves the
>      >>>>>    interoperability between the two classes of devices (WTPs and
>      >>>>> ACs)
>      >>>>>    which then enables an AC from one vendor to control
>      >> and manage a
>      >>>>> WTP
>      >>>>>    from another.
>      >>>>>
>      >>>>>    The interoperability problem is more general than as stated in
>      >>>>> the
>      >>>>>    CAPWAP problem statement [3] because it can arise out of other
>      >>>>>    networks that do not necessarily involve WLAN or any wireless
>      >>>>>    devices.  A similar problem exists in any network that is
>      >>>>> composed
>      >>>>>    of network elements that are managed by a centralized
>      >> controller
>      >>>>>    where these two classes of devices are from different
>      >> vendors and
>      >>>>>    need to interoperate with each other such that the network
>      >>>> elements
>      >>>>>    can be controlled and managed by the controller.
>      >>>>>
>      >>>>>    A possible solution to this problem is to split it into two
>      >>>> parts -
>      >>>>>    one that is technology or application independent
>      >> which serves as
>      >>>> a
>      >>>>>    common framework across multiple underlying technologies, and
>      >>>>>    another that is dependent on the underlying technology that is
>      >>>>> being
>      >>>>>    used in the network.  For example, methods and
>      >> parameters used by
>      >>>>> an
>      >>>>>    802.11 AC to configure and manage a network of 802.11 WTPs are
>      >>>>>    expected to be quite different than that used by an equivalent
>      >>>>>    802.16 controller to manage a network of 802.16 base stations.
>      >>>> The
>      >>>>>    architectural choices for these two underlying
>      >> technologies may
>      >>>>> also
>      >>>>>    be significantly different.
>      >>>>>
>      >>>>>    In this draft, we present a protocol that forms the common
>      >>>>>    technology-independent framework and the ability to
>      >> negotiate and
>      >>>>>    add, on top of this framework, a control protocol that
>      >> contains a
>      >>>>>    technology-dependent component to arrive at a complete
>      >> solution.
>      >>>>> We
>      >>>>>    have also presented two such control protocols - an 802.11
>      >>>>> Control
>      >>>>>    protocol, and another a more generic image download
>      >> protocol, in
>      >>>>>    this draft.
>      >>>>>
>      >>>>>    Even though the text in this draft is written to specifically
>      >>>>>    address the problem stated in [3], the solution can be
>      >> applied to
>      >>>>>    any problem that has a controller (equivalent to the
>      >> AC) managing
>      >>>>>    one or more network elements (equivalent to the WTP).
>      >>>>>
>      >>>>> Sincerely,
>      >>>>>
>      >>>>> Sandy Ginoza - USC/ISI
>      >>>>> Request for Comments Documents
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>
>      >>>>
>      >>>
>      >>> _________________________________________________________________
>      >>> To unsubscribe or modify your subscription options, please visit:
>      >>> http://lists.frascone.com/mailman/listinfo/capwap
>      >>>
>      >>> Archives: http://lists.frascone.com/pipermail/capwap
>      >>
> 
>     _________________________________________________________________
>     To unsubscribe or modify your subscription options, please visit:
>     http://lists.frascone.com/mailman/listinfo/capwap
> 
>     Archives: http://lists.frascone.com/pipermail/capwap
> 
> 
> ------------------------------------------------------------------------
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap