Re: IAOC: delegating ex-officio responsibility

[John C Klensin]

--On Saturday, April 16, 2011 07:51 -0700 Lucy Lynch
 wrote:

>> The implication is that the people sitting in the positions
>> of IAB Chair and  IETF Chair are essential to the good
>> operation of the IAOC/Trust.  Someone  else from their groups
>> or even someone else that they appoint from outside  cannot
>> perform the task of IAOC/Trust member adequately.
> 
> I think this is the wrong question. I don't think this is
> about the
> people who sit on the IAOC or the Trust, it is about the
> roles. Their
> participation is part of the chain of accountability to the
> community.
> The IAOC was crafted to include both the IAB and IETF Chairs
> as well
> as the ISOC CEO in their respective roles and not as Fred,
> Harold, and
> Lynn (as members of the IETF community).
> 
>> Why?
>> 
>> What are the specific contributions (insights and skills)
>> that these roles  regularly perform, in the conduct of the
>> IAOC/Trust that cannot be performed  adequately by others?
> 
> see above.
> 
> One more point here: as a former Chair of the IAOC (IAB
> appointed
> member from the community) I'm sympathetic the the overload
> arguments
> but I'll note that absent the IAB/IETF chairs the work of the
> IAOC
> chair and the weight put on that role may increase in
> unexpected ways.
> 
> I agree with many of the points that Bob, Brian, Leslie, and
> Jari
> have made in earlier posts and think that we need to take a
> broader
> view of the problems we're trying to solve here. Role overload
> is
> an on-going problem but I'm not sure we solve this by moving
> the
> administrative accountability we gained through BCP 101 to
> additional volunteers.

At the risk of agreeing violently with Dave, I think the series
of comments above, and referenced above, are missing something.
None of this familiy of "delegation" or "someone else" proposals
requires that the IAB or IESG Chairs not serve on the IAOC.  If
they think that is sensible and they have the time, they are
free to do that.  We might even strongly encourage it.  However,
if those people conclude that limited available time is better
spent in other ways or that, if they take the IAOC position,
they would not be able to devote adequate attention to it,
aren't we better off giving them the flexibility and discretion
to make that decision?  Similarly, if someone tells the
appointing body "I have the time and resources to take on the
IAB Chair or IETF Chair position but only if that position does
not include the responsibility of sitting on the IAOC" isn't it
better to give those bodies the option of considering that
person rather than limiting the choices to those who can sign up
for all of the job?

At least from my perspective, broadening the flexibility
available to already-appointed IAB and IETF Chairs and to the
bodies that appoint them is the real issue here.  _Requiring_
that they serve on the IAOC does not create more time or
resources, it just limits the range of people who can take those
positions or, more likely, raises the odds of getting someone
onto the IAOC who won't be able to pay full (or even adequate)
attention.

So. in addition to the questions Dave posed, the question I
would address to you and Bob is whether, given a hypothetical
choice of someone sitting on the IAOC ex-officio but not being
able to really pay attention because he or she concludes that
there are more pressing priorities and having someone
representing the IAB or IESG who really can pay attention, which
one you would pick.  In the worst case, if you prefer to have
the Chairs nominally present but not paying complete attention,
then keep insisting that they are the only ones who can possibly
occupy the IAOC slot.  

As part of that, figure out how you are going to convince the
Nomcom and the IAB that selecting people for the Chair roles
should have "will give IAOC first priority regardless of their
judgment about the importance of other aspects of their roles"
as an absolute criterion and/or how you are going to convince
the community to recall anyone in the Chair roles who does not
give the IAOC that priority.

best,
  john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Speechsc] Last Call: (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard

[Slawomir Testowy]

Hello,

my small comment:

The BARGE-IN-OCCURRED method is in few places wrote as BARGE-IN-OCCURED
(note missing "R"). I wonder how this could go through all 24 MRCPv2
revisions

Regards,
Slawek Testowy

2011/3/16 The IESG :
>
> The IESG has received a request from the Speech Services Control WG
> (speechsc) to consider the following document:
> - 'Media Resource Control Protocol Version 2 (MRCPv2)'
>   as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-04-13. (This allows an additional two
> weeks for review since the document is large and the review period overlaps
> the Prague IETF meeting). Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> ___
> Speechsc mailing list
> speec...@ietf.org
> https://www.ietf.org/mailman/listinfo/speechsc
> Supplemental web site:
> ;
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Speechsc] Last Call: (Media Resource Control Protocol Version 2 (MRCPv2)) to Proposed Standard

