Subject: Re: [paws] agenda uploaded

From: Pete Resnick <[email-masked]>
Date: Thu, 1 Nov 2012 16:06:14 -0700

On 10/31/12 4:20 PM, [email-masked] wrote:
>
> http://www.ietf.org/proceedings/85/agenda/agenda-85-paws
>

I have a few issues with this, at least as the final agenda. That agenda 
says:

> PAWS working group meeting - Atlanta (IETF85)
> Thursday - November 8th @ 9am
> =========================================
>
> Administrivia (5 min)
> Blue sheets, minutes taker, jabber
>
> Note Well
>
> Agenda bashing

Sure, the above is fine.

> WG doc status (20 min)

No, this should not be done. We have all read the docs. If the status 
needs to be summarized, post a message to the mailing list. There is no 
need to waste time in the session doing this. Please, let's not have 
this on the agenda.

> http://www.ietf.org/id/draft-vchen-paws-protocol-00.txt (Vince, 60min)

This is fine, but I expect the author and the chairs to have a list of 
issues in the document that *can not* be resolved on the list. I do not 
have a problem with compiling that issues list week and not finalizing 
it until the day of (I understand that we all have busy schedules), but 
please try to collect these issues together on the mailing list so if 
people want to talk about any particular issues that are not otherwise 
noted, they will be able to identify them.

> time permitting: http://www.ietf.org/id/draft-wu-paws-secutity-00.txt 
> (Yang, 20 min)

I have not seen serious discussion of this document on the list. What is 
the purpose of this agenda item?

Finally, the only feedback I got to my review of the usecases-rqmnts 
document was from Peter Stanforth, but haven't heard anything further. 
If folks aren't yet prepared to discuss this at the f2f, I will 
understand. (My review did come in quite late.) But if people do want to 
discuss it, you should post to the list so that the chairs know what you 
wish to discuss. (I don't expect this to be added to the agenda if there 
isn't more discussion on the list.)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: <[email-masked]>
Date: Fri, 2 Nov 2012 19:17:20 +0000

Pete,

This group is a bit special in a sense that many of the members are new to ietf and they are coming from different backgrounds, eg ieee, or the industry involved with white spaces, etc.
I would not be surprised finding out that many people on this mailing list believed that the use cases and requirements document was approved and it was a done deal, as soon as they saw I forwarded it to the iesg with publication requested action.
People may not know that there is the concept of the AD in IETF, that ADs usually/always have comments and can send back the documents to the wg, and the wg is supposed to address those comments, etc.
This is not to say that we do not want to go by the rules, but people sometimes need more explanation.
I sent the document to iesg on Aug31st, you came back to the list with your comments 2 months later, without specifying that these are the AD comments and the wg is requested to address them, otherwise the publication process cannot continue. People might have thought these are the comments from an outsider, why to address them. And many people interested in that document moved forward, the editors were let go from their employer, etc, so it is difficult to get people re-involved.
This might be the reasons why you did not get feedback to your comments. And this is why I reserved a bit of time in our F2F for this.

Some background info on how did we end up with those use cases in the document:
There were people coming from different SDOs, like 802.11, 802.22, and some others, with their use cases; which from system functionality point of view differ, but the requirements to the protocol between the master and the db are the same. We had this discussion in the group and people said this document should document the use cases for white space usage, even though they result in the same reqs for the protocol. By not including some of the use case, some people felt that we want to leave that specific technology out. Anyway, I wanted to see if people are ok now to remove/merge some of the use cases to address your comment. That was another reason I put it on the agenda.

Finally, since we got a 2.5h slot and some documents I expected did not come, we'll have time left for  other business, that is why the last doc showed up on the agenda.

Hope this answers your issues.

-          Gabor

From: ext Pete Resnick [mailto:[email-masked]]
Sent: Thursday, November 01, 2012 4:06 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] agenda uploaded

On 10/31/12 4:20 PM, [email-masked]<mailto:[email-masked]> wrote:
http://www.ietf.org/proceedings/85/agenda/agenda-85-paws

I have a few issues with this, at least as the final agenda. That agenda says:

Administrivia (5 min)

Note Well

Agenda bashing

Sure, the above is fine.

WG doc status (20 min)

No, this should not be done. We have all read the docs. If the status needs to be summarized, post a message to the mailing list. There is no need to waste time in the session doing this. Please, let's not have this on the agenda.

This is fine, but I expect the author and the chairs to have a list of issues in the document that *can not* be resolved on the list. I do not have a problem with compiling that issues list week and not finalizing it until the day of (I understand that we all have busy schedules), but please try to collect these issues together on the mailing list so if people want to talk about any particular issues that are not otherwise noted, they will be able to identify them.

time permitting: http://www.ietf.org/id/draft-wu-paws-secutity-00.txt (Yang, 20 min)

I have not seen serious discussion of this document on the list. What is the purpose of this agenda item?

Finally, the only feedback I got to my review of the usecases-rqmnts document was from Peter Stanforth, but haven't heard anything further. If folks aren't yet prepared to discuss this at the f2f, I will understand. (My review did come in quite late.) But if people do want to discuss it, you should post to the list so that the chairs know what you wish to discuss. (I don't expect this to be added to the agenda if there isn't more discussion on the list.)

