Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

[Sam Hartman]

> "Fred" == Fred Baker <[EMAIL PROTECTED]> writes:

Fred> I have to say that my discussions with US DoD and DHS/NCS,
Fred> and with their counterparts in other countries, doesn't
Fred> suggest that the set of technical mechanisms is all
Fred> specified. If we're looking only at voice, it is maybe so,
Fred> but they're not looking only at voice.  Questions abound
Fred> around the mechanisms for sending an email and ensuring that
Fred> it is delivered in a stated time interval on the order of
Fred> minutes or that an indication of failure is returned to the
Fred> sender, and other things.

Fred, if there are parts of the problem that clearly fall within the
IETF, can you work on a narrowly focused charter that clearly says
what you're going to work on and shows:

1) Why it is within the IETF's scope

2) What you plan to do?

>From the current charter I would have no idea at all that you were
talking about email.

--Sam


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

Re: WG Review: Recharter of Internet Emergency Preparedness (iepr ep)

[Sam Hartman]

> "King," == King, Kimberly S <[EMAIL PROTECTED]> writes:

King,> There are several important requirements that are specific
King,> to military and governmental needs that are emerging or
King,> were outside the current charter's scope.  These
King,> requirements, I believe, include items such as ensured
King,> timely delivery of critical communications in an
King,> environment where security concerns (e.g., encryption) and
King,> QoS requirements must simultaneously be met.  People may be
King,> considering the passing of RSVP messages over different
King,> security domains that may influence security (perhaps by
King,> aiding traffic analysis or introducing a covert channel).
King,> If you think that type of work is ill advised, for example,
King,> then your best chance of voicing that opinion is here at
King,> the IETF.  The requirements aren't going away and people
King,> will be acting on them the best way they know how.  Your
King,> best opportunity to bring the tradeoffs to light is here at
King,> the IETF.

And I believe that the tsvwg is the right place to discuss where RSVP
intersects with security.

--Sam


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

Re: WG Review: Recharter of Internet Emergency Preparedness (iepr ep)

[Lars Eggert]

On Nov 5, 2006, at 13:27, Sam Hartman wrote:

And I believe that the tsvwg is the right place to discuss where RSVP
intersects with security.


I agree with Sam. TSVWG is the WG currently chartered for RSVP  
maintenance, which I would see this falling under. Here is the  
relevant charter text:


   The currently active TSVWG work items mostly fall under the
   following topics:

   (...)

   Maintenance of the Resource Reservation Protocol (RSVP),
   which involves bug fixes to the RSVP specifications and
   their progression along the standards track. This work item
   may also include a small number of extensions to RSVP or
   advisory documents to address specific application
   scenarios. In order to maintain stable specifications,
   additional work on RSVP in TSVWG requires Area Director
   approval.

Lars
--
Lars Eggert NEC Network Laboratories




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

[Pete Resnick]

On 11/4/06 at 4:04 PM -0800, Fred Baker wrote:

Questions abound around the mechanisms for sending an email and 
ensuring that it is delivered in a stated time interval on the order 
of minutes or that an indication of failure is returned to the 
sender...


That, in particular, seems like a relatively easy extension to RFC 
3461 (by adding some sort of additional parameter value to DELAY). 
Not exactly rocket science. Not exactly requiring spinning up a WG.


pr
--
Pete Resnick 
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

The ietf blog should support atom

[Sam Hartman]

the registration packet include a pointer to http://community.ietf.org/blog .

Whatever blog technology we use should support our atom standard; it
seems not to do so.

There is an rss2 link but not an atom link.


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

Re: The ietf blog should support atom

[Robert Sayre]

Sam Hartman wrote:

Whatever blog technology we use should support our atom standard; it
seems not to do so.
  


Mozilla contributor Benjamin Smedberg has created an Atom component for
WordPress. Here's the URL:



- Rob Sayre



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

IETF67 Network is up!

[Jim Martin]

Gentlepeople,
	As of now, we're declaring the network for IETF67 to be up and  