[Slawomir Testowy]

Hi!

Some other comments:

> 4.2. Managing Resource Control Channels

> When the client wants to add a media processing resource to the
> session, it issues a SIP re-INVITE transaction.

Is it possible to allocate more than one resource of the same type
during one SIP dialog? Example in 4.2 shows how to allocate
synthesizer and recognizer, but does not specify if there may be e.g.
more than one synthesizer.



>6.2.9. Content-Encoding
>
>
>   The content-encoding entity-header is used as a modifier to the
>   media-type.  When present, its value indicates what additional
>   content encoding has been applied to the entity-body, and thus what
>   decoding mechanisms must be applied in order to obtain the media-type
>   referenced by the content-type header field.  Content-encoding is
>   primarily used to allow a document to be compressed without losing
>   the identity of its underlying media type.  Note that the SDP session
>   can be used to determine accepted encodings (see Section 7).  This
>   header field MAY occur on all messages.

Section 7 describes usage of OPTIONS method of SIP and Accept-Encoding
header is returned by SIP response, not SDP answer, so I guess "Note that
the SDP session can be used" should be changed to "Note that the SIP
session can be used".

>   When a CONTROL request to jump backward is issued to a currently
>  speaking synthesizer resource, and the target jump point is before
>   the start of the current "SPEAK" request, the current "SPEAK" request
>   MUST restart from the beginning of its speech data and the response
>   to the CONTROL request MUST contain this header field with a value of
>   "true" indicating a restart.

Why sometimes requests are surrounded by quotation marks (like "SPEAK")
and sometimes not (like CONTROL request)? This happens through all the
specification. This may be a minor nit, but makes the whole paper look like a
"draft" :)

> 8.4.7. Prosody-Parameters

>  The prosody parameter headers in the "SET-PARAMS" or "SPEAK" request
>  only apply if the speech data is of type text/plain and does not use
>  a speech markup format.

Why is it so? Why it is not true for Voice-Parameters?
Is it true for CONTROL (i.e. current SPEAK must be text/plain)?

Specification does not say anything about it.

> 8.4.16. Load-Lexicon
>
>
>   This header field is used to indicate whether a lexicon has to be
>   loaded or unloaded.  The default value for this header field is
>   "true".  This header field MAY be specified in a DEFINE-LEXICON
>   method.

I propose rewording this paragraph to explicilty state that "true" means
"load lexicon" and "false" means "unload lexicon".



Thanks.
Slawek Testowy




2011/3/16 The IESG :
>
> The IESG has received a request from the Speech Services Control WG
> (speechsc) to consider the following document:
> - 'Media Resource Control Protocol Version 2 (MRCPv2)'
>   as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-04-13. (This allows an additional two
> weeks for review since the document is large and the review period overlaps
> the Prague IETF meeting). Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-speechsc-mrcpv2/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> ___
> Speechsc mailing list
> speec...@ietf.org
> https://www.ietf.org/mailman/listinfo/speechsc
> Supplemental web site:
> ;
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels-05

[Mykyta Yevstifeyev]

19.04.2011 1:21, Russ Housley wrote:

Mykyta:


4. Downward References Permitted

This section says nothing about references to documents with no status 
("pre-IETF" RFCs).  Maybe informative references to such RFCs should be 
allowed.  And what about normative ones?  Whether the RFC 3967 procedure will be used in 
such cases, or such references are disallowed in Standards Track docs?  I think this 
should also be mentioned in your draft.

What does this have to do with moving from two maturity levels?
Mostly nothing, but if you consider that the whole Section 4 is 
appropriate for your document, what I propose is appropriate also.


Mykyta

Russ


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels-05

[Russ Housley]

Mykyta:

 4. Downward References Permitted
