Subject: Re: [Capwap] Terminology section

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 25 May 2006 13:04:09 +0800

Hi David,

Can you please clarify why you think references to previous
Informational documents are inappropriate? 

Saravanan

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 11:40 AM
To: Saravanan Govindan
Cc: Pat Calhoun (pacalhou); capwap
Subject: Re: [Capwap] Terminology section

HI,

I believe that it is inappropriate to make reference to
RFC4118 or objectives I-D in the CAPWAP document. If
there are needed text, it should be cut and pasted
into the CAPWAP document. This is because the CAPWAP
document should be independent from this documents.

Regards,
/david t. perkins

On Thu, 25 May 2006, Saravanan Govindan wrote:
> Here are additional terms that I think can be included a new
Terminology
> section. The latter 2 are from Section 13.1 "CAPWAP Security".
> 
> 
> [Proposed text]
> 
> 1.5.	Terminology
> 
> This document follows the terminologies of [RFC4118] and [OBJECTIVES].
> Additionally, the following terms are defined;
> 
> WLAN: A WLAN represents a Logical Group as defined in [OBJECTIVES].
> 
> Protected Data: Refers to CAPWAP messages exchanged between
> authenticated peers with encryption.
> 
> Unprotected Data: Refers to CAPWAP messages exchanged between
> authenticated peers without encryption.
> 
> [End of proposed text]
> 
> 
> Saravanan 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 10:15 PM
> To: Saravanan Govindan
> Subject: RE: [Capwap] Terminology section
> 
> Then how about you send me a final set of proposed terminologies once
> you are done, then I will create the issue.
> 
> Sound fair?
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
> > -----Original Message-----
> > From: Saravanan Govindan
[mailto:[email-masked]] 
> > Sent: Tuesday, May 23, 2006 6:28 PM
> > To: Pat Calhoun (pacalhou); [email-masked]
> > Subject: RE: [Capwap] Terminology section
> > 
> > Pat,
> > 
> > I think more text may be required for other definitions. I am 
> > still in reading the draft for any new terms we are using. 
> > 
> > Saravanan
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> > Sent: Wednesday, May 24, 2006 1:10 AM
> > To: Saravanan Govindan; [email-masked]
> > Subject: RE: [Capwap] Terminology section
> > 
> > Saravanan, I wasn't sure if the text below was complete, or whether
> > --XX-- implied "more text here".
> > 
> > Could you help clarify, after which I will create an issue to 
> > track this change request.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Saravanan Govindan 
> > [mailto:[email-masked]]
> > > Sent: Tuesday, May 23, 2006 12:08 AM
> > > To: [email-masked]
> > > Subject: [Capwap] Terminology section
> > > 
> > > All,
> > > 
> > > Following from an earlier note, this is the proposed section on 
> > > terminologies used in the CAPWAP Specifications.
> > > 
> > > Comments appreciated.
> > > 
> > > [Insert new subsection in Section 1 "Introduction"]
> > > 
> > > 1.5.	Terminology
> > > 
> > > This document follows the terminologies of [RFC4118] and 
> > [OBJECTIVES].
> > > Additionally, the following terms are defined;
> > > 
> > > WLAN: A WLAN represents a Logical Group as defined in
[OBJECTIVES].
> > > 
> > > --XX--
> > > 
> > > 
> > > 
> > > Saravanan
> > > 
> > > 
> > > 
> > > _________________________________________________________________
> > > 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

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 25 May 2006 08:41:42 -0700 (PDT)

HI,

I believe that having RFC4118 and the Objectives I-D
as normative references is inappropriate.

For me, specifications that are complete, consistent,
and have minimal dependencies on other documents are
easier to understand, write code, and use for deployment.

Regards,
/david t. perkins

---

From: "Margaret Wasserman" <[email-masked]>
Date: Thu, 25 May 2006 11:50:07 -0400

Hi All,

> I believe that having RFC4118 and the Objectives I-D as 
> normative references is inappropriate.
> 
> For me, specifications that are complete, consistent, and 
> have minimal dependencies on other documents are easier to 
> understand, write code, and use for deployment.

I agree with David's points, but this is not just a matter or taste and/or a
matter to be decided by rough consensus of the WG.

For CAPWAP to be published as a Standards-Track specification, it cannot
have normative dependencies on Informational documents.  Referencing
Informational RFCs from Standards-Track RFCs is called a "down reference"
and it is only allowed in the IETF under certain specific conditions, none
of which would seem to apply here.

Margaret

---

From: <[email-masked]>
Date: Thu, 25 May 2006 10:20:27 -0700

Hi Margaret,

We worked on publishing the Objectives draft in conjunction with the ADs
and this was approved by the IESG.  
Obviously, the remaining work in CAPWAP is dependent on the Objectives
we have already published.  This was the purpose of the Objectives
draft.

What would you recommend we do in this situation?  Re-write the
objectives within the specification and then refer to the Objectives
draft for further information?

We are just trying to write a readable protocol document here.  There
should be a reasonable way to do this in a manner that is appropriate in
the IETF.