pr

--

Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>

---

From: Pete Resnick <[email-masked]>
Date: Fri, 2 Nov 2012 14:01:16 -0700

Comments inline:

On 11/2/12 12:17 PM, [email-masked] wrote:

> This group is a bit special in a sense that many of the members are 
> new to ietf and they are coming from different backgrounds, eg ieee, 
> or the industry involved with white spaces, etc.
>
> I would not be surprised finding out that many people on this mailing 
> list believed that the use cases and requirements document was 
> approved and it was a done deal, as soon as they saw I forwarded it to 
> the iesg with publication requested action.
>
> People may not know that there is the concept of the AD in IETF, that 
> ADs usually/always have comments and can send back the documents to 
> the wg, and the wg is supposed to address those comments, etc.
>

Absolutely understood. I certainly did not intend my message to be in 
anyway interpreted as saying that the WG is doing something wrong with 
regard to my comments; indeed, that part was solely a push to say, "If 
the WG wishes to discuss these comments, we should start that discussion 
on the list." More importantly, as you say:

> I sent the document to iesg on Aug31st, you came back to the list with 
> your comments 2 months later...
>

Yes, for this again I must sincerely apologize. Far beyond my average 
for responding to requests to publish, and this again is why I did not 
wish to express anything wrong with the WG not discussing these 
comments: I cannot expect that I will be so late in providing my 
comments and then the WG turn around and start discussing within 2 
weeks. So again, I am not worried about that.

> ...without specifying that these are the AD comments and the wg is 
> requested to address them, otherwise the publication process cannot 
> continue. People might have thought these are the comments from an 
> outsider, why to address them.
>

Ah, yes, I should explain more: I need to be prepared to bring this 
document to the IETF list for Last Call as well as bringing to the IESG 
for IESG Evaluation. In its current form, I am afraid I will get large 
pushback from each of those bodies, so I think the WG should consider 
making some changes. That said, if the WG can give me the ammunition I 
need to defend the document in its current form, that will be OK as 
well. But either way, we do need to work through my comments.

> And many people interested in that document moved forward, the editors 
> were let go from their employer, etc, so it is difficult to get people 
> re-involved.
>

Yes, that is going to be tricky. We'll see what we can figure out.

> This might be the reasons why you did not get feedback to your 
> comments. And this is why I reserved a bit of time in our F2F for this.
>

Completely understood.

> There were people coming from different SDOs, like 802.11, 802.22, and 
> some others, with their use cases; which from system functionality 
> point of view differ, but the requirements to the protocol between the 
> master and the db are the same. We had this discussion in the group 
> and people said this document should document the use cases for white 
> space usage, even though they result in the same reqs for the 
> protocol. By not including some of the use case, some people felt that 
> we want to leave that specific technology out. Anyway, I wanted to see 
> if people are ok now to remove/merge some of the use cases to address 
> your comment. That was another reason I put it on the agenda.
>

Yes, I understand not wanting to leave things out. The idea of "merging" 
some of the use cases together I think would be a nice way forward. We 
should (as a group) discuss that.

> Finally, since we got a 2.5h slot and some documents I expected did 
> not come, we'll have time left for  other business, that is why the 
> last doc showed up on the agenda.
>

It more than answers my issues regarding my AD comments on the 
usecases-rqmts document. Of course, it does not address my other 
comments regarding the agenda.

Thanks for your reply.

pr