>>> This section says nothing about references to documents with no status 
>>> ("pre-IETF" RFCs).  Maybe informative references to such RFCs should be 
>>> allowed.  And what about normative ones?  Whether the RFC 3967 procedure 
>>> will be used in such cases, or such references are disallowed in Standards 
>>> Track docs?  I think this should also be mentioned in your draft.
>> What does this have to do with moving from two maturity levels?
> Mostly nothing, but if you consider that the whole Section 4 is appropriate 
> for your document, what I propose is appropriate also.

I just reviewed RFC 3967.  It does not seem to claim that references to those 
older documents requires special handling.  I'd like to leave this topic to an 
update to RFC 3967 if such an update is needed at all.

Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels-05

[Peter Saint-Andre]

On 4/19/11 9:57 AM, Russ Housley wrote:
> Mykyta:
> 
> 4. Downward References Permitted
 This section says nothing about references to documents with no status 
 ("pre-IETF" RFCs).  Maybe informative references to such RFCs should be 
 allowed.  And what about normative ones?  Whether the RFC 3967 procedure 
 will be used in such cases, or such references are disallowed in Standards 
 Track docs?  I think this should also be mentioned in your draft.
>>> What does this have to do with moving from two maturity levels?
>> Mostly nothing, but if you consider that the whole Section 4 is appropriate 
>> for your document, what I propose is appropriate also.
> 
> I just reviewed RFC 3967.  It does not seem to claim that references to those 
> older documents requires special handling.  I'd like to leave this topic to 
> an update to RFC 3967 if such an update is needed at all.

+1. Let's keep this I-D short and focused.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

IETF 84 Venue

[IETF Administrative Director]

The IAOC is pleased to announce Vancouver,BC, Canada as the site for IETF
84 from July 29 to August 3, 2012.  This will be the IETF's fourth meeting
in Vancouver, the others being 18, 64 and 70.  

Google will be the the Host for this meeting.  Google most recently was
the host for IETF 73 in Minneapolis.Thanks again
Google!

We want to thank our benefactors.  The IETF cannot support its technical
standards efforts, including the Secretariat and RFC Editor, without the
generous support of its hosts and sponsors.

Contact Drew Dvorshak at dvors...@isoc.org if you are interested in being
a Sponsor for IETF 84, or a Host for a different meeting. 

Hope to see you in Quebec City at IETF 81in 95 days!

Ray Pelletier
IETF Administrative Director
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IAOC: delegating ex-officio responsibility

[Dave CROCKER]

Bob, et al,

On 4/18/2011 2:25 PM, Bob Hinden wrote:

I didn't say no one else could do the job adequately.  I said "would have a
negative impact" on the operations of the IETF.


Right. And my second sentence did go farther than I meant.

However rejecting an effort to change the current arrangement -- especially when 
it is initiated by a principal -- means that alternatives are not acceptable, 
which translates roughly to saying the alternatives will not produce adequate 
performance.  Otherwise it looks like a difference between 'adequate' and 
perhaps "perfect"?


There is a core reality, here, that the I* Chairs are overburdened. This is 
obvious from looking at the list of their duties and underscored by the source 
of the current initiative.  We can choose to defer doing anything, under the 
guise of taking a 'holistic' view or we can try to help with the specific burden 
that is the focus of the overburdened folk.  On the average, we do better with 
incremental change and this is the one before us now.




If I generalize this, I would say that the I* chairs have been actively
involved in the most significant decisions the IAOC makes, they tend to be
less active in many of the day to day operational issues.

...

I think the I* chairs, in my view bring a broad view of the community and
operational needs based on what's involved in doing their jobs than another
person would not have.


My own simplistic summary:  For some topics it is extremely helpful to have the 
broader knowledge and insight that can be provided by an I* chair. For many 
topics, this is not needed, but for some it makes a significant difference.


To that end, here's a very simple proposal that resolves the issue cleanly:

 1. ISOC, IAB and IESG each appoint one person currently.  Change this to 
be two each, the same as Nomcom.  Each year, they would appoint one person.


 2. Move the I* Chairs to be non-voting ex-officio participants, the same 
as the IETF Administrative Director.  They are welcome to participate or be 
explicitly invited to all IAOC/Trust activities.