Best Regards,
Dorothy

-----Original Message-----
From: ext Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 8:50 AM
To: 'David T. Perkins'; 'Saravanan Govindan'
Cc: 'capwap'
Subject: Re: [Capwap] Terminology section

Hi All,

> I believe that having RFC4118 and the Objectives I-D as normative 
> references is inappropriate.
> 
> For me, specifications that are complete, consistent, and have minimal

> dependencies on other documents are easier to understand, write code, 
> and use for deployment.

I agree with David's points, but this is not just a matter or taste
and/or a matter to be decided by rough consensus of the WG.

For CAPWAP to be published as a Standards-Track specification, it cannot
have normative dependencies on Informational documents.  Referencing
Informational RFCs from Standards-Track RFCs is called a "down
reference"
and it is only allowed in the IETF under certain specific conditions,
none of which would seem to apply here.

Margaret

---

From: "Margaret Wasserman" <[email-masked]>
Date: Thu, 25 May 2006 13:38:32 -0400

Hi Dorothy,

Informative references are okay, the requirement is that you avoid
_Normative_ references to an Informational document from a Standards-Track
document.
  
So, you shouldn't need to restate all of the objectives in the protocol
specification.  If you want to give readers a pointer to the objectives
document and/or indicate how a particular feature relates to the objectives,
you can simply include an Informative reference to the objectives document.
Informative references are appropriate when the reader may want to look at
another document for background information or wider understanding.

However, you need to avoid Normative references to the objectives document.
In other words, it should be possible to understand and implement the CAPWAP
specification without reading the objectives document.  It isn't possible to
read and understand a document without knowing how the terminology is
defined, a reference to the objectives document for the terminology
definitions would be a Normative reference.  To avoid a Normative reference
to the objectives document, you would simply include the same terminology
definitions in the protocol specification.  You can even mention that they
originally came from the objective document, if you like, which would then
be an Informative reference.

Does that make sense?

Margaret

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, May 25, 2006 1:20 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> We worked on publishing the Objectives draft in conjunction 
> with the ADs and this was approved by the IESG.  
> Obviously, the remaining work in CAPWAP is dependent on the 
> Objectives we have already published.  This was the purpose 
> of the Objectives draft.
> 
> What would you recommend we do in this situation?  Re-write 
> the objectives within the specification and then refer to the 
> Objectives draft for further information?
> 
> We are just trying to write a readable protocol document 
> here.  There should be a reasonable way to do this in a 
> manner that is appropriate in the IETF.
> 
> Best Regards,
> Dorothy
>  
> 
> have minimal
> I agree with David's points, but this is not just a matter or 
> taste and/or a matter to be decided by rough consensus of the WG.
> 
> For CAPWAP to be published as a Standards-Track 
> specification, it cannot have normative dependencies on 
> Informational documents.  Referencing Informational RFCs from 
> Standards-Track RFCs is called a "down reference"
> and it is only allowed in the IETF under certain specific 
> conditions, none of which would seem to apply here.
> 
> Margaret
> 
>

---

From: <[email-masked]>
Date: Thu, 25 May 2006 11:12:08 -0700

Hi Margaret, 

Of course.  What specifically from the Objective document should we cut
and paste into the Specification so that it is clear and easy to
understand for you?

-Dorothy

-----Original Message-----
From: ext Margaret Wasserman [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 10:39 AM
To: Gellert Dorothy (Nokia-ES/MtView); [email-masked];
[email-masked]
Cc: [email-masked]; Kessens David (Nokia-NET/MtView);
[email-masked]; [email-masked]
Subject: RE: [Capwap] Terminology section

Hi Dorothy,

Informative references are okay, the requirement is that you avoid
_Normative_ references to an Informational document from a
Standards-Track document.
  
So, you shouldn't need to restate all of the objectives in the protocol
specification.  If you want to give readers a pointer to the objectives
document and/or indicate how a particular feature relates to the
objectives, you can simply include an Informative reference to the
objectives document.
Informative references are appropriate when the reader may want to look
at another document for background information or wider understanding.

However, you need to avoid Normative references to the objectives
document.
In other words, it should be possible to understand and implement the
CAPWAP specification without reading the objectives document.  It isn't
possible to read and understand a document without knowing how the
terminology is defined, a reference to the objectives document for the
terminology definitions would be a Normative reference.  To avoid a
Normative reference to the objectives document, you would simply include
the same terminology definitions in the protocol specification.  You can
even mention that they originally came from the objective document, if
you like, which would then be an Informative reference.

Does that make sense?

Margaret

> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> We worked on publishing the Objectives draft in conjunction with the 
> ADs and this was approved by the IESG.

> should be a reasonable way to do this in a manner that is appropriate 
> in the IETF.
> 
> Best Regards,
> Dorothy
>  
> 
> For CAPWAP to be published as a Standards-Track specification, it 
> cannot have normative dependencies on Informational documents.  
> Referencing Informational RFCs from Standards-Track RFCs is called a 
> "down reference"