> *From:* ext Pete Resnick [mailto:[email-masked]]
> *Sent:* Thursday, November 01, 2012 4:06 PM
> *To:* Bajko Gabor (Nokia-CIC/SiliconValley)
> *Cc:* [email-masked]
> *Subject:* Re: [paws] agenda uploaded
>
> needs to be summarized, post a message to the mailing list. There is 
> no need to waste time in the session doing this. Please, let's not 
> have this on the agenda.
>
>
> issues in the document that *can not* be resolved on the list. I do 
> not have a problem with compiling that issues list week and not 
> finalizing it until the day of (I understand that we all have busy 
> schedules), but please try to collect these issues together on the 
> mailing list so if people want to talk about any particular issues 
> that are not otherwise noted, they will be able to identify them.
>
>
> understand. (My review did come in quite late.) But if people do want 
> to discuss it, you should post to the list so that the chairs know 
> what you wish to discuss. (I don't expect this to be added to the 
> agenda if there isn't more discussion on the list.)
>
> pr
>
> -- 
> Pete Resnick<http://www.qualcomm.com/~presnick/>  <http://www.qualcomm.com/%7Epresnick/>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

---

From: Nancy Bravin <[email-masked]>
Date: Fri, 2 Nov 2012 14:54:07 -0700

Hi Peter, 
  I will take exception to merging technologies:
The blending of all or any similar groups that participated in this effort or were considered from IEEE802. I.e. 22, 11, 16. 15 white space groups. 
What what done by people from all groups was to be concerned about the "consumer" as well as industry for different locations globally where 
WS devices can be used. 
Would it be cheaper to have one type? At what cost…the very people that are in other countries, 
that are not under the FCC/Ofcom type structure of Regulations/Devices types? Isn't what you have advised against by not mentioning regulators etc in the protocol?
22 is referenced, and as the first approved standard, and the only one going forth on use cases others are not…
15 is evoling in other ways, 16 and 11 different solutions still. It is the market and consumer who should decide what to use, makes competition better,
and allows for further innovation from all of them, with different use case solutions offered and involved with new innovations to come? 
I am not eloquent, am not affiliated with a company, and have been agnostic and inclusive technology wise as it relates to 802, but,  I do hope you understand my point, as a further comment to Gabor's.

Sincerely, Nancy

On Nov 2, 2012, at 2:01 PM, Pete Resnick wrote:

> Absolutely understood. I certainly did not intend my message to be in anyway interpreted as saying that the WG is doing something wrong with regard to my comments; indeed, that part was solely a push to say, "If the WG wishes to discuss these comments, we should start that discussion on the list." More importantly, as you say:
> 
>> I sent the document to iesg on Aug31st, you came back to the list with your comments 2 months later...
> 
> Yes, for this again I must sincerely apologize. Far beyond my average for responding to requests to publish, and this again is why I did not wish to express anything wrong with the WG not discussing these comments: I cannot expect that I will be so late in providing my comments and then the WG turn around and start discussing within 2 weeks. So again, I am not worried about that.
> 
>> ...without specifying that these are the AD comments and the wg is requested to address them, otherwise the publication process cannot continue. People might have thought these are the comments from an outsider, why to address them.
> 
> Ah, yes, I should explain more: I need to be prepared to bring this document to the IETF list for Last Call as well as bringing to the IESG for IESG Evaluation. In its current form, I am afraid I will get large pushback from each of those bodies, so I think the WG should consider making some changes. That said, if the WG can give me the ammunition I need to defend the document in its current form, that will be OK as well. But either way, we do need to work through my comments.
> 
>> And many people interested in that document moved forward, the editors were let go from their employer, etc, so it is difficult to get people re-involved.
> 
> Yes, I understand not wanting to leave things out. The idea of "merging" some of the use cases together I think would be a nice way forward. We should (as a group) discuss that.
> 
>> Finally, since we got a 2.5h slot and some documents I expected did not come, we’ll have time left for  other business, that is why the last doc showed up on the agenda.
>>  
> It more than answers my issues regarding my AD comments on the usecases-rqmts document. Of course, it does not address my other comments regarding the agenda.
> 
> Thanks for your reply.
> 
> pr
> 
> 
>> Pete Resnick <http://www.qualcomm.com/~presnick/>
> Pete Resnick <http://www.qualcomm.com/~presnick/>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 6 Nov 2012 09:32:11 -0500

Hi Nancy,

I think you misunderstood the intention of my comment regarding 
"merging". See inline:

On 11/2/12 5:54 PM, Nancy Bravin wrote:

> The blending of all or any similar groups that participated in this 
> effort or were considered from IEEE802. I.e. 22, 11, 16. 15 white 
> space groups.
> What what done by people from all groups was to be concerned about the 
> "consumer" as well as industry for different locations globally where
> WS devices can be used.
> that are not under the FCC/Ofcom type structure of Regulations/Devices 
> types? Isn't what you have advised against by not mentioning 
> regulators etc in the protocol?

I am *not* suggesting merging the technologies themselves. Of course 
that's not something that the IETF can do anything about at all. All I 
was suggesting was that in the list of use cases in the document, we 
might be able to combine a few of the technologies into one section of 
the document where those technologies have a lot in common. The problem 
is not the number of technologies; it's fine to mention them all. It's 
just that there is a lot of duplicated information in the descriptions, 
and I think it would make the document clearer to group a few of them 
together. For example, the hotspot example in 4.2.1 and the 
wide-area/rural example in 4.2.2 have almost identical architectures, so 
I think we might be able to mention both use cases in one section.

I'm sorry if I confused the issue by using the word "merging". I was not 
referring to the technologies. I only meant that we could mention 
multiple technologies in a single section of the use cases document when 
it makes sense to group them together.

Does that make sense?

pr

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 6 Nov 2012 10:38:06 -0500

It is those regulators again!  Using FCC rules:
Those two use cases may have similar architectures but as a DB provider I have to treat them very differently. Specifically rural is fixed to fixed and hotspot is mode 2 to mode 1
The messaging is different. The fixed device is required to register the mode 2 does not. The mode 2 has to validate the FCCid of its associated mode 1 devices. A fixed device does not validate the fixed slaves associated with it. 
A fixed slave, fixed master and mode 2 talk to the DB the mode 1 never does.

---

From: Nancy Bravin <[email-masked]>
Date: Tue, 6 Nov 2012 08:07:25 -0800

Peter, Pete, 

I do not think it is advisable to change any of the use cases under one umbrella because they are similar, and if it were me I would have it rural/remote but that is me….
For regulators who will have different rules, i.e., Peter's comments, I agree.
On many other issues you mentioned I do agree, but not this. Sorry. N