This produces the continuity that is needed for the admin work, but also retains 
access to the expertise of the I* chairs.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Joel M. Halpern]

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks 
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where 
the relevant GEOLOC work has been done up till now.


Yours,
Joel M. Halpern

On 4/19/2011 12:56 PM, IESG Secretary wrote:

A new IETF working group has been proposed.  The IESG has not made any
determination as yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011.


Protocol to Access White Space database (paws)

Current Status: Proposed Working Group
Last updated: 2011-04-14

Chairs:
TBD

Area Directors:
TBD

Area Advisor:
TBD

Mailing lists:
Address: p...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/paws
Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Governments around the world continue to search for new pieces of radio
spectrum which can be used by the expanding wireless communications
industry to provide more services in the usable spectrum. The concept
of allowing secondary transmissions (licensed or unlicensed) in
frequencies allocated to a primary user is a technique to "unlock"
existing spectrum for new use. An obvious requirement is that these
secondary transmissions do not interfere with the primary use of the
spectrum. Often, in a given physical location, the primary user(s) may
not be using the entire band allocated to them. The available spectrum
for a secondary use would then depend on the location of the secondary
user. The primary user may have a schedule when it uses the spectrum,
which may be available for secondary use outside that schedule. The
fundamental issue is how to determine for a specific location and
specific time, if any of the primary spectrum is available for secondary
use. One simple mechanism is to use a geospatial database that records
protected contours for primary users, and require the secondary users to
check the database prior to selecting what part of the spectrum they
use. Such databases could be available on the Internet for query by
users.

In a typical implementation of geolocation and database to access TV
white space, a radio is configured with, or has the capability to
determine its location in latitude and longitude. At power-on, before
the device can transmit or use any of the spectrum set aside for
secondary use, the device must identify the relevant database to query,
contact the database, provide its geolocation and receive in return a
list of unoccupied or "white space" spectrum (for example, in a TV
White space implementation, the list of available channels at that
location). The device can then select one of the channels from the list
and begin to transmit and receive on the selected channel. The device
must query the database subsequently on a periodic basis for a list of
unoccupied channels based on certain conditions, e.g. a fixed amount of
time has passed or the device has changed location beyond a specified
threshold.

The databases are expected to be reachable via the Internet and the
devices querying these databases are expected to have some form of
Internet connectivity, directly or indirectly. The databases may be
country specific since the available spectrum and regulations may vary,
but the fundamental operation of the protocol should be country
independent, thus extensibility of data structures will be required. The
solution will not be tied to any specific spectrum, country, or
phy/mac/air interface but may incorporate relevant aspects of these as
needed for proper operation.

The proposed working group will :
- standardize a protocol for querying the database, which includes a
location sensitive database discovery mechanism and security for the
protocol, and application services.
- Standardize the data structure to be carried by the query
protocol.

The protocol must protect both the channel enablement process and the
privacy of users. Robust security mechanisms are required to prevent:
device identity spoofing, modification of device requests, modification
of channel enablement information, impersonation of registered database
services and unauthorized disclosure of a users location.

Existing IETF location data structures and privacy mechanisms may be
considered for use. The WG will also investigate the need for other
mechanisms and related protocols to the White Space DB.

The Working Group will set up and maintain appropriate contact and
liaison with other relevant standards bodies and groups, including IEEE
802.11af and IEEE 802.22 to begin with. The working group may also
consider input from regulatory entities that are involved in the
specification of the rules for secondary use of spectrum in specific
bands.

Goals and Milestones

Sep 2011  Submit 'Requirements and Fra

Re: IAOC: delegating ex-officio responsibility

[SM]

Hi Bob,
At 14:25 18-04-2011, Bob Hinden wrote:
I didn't say no one else could do the job adequately.  I said "would 
have a negative impact" on the operations of the IETF.


Some examples where an I* chair had a significant influence on a 
decision that IAOC made include:


 - The hiring of the Transitional RSE
 - Many of the Beijing meeting issues (prior and post signing the MOU)
 - Specific venue selections (in one case avoiding a less than ideal venue)
 - The need for transparency in certain IAOC actions (day passes, 
venue rotation)
 - Discussion of what policy decisions that the IAOC can make vs. 