active. Wireless is available as ietf67a (802.11a) and ietf67b  
(802.11b/g) throughout the meeting areas, both east and west tower  
lobbies, both east tower pools, the Coffee shop in East, and the  
lobby and Quinn bars in East. The terminal room is open 24 hours a  
day until Friday noon and is located downstairs from the main meeting  
space in Nautilus 4 & 5.  Information on the network is available at  
http://www.ietf67.org, and any problems can be reported to the  
helpdesk in the terminal room, via email to [EMAIL PROTECTED], or  
via the web ticketing system at http://noc.ietf67.org/trac.


	As always, we encourage problem reports. We can't fix it if we don't  
know about it. Also, tickets submitted via any of the methods listed  
above are more likely to be noticed than those sent to the main IETF  
list.


- Jim


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

Re: WG Review: Recharter of Internet Emergency Preparedness (iepr ep)

[Lars Eggert]

On Nov 5, 2006, at 16:06, King, Kimberly S. wrote:

On Nov 5, 2006, at 13:27, Sam Hartman wrote:

And I believe that the tsvwg is the right place to discuss where RSVP
intersects with security.


The point is that this work belongs here at the IETF, not which  
working

group addresses a particular aspect.


Note that I wrote:


TSVWG is the WG currently chartered for RSVP
maintenance, which I would see this falling under.


I made no statement of where RSVP work should happen in the future,  
but having this work elsewhere would obviously require consensus at  
various levels.


Lars
--
Lars Eggert NEC Network Laboratories




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

My availability for a new term as Operations & Management Area Director

[David Kessens]

Many people have approached me and asked the question whether I am
available for a new term as one of the Operations & Management Area
Directors.

I have no problem answering this question but I personally felt a bit
uncomfortable with answering this question in a private setting as
some people get to know the answer while others are kept in the dark.

To avoid such situations, I would like to let you know that I am
available for another term as Operations & Management Area Director.

I hope this helps,

David Kessens
---


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

How confidential is the information we share with the Nomcom?

[Lakshminath Dondeti]

Confidentiality and the Nomcom has always been an interesting topic 
to me.  Some want everything to be secretive.  I think that the more 
stuff we try to keep secret the harder it is.  Personally, the holy 
grail is potential negative feedback the community may want to 
provide to the nomcom.  In some instances that feedback has been used 
to unseat someone and in other cases just to be packaged as feedback 
to the I* member in question.  If we lose the potential to get/give 
negative feedback without possible repercussions, more people are 
willing to share such opinions.  That's the objective anyway.


It might be worthwhile for the community to know the feedback is known to

* the voting members of the nomcom
* nomcom current and past year's chair
* the 3 liaison members
* the tools team  (some of them are IETF contributors)
* whoever maintains the nomcom list archives
* ???

Frankly the feedback does not need to seen by anyone other than the 
voting members IMO.  What do others think?


thanks,
Lakshminath


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

Re: How confidential is the information we share with the Nomcom?

[Frank Ellermann]

Lakshminath Dondeti wrote:
 
> It might be worthwhile for the community to know the feedback
> is known to
 
> * the voting members of the nomcom
> * nomcom current and past year's chair
> * the 3 liaison members
> * the tools team  (some of them are IETF contributors)
> * whoever maintains the nomcom list archives
> * ???

"The tools team" is a bit broad, of course a Web server with a
HTML form sending mail has an admin.  Like a Web server with a
mail archive.  

> Frankly the feedback does not need to seen by anyone other
> than the voting members IMO.  What do others think?

In theory.  In practice I don't see how you can get rid of the
admins.  For any nominations I hope that you ask ??? if they
consider to volunteer, if the nomination passed a giggle test.

It's probably not necessary that they know who nominated them,
or is it ?  Ditto the liaisons.

Frank



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

Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

[Pete Resnick]

On 11/5/06 at 2:38 PM -0800, Pete Resnick wrote:


On 11/4/06 at 4:04 PM -0800, Fred Baker wrote:

Questions abound around the mechanisms for sending an email and 
ensuring that it is delivered in a stated time interval on the 
order of minutes or that an indication of failure is returned to 
the sender...


That, in particular, seems like a relatively easy extension to RFC 
3461 (by adding some sort of additional parameter value to DELAY). 
Not exactly rocket science. Not exactly requiring spinning up a WG.


And as someone kindly pointed out to me (thanks Philip), we already 
have that extension in RFC 2852 which defines said mechanism (thanks 
Chris).


pr
--
Pete Resnick 
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