the IESG vs. community

 - Discussion about when to get community feedback
 - Secretariat contract (RFP, bidders review, selection, etc.)
 - RFC Publisher and Publisher contracts  (RFP, bidders review, 
selection, etc.)


Some of these decision might have been different without one or more 
I* chairs being directly involved in the decision.  Please review 
the minutes for more detail.


From RFC 4071:

  "The IAOC shall be accountable to the IETF community for the
   effectiveness, efficiency, and transparency of the IASA."

In a personal note that Olaf posted ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg66161.html ), it 
is mentioned that it takes 0.7 FTE.  I do not believe that the 
decisions mentioned above are unimportant.  However, you have to 
consider which decisions require your attention when you have a 
limited amount of time available.


The current members of the IAOC, excluding ex officio, are:

 Eric Burger
 Dave Crocker
 Marshall Eubanks
 Bob Hinden
 Ray Pelletier (non-voting)

None of them are new to the IETF.  If it requires I* Chairs for the 
IAOC to be transparent, something is not right.


I think the I* chairs, in my view bring a broad view of the 
community and operational needs based on what's involved in doing 
their jobs than another person would not have.


If I understand your arguments, it is also about avoiding a 
disconnect between the administrative side of the IETF and the IAB/IESG.


draft-kolkman-iasa-ex-officio-membership-00 argues for a change to 
reduce the workload and make the I* Chair positions more 
attractive.  Would it help if the IAOC Chair has a liaison position 
on the IAB and IESG?  The IAB and IESG Chairs can use their 
discretion to determine which IAOC meetings they should attend.  The 
IAOC Chair gets a broader view.


The above pushes the workload around instead of addressing the 
problem.  If this trend continues, the best fit people will turn down 
I* positions.


Regards,
-sm  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

North American Cable Industry to Host IETF 85

[IETF Administrative Director]

The IAOC is pleased to be able to announce sponsors for IETF 85 in Atlanta
in November 4 - 9, 2012. That meeting will be hosted by the North American
cable industry. The sponsoring companies are Comcast, Time Warner Cable,
CableLabs, the National Cable & Telecommunications Association,
Brighthouse, Cablevision, Charter, and Cox.

Comcast hosted IETF 71 in Philadelphia and has sponsored meeting breaks
and ice cream socials at other meetings, such as recently in Prague.

Thanks to the cable industry!  

Interested in hosting an IETF meeting?  Contact Drew Dvorshak at
dvors...@isoc.org.

Ray Pelletier
IETF Administrative Director
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

Dave,

On Apr 19, 2011, at 10:33 AM, Dave CROCKER wrote:

> Bob, et al,
> 
> On 4/18/2011 2:25 PM, Bob Hinden wrote:
>> I didn't say no one else could do the job adequately.  I said "would have a
>> negative impact" on the operations of the IETF.
> 
> Right. And my second sentence did go farther than I meant.
> 
> However rejecting an effort to change the current arrangement -- especially 
> when it is initiated by a principal -- means that alternatives are not 
> acceptable, which translates roughly to saying the alternatives will not 
> produce adequate performance.  Otherwise it looks like a difference between 
> 'adequate' and perhaps "perfect"?

We don't get perfect :-)

> 
> There is a core reality, here, that the I* Chairs are overburdened. This is 
> obvious from looking at the list of their duties and underscored by the 
> source of the current initiative.  We can choose to defer doing anything, 
> under the guise of taking a 'holistic' view or we can try to help with the 
> specific burden that is the focus of the overburdened folk.  On the average, 
> we do better with incremental change and this is the one before us now.


Then let's talk about the overall problem and not a point solution.

> If I generalize this, I would say that the I* chairs have been actively
>> involved in the most significant decisions the IAOC makes, they tend to be
>> less active in many of the day to day operational issues.
> ...
>> I think the I* chairs, in my view bring a broad view of the community and
>> operational needs based on what's involved in doing their jobs than another
>> person would not have.
> 
> My own simplistic summary:  For some topics it is extremely helpful to have 
> the broader knowledge and insight that can be provided by an I* chair. For 
> many topics, this is not needed, but for some it makes a significant 
> difference.


I agree, and it is representative of the level of current participation of I* 
chairs.


> 
> To that end, here's a very simple proposal that resolves the issue cleanly:
> 
> 1. ISOC, IAB and IESG each appoint one person currently.  Change this to 
> be two each, the same as Nomcom.  Each year, they would appoint one person.
> 
> 2. Move the I* Chairs to be non-voting ex-officio participants, the same 
> as the IETF Administrative Director.  They are welcome to participate or be 
> explicitly invited to all IAOC/Trust activities.
> 
> This produces the continuity that is needed for the admin work, but also 
> retains access to the expertise of the I* chairs.


I don't agree.  Appointing two people (or more?) doesn't solve the problem I am 
concerned about, it still doesn't bring the chairs perspective.  It also 
significantly changes the governance model by changing the balance between 
between nomcom, iab, iesg, and ISOC appointed members.  Also, adding six people 
(still counting the chairs) will make the IAOC much larger and unwieldy.  

Bob



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Peter Saint-Andre]

On 4/19/11 1:47 PM, Paul Lambert wrote:
> 
> 
> How does the area that the group is assigned impact the choices of
> technology?
> 
> I'm an advocate for an efficient solution set for PAWS ... it will be
> much like DNS for spectrum in the future and should be viewed as a
> core infrastructural component that needs careful design.  There are
> good reasons that routing protocols don't use XML.
> 
> Applications now days tend to go for the simple, quick to make a web
> application solutions using XML or the like ...  My concern is that
> "Applications" imply that efficiency does not matter.

A quick look at the specifications for the CORE WG in the Applications
Area will show you that we're able to produce protocols that are quite
slim on the wire.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IAOC: delegating ex-officio responsibility

[Bob Hinden]

SM,

> Eric Burger
> Dave Crocker
> Marshall Eubanks
> Bob Hinden
> Ray Pelletier (non-voting)
> 
> None of them are new to the IETF.  If it requires I* Chairs for the IAOC to 
> be transparent, something is not right.

But that may not always be the case that all IAOC members have a lot of IETF 
experience.  We need to have a governance model that works into the future.  

> 
>> I think the I* chairs, in my view bring a broad view of the community and 
>> operational needs based on what's involved in doing their jobs than another 
>> person would not have.
> 
> If I understand your arguments, it is also about avoiding a disconnect 
> between the administrative side of the IETF and the IAB/IESG.

Yes

> 
> draft-kolkman-iasa-ex-officio-membership-00 argues for a change to reduce the 
> workload and make the I* Chair positions more attractive.  Would it help if 
> the IAOC Chair has a liaison position on the IAB and IESG?  The IAB and IESG 
> Chairs can use their discretion to determine which IAOC meetings they should 
> attend.  The IAOC Chair gets a broader view.
> 
> The above pushes the workload around instead of addressing the problem.  If 
> this trend continues, the best fit people will turn down I* positions.

It would certainly give the IAOC chair a broader view, but still not the views 
of the I* chair.  Also, if the I* chairs (3 of 9 voting members) regularly 
didn't attend, it would be much harder to get a quorum for a meeting and pass 
motions.  

Bob

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Protocol to Access White Space database (paws)

[Stephen Farrell]

I think this is a good and timely thing for the IETF to do.

One part of this where I think it might be useful to get
some broader input (which may have happened already, I'm not
sure) is the following:

On 19/04/11 17:56, IESG Secretary wrote:
> The protocol must protect both the channel enablement process and the
> privacy of users. 

That part is fine but it goes on to say:

> Robust security mechanisms are required to prevent:
> device identity spoofing, modification of device requests, modification
> of channel enablement information, ...

I'm told (and believe) this in response to (at least) US
FCC requirements that call for a device ID and sometimes
serial number to be (securely, for some value of securely)
sent with the query.

Those appear to be real regulatory requirements in the
US, presumably so the regulator can stomp on someone who
messes about in the wrong spectrum at the wrong time.
(The link below [1] may be to the right or wrong bit of
those US regulations, I'm not at all sure, not being
from there;-)