Re: WG Review: Recharter of Internet Emergency Preparedness (iepr ep)

[James M. Polk]

At 04:29 PM 11/5/2006 -0800, Lars Eggert wrote:

On Nov 5, 2006, at 16:06, King, Kimberly S. wrote:

On Nov 5, 2006, at 13:27, Sam Hartman wrote:

And I believe that the tsvwg is the right place to discuss where RSVP
intersects with security.


The point is that this work belongs here at the IETF, not which
working
group addresses a particular aspect.


Note that I wrote:


TSVWG is the WG currently chartered for RSVP
maintenance, which I would see this falling under.


I made no statement of where RSVP work should happen in the future,
but having this work elsewhere would obviously require consensus at
various levels.


didn't the IESG, about 18 months ago (it may be longer) write a letter to 
either ITU-T or ETSI  to stop attempting to extend RSVP, that it was 
supposed to be done in the IETF?


I seem to remember that event occuring, though I admit I don't remember the 
details; Allison Mankin would know, as should Jon Peterson.




Lars
--
Lars Eggert NEC Network Laboratories





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


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

Re: How confidential is the information we share with the Nomcom?

[Henrik Levkowetz]

on 2006-11-05 18:59 Lakshminath Dondeti said the following:

[snip first part of message]

> It might be worthwhile for the community to know the feedback is known to

[snip other parties]

> * the tools team  (some of them are IETF contributors)

This is incorrect.  The feedback is encrypted (with the nomcom's public
key) before being committed to disk, and only the nomcom has the private
key necessary to decrypt and read the feedback.  The design of this is
very explicitly done so that nobody who doesn't have the nomcom's private
key can read the feedback.

Where did this erroneous information about the tools team having access
to the feedback come from?


Henrik


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

Re: How confidential is the information we share with the Nomcom?

[Lakshminath Dondeti]

At 08:12 PM 11/5/2006, Frank Ellermann wrote:

Lakshminath Dondeti wrote:

> It might be worthwhile for the community to know the feedback
> is known to

> * the voting members of the nomcom
> * nomcom current and past year's chair
> * the 3 liaison members
> * the tools team  (some of them are IETF contributors)
> * whoever maintains the nomcom list archives
> * ???

"The tools team" is a bit broad, of course a Web server with a
HTML form sending mail has an admin.  Like a Web server with a
mail archive.

> Frankly the feedback does not need to seen by anyone other
> than the voting members IMO.  What do others think?

In theory.  In practice I don't see how you can get rid of the
admins.


The nomcom chair could maintain the email server and the nomcom chair 
can also continue to serve as the anonymizer.  This will include the 
nomcom chair in the list of people who one might be comfortable to 
share that information with.


If voting members are the only ones who should be allowed to see the 
feedback and the nomination information, then we may have to change 
how we select the nomcom chair.


The other option is to use admins who don't care about the 
IETF.  They are not interested in the information and it is not 
really worth a whole lot on the open market so to speak.


regards,
Lakshminath


For any nominations I hope that you ask ??? if they
consider to volunteer, if the nomination passed a giggle test.

It's probably not necessary that they know who nominated them,
or is it ?  Ditto the liaisons.

Frank



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



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

Re: How confidential is the information we share with the Nomcom?

[Lakshminath Dondeti]

I am not (yet) going to get into who specifically has access to what 
kind of information and how, but instead asking a meta question about 
whether or not people care about confidentiality, and to what extent.


I would also like to bring back the attention to the subject of my 
email "the information we share with the Nomcom" whatever kind it is, 
nominations, feedback, advise etc.  What should be confidential and 
what doesn't need to be?


regards,
Lakshminath

At 11:10 PM 11/5/2006, Henrik Levkowetz wrote:



on 2006-11-05 18:59 Lakshminath Dondeti said the following:

[snip first part of message]

> It might be worthwhile for the community to know the feedback is known to

[snip other parties]

> * the tools team  (some of them are IETF contributors)

This is incorrect.  The feedback is encrypted (with the nomcom's public
key) before being committed to disk, and only the nomcom has the private
key necessary to decrypt and read the feedback.  The design of this is
very explicitly done so that nobody who doesn't have the nomcom's private
key can read the feedback.

Where did this erroneous information about the tools team having access
to the feedback come from?


Henrik



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