So my questions:

Are there may be similar (or conflicting!) requirements
elsewhere?

Does this bit of the charter text need changes to work
well for other regions?

Separately, I'm not sure how to square those kinds of
regulatory requirements with protecting privacy where the
device is carried by a person and has some FCC device ID
(which lots do I guess) and the person might not want
the database operator to know who's asking. But I think
that's ok as something for the WG to figure out since
the charter already calls for respecting privacy.

I'm more concerned in case e.g. some other regional regulation
called for this protocol to be completely anonymous or
something, in which case the current charter text might
be problematic.

Cheers,
Stephen.

[1]
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=3e9c322addf1f7e897d8c84a6c7aca78&rgn=div8&view=text&node=47:1.0.1.1.14.8.243.9&idno=47
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Joel M. Halpern]

Clearly, the discussion about whether the application protocol should be 
XML, plain ASCII/UTF8, binary, or some other encoding needs to take 
place.  But that can take place wherever we place the working group.


There is an argument, which you allude to, which would place this WG in 
the Internet Area as part of "infrastructure."  While that does not 
resonate with me, I do see that there is some merit in that perspective.


I tend to think we need to focus on transactional application experience 
(the apps area) or where we have experience with protocols that need to 
communicate geolocation (RAI).


I would hope, and expect, that the ADs for any area would be receptive 
to a proper evaluation of any candidate protocol and encoding.  (The 
arguments get complex, and it takes care to avoid religious assertions.)


Yours,
Joel

On 4/19/2011 3:47 PM, Paul Lambert wrote:



How does the area that the group is assigned impact the choices of technology?

I'm an advocate for an efficient solution set for PAWS ... it will be much like 
DNS for spectrum in the future and should be viewed as a core infrastructural 
component that needs careful design.  There are good reasons that routing 
protocols don't use XML.

Applications now days tend to go for the simple, quick to make a web application 
solutions using XML or the like ...  My concern is that "Applications" imply 
that efficiency does not matter.

Paul




-Original Message-
From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of
Joel M. Halpern
Sent: Tuesday, April 19, 2011 10:50 AM
To: i...@ietf.org
Cc: p...@ietf.org; IETF discussion list
Subject: Re: [paws] WG Review: Protocol to Access White Space database
(paws)

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where
the relevant GEOLOC work has been done up till now.

Yours,
Joel M. Halpern

On 4/19/2011 12:56 PM, IESG Secretary wrote:

A new IETF working group has been proposed.  The IESG has not made

any

determination as yet. The following draft charter was submitted, and

is

provided for informational purposes only. Please send your comments

to the

IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011.


Protocol to Access White Space database (paws)

Current Status: Proposed Working Group
Last updated: 2011-04-14

Chairs:
TBD

Area Directors:
TBD

Area Advisor:
TBD

Mailing lists:
Address: p...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/paws
Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Governments around the world continue to search for new pieces of

radio

spectrum which can be used by the expanding wireless communications
industry to provide more services in the usable spectrum. The concept
of allowing secondary transmissions (licensed or unlicensed) in
frequencies allocated to a primary user is a technique to "unlock"
existing spectrum for new use. An obvious requirement is that these
secondary transmissions do not interfere with the primary use of the
spectrum. Often, in a given physical location, the primary user(s)

may

not be using the entire band allocated to them. The available

spectrum

for a secondary use would then depend on the location of the

secondary

user. The primary user may have a schedule when it uses the spectrum,
which may be available for secondary use outside that schedule. The
fundamental issue is how to determine for a specific location and
specific time, if any of the primary spectrum is available for

secondary

use. One simple mechanism is to use a geospatial database that

records

protected contours for primary users, and require the secondary users

to

check the database prior to selecting what part of the spectrum they
use. Such databases could be available on the Internet for query by
users.

In a typical implementation of geolocation and database to access TV
white space, a radio is configured with, or has the capability to
determine its location in latitude and longitude. At power-on, before
the device can transmit or use any of the spectrum set aside for
secondary use, the device must identify the relevant database to

query,

contact the database, provide its geolocation and receive in return a
list of unoccupied or "white space" spectrum (for example, in a TV
White space implementation, the list of available channels at that
location). The device can then select one of the channels from the

list

and begin to transmit and receive on the selected channel. The device
must query the database subsequently on a periodic basis for a list

of

unoccupied channels based on certain conditions, e.g. a fixed amount

of

time has passed or the device has changed location beyond a specified
threshold.

The databases are expected to be reachable via the Inter

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Joel M. Halpern]

Actually, as far as I can tell, there is very little parallel between 
the PAWS problem and SNMP.
SNMP tends to be initiated by the manager, and used to extract 
information from the device in the network, or set information in teh 
device.
This protocol is used by the client.  It extracts basically stable 
information about what frequencies can be used in this geographic region 
at this time.
There is no "network management" going on.  the interaction does not 
look like SNMP.  And the effect does not look like SNMP.  While Radius 
or Diameter are closer, this protocol is not even a policy decision 
protocol.  There is no "policy".


So no, I do not think this looks anything like network management.
The protocols, the transaction drivers and behavior, the problem space, 
and the underlying data behavior are all very different from any of our 
NM work.


Yours,
Joel

On 4/19/2011 5:21 PM, Rex Buddenberg wrote:

On Tue, 2011-04-19 at 12:47 -0700, Paul Lambert wrote:


How does the area that the group is assigned impact the choices of
technology?

I'm an advocate for an efficient solution set for PAWS ... it will be
much like DNS for spectrum in the future and should be viewed as a
core infrastructural component that needs careful design.  There are
good reasons that routing protocols don't use XML.


While the DNS analogy works, I was thinking more a parallel -- or
extension -- of SNMP.

Still remain within 'applications', Joel?



Applications now days tend to go for the simple, quick to make a web
application solutions using XML or the like ...  My concern is that
"Applications" imply that efficiency does not matter.

Paul




-Original Message-
From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of
Joel M. Halpern
Sent: Tuesday, April 19, 2011 10:50 AM
To: i...@ietf.org
Cc: p...@ietf.org; IETF discussion list
Subject: Re: [paws] WG Review: Protocol to Access White Space database
(paws)

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where
the relevant GEOLOC work has been done up till now.

Yours,
Joel M. Halpern

On 4/19/2011 12:56 PM, IESG Secretary wrote:

A new IETF working group has been proposed.  The IESG has not made

any

determination as yet. The following draft charter was submitted, and

is

provided for informational purposes only. Please send your comments

to the

IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011.


Protocol to Access White Space database (paws)

Current Status: Proposed Working Group
Last updated: 2011-04-14

Chairs:
TBD

Area Directors:
TBD

Area Advisor:
TBD

Mailing lists:
Address: p...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/paws
Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Governments around the world continue to search for new pieces of

radio

spectrum which can be used by the expanding wireless communications
industry to provide more services in the usable spectrum. The concept
of allowing secondary transmissions (licensed or unlicensed) in
frequencies allocated to a primary user is a technique to "unlock"
existing spectrum for new use. An obvious requirement is that these
secondary transmissions do not interfere with the primary use of the
spectrum. Often, in a given physical location, the primary user(s)

may

not be using the entire band allocated to them. The available

spectrum

for a secondary use would then depend on the location of the

secondary

user. The primary user may have a schedule when it uses the spectrum,
which may be available for secondary use outside that schedule. The
fundamental issue is how to determine for a specific location and
specific time, if any of the primary spectrum is available for

secondary

use. One simple mechanism is to use a geospatial database that

records

protected contours for primary users, and require the secondary users

to

check the database prior to selecting what part of the spectrum they
use. Such databases could be available on the Internet for query by
users.

In a typical implementation of geolocation and database to access TV
white space, a radio is configured with, or has the capability to
determine its location in latitude and longitude. At power-on, before
the device can transmit or use any of the spectrum set aside for
secondary use, the device must identify the relevant database to

query,

contact the database, provide its geolocation and receive in return a
list of unoccupied or "white space" spectrum (for example, in a TV
White space implementation, the list of available channels at that
location). The device can then select one of the channels from the

list

and begin to transmit and receive on the selected channel. The device
must query the database subsequently on a periodic basis fo