RE: Running Code

[Hannes Tschofenig]

>We also certainly don't want to put yet more hurdles into the 
>path of getting drafts published. Does the RFC editor have to 
>verify the URLs and that they still exist? Do we worry about 
>advertising pages and implementations that turn out to be 
>malicious? I'd really rather not have to deal with an RFC 
>where a domain of a fledgling open-source project was taken 
>over by a malware distributor.
>
>Henning

I would like to provide one recent example. In the EMU working group we
worked on a protocol, called EAP-GPSK http://www.ietf.org/rfc/rfc5433.txt. 
The work was done in a design team, it took a very long time (the first
design team draft dates back to May 2006). 

Jouni Malinen implemented the protocol in 8 hours! Jouni also provided a
number of suggestions and we put him into the acknowledgments section.
Before the draft got published as an RFC the reference to his implementation
was removed by the RFC Editor. The RFC Editor also verified the URL and it
was not correct anymore (but that's another topic). 

As mentioned in
http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.
txt the problem with feeding experience with running code back into the
specification work is elsewhere.

There are three main problems: 

* Almost random changes to the specification make early implementation work
almost useless (if your goal is to produce code that aims having code for a
specific RFC after all). Since it takes so long to finish the
standardization work it is often not possible to wait till the RFC comes
out. 

* Nobody cares if you have running code. Requests to substantially change
the specification often come at a late stage. Even IESG members have already
re-written specifications during IETF Last Call. As a joke, I suggested to
just submit the table of contents to the IESG and then start the work there.

* Finally, because it takes so long to finish specifications the 3-level
Standards Track process is rarely utilized anymore. That process considers
interoperable code but what does it help? 

Ciao
Hannes







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

Re: Internet Society joins Liberty Alliance Management Board: Why?

[Lynn St . Amour]

On Mar 1, 2009, at 9:04 PM, Eric Rescorla wrote:


At Sun, 1 Mar 2009 19:59:00 +0200,
Hannes Tschofenig wrote:
As you might have noticed, the WebSSO Identity Management space is  
not
running out of organizations and groups. Someone could, for  
example, come up
with the question why ISOC did not join the MIT Kerberos Consortium  
(see
http://www.kerberos.org/), as Kerberos is a technology developed  
within the
IETF, or to support technologies like OpenID, OAuth, etc. that are  
closer to

the Internet deployment.

I am sure your team had a lot of conversations with the IAB on what
direction would be better for the Internet (with respect to the  
creation of
an identity layer) but I fear that many in the IETF community are  
at best
not informed about what you are doing and why you believe that this  
is

heading into the right direction.


Did ISOC in fact have these discussions with the IAB? I'd be very  
interested

to hear the IAB weigh in here.

-Ekr



Hi Ekr and Hannes,

ISOC has been working within the IETF community as a whole on a  
variety of technical issues, and did not approach the IAB as a body  
when taking the decision to join Liberty Alliance/NewOrg.


ISOC's broad goals here seem largely to fall outside the IETF arena.   
We are working with these other communities to build a more  
transparent and open identity organization which serves the broader  
identity community, and reaches out to adopters and end-users.   We  
are, of course, very open to conversation about advancing these goals  
with any interested IETFer.  And, to be clear we are very  
supportive of the OAuth efforts and hope to see OAuth chartered in the  
IETF.


I echo Dave's original comments that this discussion is interesting  
and useful, and Leslie has provided some additional context in another  
mail.


Best,
Lynn


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

Re: Running Code

[Marc Petit-Huguenin]

Ned Freed wrote:
>> Harald Alvestrand wrote:
>>> Marc Petit-Huguenin wrote:
 I would like to bring to your attention this proposal to put back
 running code at the center of Internet protocol design by adding a
 new Considerations Section in future Internet-Drafts and RFCs:

 http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt



>>> There used to be a term for those who attempted to manipulate the shape
>>> of the universe by manipulating the names in the Usenet hierarchy.
>>>
>>> I get the same impression from people who want to manipulate IETF
>>> behaviour by manipulating the shape of Internet-Drafts.
> 
>> I do not see how you can have this impression, as the I-D does not
>> try to make implementations mandatory for Internet-Drafts - _that_
>> would be changing the IETF behavior.
> 
> On the contrary, that's exactly what it does. Quoting from the draft:
> 
>The "Running Code Considerations" section MUST be present in all
>Internet-Draft and SHOULD be inserted after the Security
>Considerations and IANA Considerations sections.  This section MUST
>be present even if the document does not describe an implementable
>protocol and should contain in this case a text explaining why this
>section is irrelevant.  The RFC Editor can remove this "Running Code
>Considerations" section before publication as RFC.

A "Running Code Considerations" section can be empty, this is the
reason of the last sentence (this is similar to what is done for the
IANA Consideration Section).  If a protocol described in an I-D has
no implementation then the section is empty, and people can decide
to invest in this protocol using this information.  This to say,
again, that the text does not implies that implementations are
mandatory, just that their existence must be documented in the I-D.

> 
> I'm already on record as oppossing the addition of such bureaucratic folderol
> in other cases.
> 
> And while I'm a big believer in running code and always try to implement 
> what's
> described in my drafts before calling them complete, I think this proposal is
> an absolutely terrible idea.
> 
>> What the document says is that
>> early implementers efforts should be rewarded by listing their name,
>> sponsors and access to their code as a thank you for helping improve
>> the protocol.  That does not change the IETF behavior - at best that
>> will change the quality of IETF protocols.
> 
> You need to read the draft again because that is not what it says.

OK, I do not know what to say here.  I read again the text, and
nowhere it is said that having an implementation is mandatory.
Documenting eventual implementations would be.

-- 
Marc Petit-Huguenin
Home: m...@petit-huguenin.org
Work: petit...@acm.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Running Code

[Marc Petit-Huguenin]

Henning Schulzrinne wrote:
>>
> 
> I admit that I'm no friend of additional I-D sections, as they easily
> generate into boilerplate and "make work" projects. If the goal, which
> does not seem stated, is to acknowledge the contributions of
> implementations in improving a standards document, we already have a
> mechanism for that, namely the customary acknowledgements found in most
> RFCs. I don't think anybody would object to saying something like
> 
> "The authors gratefully recognize the efforts of Joe Programmer, whose
> XYZ implementation of early versions of the draft helped to remove
> useless crud from the spec."
> 
> [well, maybe not quite verbatim like that.]
> 
> We can never hope to acknowledge all implementations in any event; for
> example, many are done by students in classes, and are never released
> (and that's a good thing...). It seems much more useful to capture
> implementations on WG-related web pages; after all, the value of
> implementations does not step when the I-D hits the RFC editor's desk.
> 
> We also certainly don't want to put yet more hurdles into the path of
> getting drafts published. Does the RFC editor have to verify the URLs
> and that they still exist? Do we worry about advertising pages and
> implementations that turn out to be malicious? I'd really rather not
> have to deal with an RFC where a domain of a fledgling open-source
> project was taken over by a malware distributor.

That's a good point.  The reference to the code is needed only until
the publication as RFC, so an URL does not need to be valid after
this - the subsequent need for two implementations for Draft
Standard is a completely different problem that have nothing to do
with my proposal.  So I will modify the draft to say that the URLs
have to be removed before publication as an RFC.

-- 
Marc Petit-Huguenin
Home: m...@petit-huguenin.org
Work: petit...@acm.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Running Code

[Masataka Ohta]

Andy Bierman wrote:

>> So, existence of required running code does not mean much.

> I disagree.
> It means the specification is implementable.

If a protocol is so complex that its implementability is not
obvious, you have lost from the beginning.

> Since the goal of our work is to produce specifications
> that will allow multiple independent implementations to
> inter-operate successfully,

How can you define successful interoperation of implementations?

> I think adequate procedures exist for gathering implementation
> experience for the IESG to evaluate protocol interoperability.

Such formalism has killed IETF.

To formally confirm that multiple implementations of a protocol
interoperate, which is required these days, you really need to
have a formal specification of a protocol, which, if any, is very
complex even if an informal specification of the protocol is simple.

If all you want is informal and vague feeling of interoperability,
it is not a very useful review.

Masataka Ohta

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

Re: Running Code

[ned+ietf]

> Harald Alvestrand wrote:
> > Marc Petit-Huguenin wrote:
> >> I would like to bring to your attention this proposal to put back
> >> running code at the center of Internet protocol design by adding a
> >> new Considerations Section in future Internet-Drafts and RFCs:
> >>
> >> http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt
> >>
> >>
> >>
> > There used to be a term for those who attempted to manipulate the shape
> > of the universe by manipulating the names in the Usenet hierarchy.
> >
> > I get the same impression from people who want to manipulate IETF
> > behaviour by manipulating the shape of Internet-Drafts.

> I do not see how you can have this impression, as the I-D does not
> try to make implementations mandatory for Internet-Drafts - _that_
> would be changing the IETF behavior.

On the contrary, that's exactly what it does. Quoting from the draft:

   The "Running Code Considerations" section MUST be present in all
   Internet-Draft and SHOULD be inserted after the Security
   Considerations and IANA Considerations sections.  This section MUST
   be present even if the document does not describe an implementable
   protocol and should contain in this case a text explaining why this
   section is irrelevant.  The RFC Editor can remove this "Running Code
   Considerations" section before publication as RFC.

I'm already on record as oppossing the addition of such bureaucratic folderol
in other cases.

And while I'm a big believer in running code and always try to implement what's
described in my drafts before calling them complete, I think this proposal is
an absolutely terrible idea.

> What the document says is that
> early implementers efforts should be rewarded by listing their name,
> sponsors and access to their code as a thank you for helping improve
> the protocol.  That does not change the IETF behavior - at best that
> will change the quality of IETF protocols.

You need to read the draft again because that is not what it says.

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

Re: Running Code

[Andy Bierman]

Masataka Ohta wrote:

Hallam-Baker, Phillip wrote:


I don't see the value of running code quite as others do.


I agree. It was valuable in good old days, when implmenting a protocol
was purely voluntary with no budget.

Existence of multiple independent implementations, then, meant the
protocol was widely accepted by the society.

However, after the overly introduction of standardization engineering
to IETF, people satisfy requirements merely because they are required.

So, existence of required running code does not mean much.


I disagree.
It means the specification is implementable.

Since the goal of our work is to produce specifications
that will allow multiple independent implementations to
inter-operate successfully, I can think of no more valuable
review input towards this goal than comments from implementers.

I think adequate procedures exist for gathering implementation
experience for the IESG to evaluate protocol interoperability.




Masataka Ohta


Andy

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

Re: Running Code

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Masataka!

On Wed, 4 Mar 2009, Masataka Ohta wrote:

> So, existence of required running code does not mean much.

Except a basic proof of real functionality and that is valuable.

RGDS
GARY
- ---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
g...@rellim.com  Tel:+1(541)382-8588

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFJrejvBmnRqz71OvMRAi+VAKCVsUj7BHea+p5/9S/4HFuQLI/iBwCgvHaQ
TWSzTobAnC1lNpsvEvqE1iY=
=Kysh
-END PGP SIGNATURE-

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

Re: Running Code

[Masataka Ohta]

Hallam-Baker, Phillip wrote:

> I don't see the value of running code quite as others do.

I agree. It was valuable in good old days, when implmenting a protocol
was purely voluntary with no budget.

Existence of multiple independent implementations, then, meant the
protocol was widely accepted by the society.

However, after the overly introduction of standardization engineering
to IETF, people satisfy requirements merely because they are required.

So, existence of required running code does not mean much.

Masataka Ohta

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

RE: Running Code

[Hallam-Baker, Phillip]

I don't see the value of running code quite as others do.

For me the value of running code is that the requirement to actually implement 
stuff does tend to reduce the scope for complexity, you have someone in the 
room pushing against something that will make work for them. And the other 
advantage is that there tends to be a closer relationship to actual real world 
needs.

But you do not have to do A to get B and doing A does not guarantee that you 
get B.

Another alternative is to require people to produce a proof of correctness for 
their protocol. That provides even greater encouragement to be concise and to 
get it right the first time. 


The running code strategy can also backfire. I have seen groups where one party 
has a large development team on call that allows them to drive the 
specification. And I have also seen groups where no progress can be made 
because the programmer who wrote the dufus code won't allow the dufus to be 
deleted from the spec. Coding too early can also be a problem.


-Original Message-
From: ietf-boun...@ietf.org on behalf of Brian E Carpenter
Sent: Tue 3/3/2009 4:54 PM
To: Marc Petit-Huguenin
Cc: ietf@ietf.org
Subject: Re: Running Code
 
Marc, and Henry,

I think adding any new mandatory section to all I-Ds is a bad idea.
It will quickly become bureaucratic. We've had proposals for mandatory
Management Considerations, IPv6 Considerations, and no doubt others
that I've forgotten, and they all have the same problem.

However, I think it's a very good idea to offer *guidelines* for what
should be in technical specifications in this area. In fact, my old
commentary on RFC2026 talked about related issues concerning
interoperability criteria for promotion to Draft Standard.
See the comments on "4.1.2 Draft Standard" in
http://tools.ietf.org/id/draft-carpenter-rfc2026-practice-00.txt
Obviously, the first stage in interoperability is interoperability
with yourself ;-).
(As far as I am concerned, you are welcome to use any of that
material under RFC5378 conditions.)

I encourage your draft to become purely a set of guidelines.
That would be useful and non-bureaucratic.

Brian

On 2009-03-04 10:17, Marc Petit-Huguenin wrote:
> I would like to bring to your attention this proposal to put back
> running code at the center of Internet protocol design by adding a
> new Considerations Section in future Internet-Drafts and RFCs:
> 
> http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt
> 
> Thanks.
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

Re: Running Code

[Henning Schulzrinne]

I admit that I'm no friend of additional I-D sections, as they easily  
generate into boilerplate and "make work" projects. If the goal, which  
does not seem stated, is to acknowledge the contributions of  
implementations in improving a standards document, we already have a  
mechanism for that, namely the customary acknowledgements found in  
most RFCs. I don't think anybody would object to saying something like


"The authors gratefully recognize the efforts of Joe Programmer, whose  
XYZ implementation of early versions of the draft helped to remove  
useless crud from the spec."


[well, maybe not quite verbatim like that.]

We can never hope to acknowledge all implementations in any event; for  
example, many are done by students in classes, and are never released  
(and that's a good thing...). It seems much more useful to capture  
implementations on WG-related web pages; after all, the value of  
implementations does not step when the I-D hits the RFC editor's desk.


We also certainly don't want to put yet more hurdles into the path of  
getting drafts published. Does the RFC editor have to verify the URLs  
and that they still exist? Do we worry about advertising pages and  
implementations that turn out to be malicious? I'd really rather not  
have to deal with an RFC where a domain of a fledgling open-source  
project was taken over by a malware distributor.


Henning


I do not see how you can have this impression, as the I-D does not
try to make implementations mandatory for Internet-Drafts - _that_
would be changing the IETF behavior.  What the document says is that
early implementers efforts should be rewarded by listing their name,
sponsors and access to their code as a thank you for helping improve
the protocol.  That does not change the IETF behavior - at best that
will change the quality of IETF protocols.

--
Marc Petit-Huguenin
Home: m...@petit-huguenin.org
Work: petit...@acm.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



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

Re: Running Code

[Marc Petit-Huguenin]

Harald Alvestrand wrote:
> Marc Petit-Huguenin wrote:
>> I would like to bring to your attention this proposal to put back
>> running code at the center of Internet protocol design by adding a
>> new Considerations Section in future Internet-Drafts and RFCs:
>>
>> http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt
>>
>>
>>   
> There used to be a term for those who attempted to manipulate the shape
> of the universe by manipulating the names in the Usenet hierarchy.
> 
> I get the same impression from people who want to manipulate IETF
> behaviour by manipulating the shape of Internet-Drafts.

I do not see how you can have this impression, as the I-D does not
try to make implementations mandatory for Internet-Drafts - _that_
would be changing the IETF behavior.  What the document says is that
early implementers efforts should be rewarded by listing their name,
sponsors and access to their code as a thank you for helping improve
the protocol.  That does not change the IETF behavior - at best that
will change the quality of IETF protocols.

-- 
Marc Petit-Huguenin
Home: m...@petit-huguenin.org
Work: petit...@acm.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Terminal room at IETF74

[Mark Andrews]

In message , John C Klensin writes:
> 
> 
> --On Wednesday, March 04, 2009 07:51 +1100 Mark Andrews
>  wrote:
> 
> >...
> > There is no "interesting direction".  I'm pretty sure customs
> > gets the same sort of search and ceasure rights on exit and
> > it does on arrival.  They do here in Australia.
> 
> In principle, probably.   In practice, travelers leaving the US
> don't even get to see customs officials.

I beg to differ.  I've seen them myself.  Not often but
on more than one occassion.
 
>john
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Terminal room at IETF74

[John C Klensin]

--On Wednesday, March 04, 2009 07:51 +1100 Mark Andrews
 wrote:

>...
>   There is no "interesting direction".  I'm pretty sure customs
>   gets the same sort of search and ceasure rights on exit and
>   it does on arrival.  They do here in Australia.

In principle, probably.   In practice, travelers leaving the US
don't even get to see customs officials.

   john



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

Re: Running Code

[Harald Alvestrand]

Marc Petit-Huguenin wrote:

I would like to bring to your attention this proposal to put back
running code at the center of Internet protocol design by adding a
new Considerations Section in future Internet-Drafts and RFCs:

http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt

  
There used to be a term for those who attempted to manipulate the shape 
of the universe by manipulating the names in the Usenet hierarchy.


I get the same impression from people who want to manipulate IETF 
behaviour by manipulating the shape of Internet-Drafts.


(and - going into nits mode - the idea that only implementations that 
can be dowloaded from a public URL "count" as implementations flies into 
the face of long-term IETF policy.)


  Harald

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

Stepping back a bit Re: Internet Society joins Liberty Alliance Management Board: Why?

[Leslie Daigle]

As Lynn mentioned in her message, ISOC has been building up more 
technical programmes over the course of the last couple of years.  I 
want to take the opportunity to say a bit more about that, as an 
indirect way of addressing the issue of what types of decisions are 
being made, and what the intended implications are.


First, ISOC is dedicated to keeping the Internet development model open 
and functioning, and it is dedicated to supporting the IETF.


A couple of things that this means in practice are that ISOC develops 
messaging for the non-IETF, not-always-technical communities pointing 
out the strengths and virtues of the Internet's open development model, 
and the appropriate venues for carrying out policy and technical 
discussions.  And then we go out and work with different groups, in 
various ways, to get that message across.  You can see some examples of 
that in our contributions to the ITU-T World Telecomms Standards 
Assembly meeting in Johannesburg last year -- fact sheets on Internet 
standards (pointing to the IETF), IPv6 policy (pointing to the RIRs for 
regional policy discussions), etc.


http://www.isoc.org/pubpolpillar/governance/itu-wtsa_2008.shtml
http://www.isoc.org/pubpolpillar/docs/ISOC-WTSA_20081017.pdf
http://www.isoc.org/pubpolpillar/docs/ISOC-ITU-ipv6_20081017.pdf

We're also doing work to raise awareness about critical issues facing 
the Internet.  As an example, I don't want to discuss an unannounced 
product ( ;-) ), but we're planning an IPv6 briefing  (targeted not at 
us engineers, but rather at the deploying world) in conjunction with IETF74.


These are things ISOC does to further its own mission of promoting the 
open development, evolution, and use of the Internet for the benefit of 
all people throughout the world, and not because it is the 
organizational home of the IETF.


When we participate in IETF work, we (like everyone else) participate as 
individuals, and we work quite hard, internally, to make sure we don't 
presume a special role with the IETF in deciding its course.


And, if people want to know more about what we're up to, I'm always 
happy to come talk about it.


So, coming back to the issue at hand -- while it is unfortunate if ISOC 
winds up surprising the IETF leadership with its decisions, rather than 
being a decision made in ignorance of the state of technical discussions 
in the identity community, I believe that it was a decision made in 
consideration of the broader world of influences on open Internet 
development than are typically discussed within the IETF or any of the 
identity-specific development groups.


ISOC joined Liberty to have a voice in shaping the new organization to 
ensure that it is open, transparent, and not subject to capture by the 
interests of a single technology or community:  consistent with the 
Internet development model.  In the long run, we hope that various open 
efforts will gain a great deal by bringing their ideas and concerns into 
this process as it means that their work will get out to audiences along 
with the messages coming from large companies, technology partisans, etc.


From our perspective, the time has come to move identity efforts to 
wider deployment, and they need to find a way to communicate both the 
importance of the solutions they offer and the ways that users can best 
manage both their own identity and the slew of new relationships that 
these technologies will enable.  I know Lucy is always looking for input 
-- providing some concrete input on how best to achieve this would 
certainly be considered helpful to ISOC.


And none of this should particularly challenge the IETF or any identity 
work it chooses to take on or not; you'll have seen at least two of us 
individuals raising our hands in support of the OAUTH work in the last BoF.


Thanks,
Leslie.

===
Leslie Daigle
Chief Internet Technology Officer, ISOC
dai...@isoc.org


Eran Hammer-Lahav wrote:

My concern regarding this announcement is the fact that it gives support to a 
misguided effort by Liberty Alliance. I think it is somewhat irresponsible for 
the ISOC to actively support an effort without first engaging the community at 
large to fully understand the dynamics of the identity communities involved.

The people behind the IDtbd effort have been going around trying to sell this 
effort for a while. The reality is that at this point, the communities behind 
two of the most successful identity related protocols, OAuth and OpenID, have 
rejected this effort by Liberty, including many of the individual companies 
that support these communities.

I find it personally offensive that Liberty have been going behind the OAuth's 
community's back trying get corporations to move their OAuth and OpenID efforts 
to IDtbd instead of the communities that drive these efforts forward.

IDtbd is an effort to create a full-blown standard body to manage all identity 
related protocols, with its own set of IPR rules, process, an

Re: Passing of Jim Bound

[Philip Nesser]

It is amazing how events coincide.  I have not talked to Jim in
several years and was thinking of him yesterday, determined to look
him up today and seeing what he was up too.  I remember meeting him at
my first IETF in Seattle in 1993 or 1994.  I was very interested in
IPng at the time and as a member of the IPng Directorate I spent a
fair amount of time talking to him at that IETF and many others over
the years.

I distinctly recall a very memorable IETF Plenary (at Danvers I
believe) where the Security directorate had taken the (it seemed to us
at the time) noble stance of making 56bit DES a MUST implement for
IPsec as a direct challenge to the US policy at the time to limit
export of encryption software above 40bits of key strength.  Jim gave
an impassioned presentation against the decision using "The Art of
War" as the theme.

At the time, Jim was a Vendor/Developer Incarnate in a world of
protocol geeks.  He always pointed out the issues a vendor would have
with delivering a product based on a draft or RFC.

I am very saddened to hear about his passing.  If anyone knows his
familly please express all of our good wishes.

Sincerely saddened,

Phil

On Tue, Mar 3, 2009 at 1:59 PM, Russ Housley  wrote:
> This is very sad news.  Jim was a very strong supporter of the IETF and
> IPv6.
>
> Jim served the community as:
>  -  IPv6 Forum Chief Technology Officer
>  -  Chair of the North American IPv6 Task Force
>  -  Active IETF contributor, including member of the IPng Directorate
>
> We will miss him.
>
> Russ
>
>
> --- forwarded message ---
>
> From: "Pouffary, Yanick" 
> Date: March 3, 2009 8:23:07 AM EST
> To: nav...@ipv6forum.com, memb...@ipv6forum.com
> Subject: Jim Bound
>
> Dear IPv6-ers,
> Jim Bound passed away yesterday. Jim was only 58 years old.
> Jim was a symbol of integrity and professionalism.
> He made a profound impact on our industry and everyone who worked with him.
> I am very fortunate to have been able to also call Jim friend.
> Very very sad time,
> Yanick
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 

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

Re: Running Code

[Marc Petit-Huguenin]

Brian E Carpenter wrote:
> Marc, and Henry,
> 
> I think adding any new mandatory section to all I-Ds is a bad idea.
> It will quickly become bureaucratic. We've had proposals for mandatory
> Management Considerations, IPv6 Considerations, and no doubt others
> that I've forgotten, and they all have the same problem.

I agree that its sounds bad when presented like this.

The main motivation is to provide an incentive for early
implementations of a protocol, because I am convinced that this is a
very important factor on the quality of a protocol.  I had to
implement at least three times TURN from scratch during it's
development and this is an exhausting task.  This explain why a lot
of developers simply wait for the protocol to be stable (read: been
published as an RFC), and so deprive the protocol design of an
important feedback.  Giving to early implementers a guaranty that
their contributions will not be forgotten is a way to counterbalance
the time and effort spent in working on this contributions.

> 
> However, I think it's a very good idea to offer *guidelines* for what
> should be in technical specifications in this area. In fact, my old
> commentary on RFC2026 talked about related issues concerning
> interoperability criteria for promotion to Draft Standard.
> See the comments on "4.1.2 Draft Standard" in
> http://tools.ietf.org/id/draft-carpenter-rfc2026-practice-00.txt
> Obviously, the first stage in interoperability is interoperability
> with yourself ;-).
> (As far as I am concerned, you are welcome to use any of that
> material under RFC5378 conditions.)
> 
> I encourage your draft to become purely a set of guidelines.
> That would be useful and non-bureaucratic.
> 
> Brian
> 
> On 2009-03-04 10:17, Marc Petit-Huguenin wrote:
>> I would like to bring to your attention this proposal to put back
>> running code at the center of Internet protocol design by adding a
>> new Considerations Section in future Internet-Drafts and RFCs:
>>
>> http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt
>>
>> Thanks.
>>
> 


-- 
Marc Petit-Huguenin
Home: m...@petit-huguenin.org
Work: petit...@acm.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Running Code

[Peter Saint-Andre]

Marc Petit-Huguenin wrote:
> I would like to bring to your attention this proposal to put back
> running code at the center of Internet protocol design by adding a
> new Considerations Section in future Internet-Drafts and RFCs:
> 
> http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt

It might be helpful to define what running code is. I've been meaning to
write an I-D about that but haven't gotten to it yet...

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

Passing of Jim Bound

[Russ Housley]

This is very sad news.  Jim was a very strong supporter of the IETF and IPv6.

Jim served the community as:
  -  IPv6 Forum Chief Technology Officer
  -  Chair of the North American IPv6 Task Force
  -  Active IETF contributor, including member of the IPng Directorate

We will miss him.

Russ


--- forwarded message ---

From: "Pouffary, Yanick" 
Date: March 3, 2009 8:23:07 AM EST
To: nav...@ipv6forum.com, memb...@ipv6forum.com
Subject: Jim Bound

Dear IPv6-ers,
Jim Bound passed away yesterday. Jim was only 58 years old.
Jim was a symbol of integrity and professionalism.
He made a profound impact on our industry and everyone who worked with him.
I am very fortunate to have been able to also call Jim friend.
Very very sad time,
Yanick

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

Re: Running Code

[Brian E Carpenter]

Marc, and Henry,

I think adding any new mandatory section to all I-Ds is a bad idea.
It will quickly become bureaucratic. We've had proposals for mandatory
Management Considerations, IPv6 Considerations, and no doubt others
that I've forgotten, and they all have the same problem.

However, I think it's a very good idea to offer *guidelines* for what
should be in technical specifications in this area. In fact, my old
commentary on RFC2026 talked about related issues concerning
interoperability criteria for promotion to Draft Standard.
See the comments on "4.1.2 Draft Standard" in
http://tools.ietf.org/id/draft-carpenter-rfc2026-practice-00.txt
Obviously, the first stage in interoperability is interoperability
with yourself ;-).
(As far as I am concerned, you are welcome to use any of that
material under RFC5378 conditions.)

I encourage your draft to become purely a set of guidelines.
That would be useful and non-bureaucratic.

Brian

On 2009-03-04 10:17, Marc Petit-Huguenin wrote:
> I would like to bring to your attention this proposal to put back
> running code at the center of Internet protocol design by adding a
> new Considerations Section in future Internet-Drafts and RFCs:
> 
> http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt
> 
> Thanks.
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Repair of Public Mail List Archives Complete

[Alexa Morris]

As I mentioned late last week, as a side effect of a recent Mailman  
upgrade some mail lists with previously public archives had their list  
configuration reset to private archiving, resulting in  inaccessible  
archives. This archiving issue has now been repaired and the "missing"  
archives have been transferred from private to public.


All lists with public archives should now have the complete set of  
messages.


As always, please contact me with any questions or concerns.

Regards,
Alexa

---
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

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

Running Code

[Marc Petit-Huguenin]

I would like to bring to your attention this proposal to put back
running code at the center of Internet protocol design by adding a
new Considerations Section in future Internet-Drafts and RFCs:

http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt

Thanks.

-- 
Marc Petit-Huguenin
Home: m...@petit-huguenin.org
Work: petit...@acm.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Terminal room at IETF74

[Mark Andrews]

In message , Samuel Weil
er writes:
> On Mon, 2 Mar 2009, John C Klensin wrote:
> 
> > * Machines in the "netbook" category have gotten very cheap (cheaper 
> > than IETF registration fees, for example).  While I would not expect 
> > your company to change policy, obtaining a few of those machines and 
> > imaging them to contain nothing in local storage of corporate 
> > interest would seem economic - you are presumably not the only 
> > person who travels to the US.
> 
> I second this idea.
> 
> Given the duties on some of these systems in the EU, you might 
> consider buying from a US vendor, having the machine shipped to the 
> IETF hotel, and installing your choice of OS when you arrive.  And 
> then you entirely avoid taking the system through US customs in the 
> interesting direction.
> 
> Also consider used laptops: I just picked up a used Dell Latitude for 
> about the same price as a netbook (and half the price of IETF 
> registration), and I'm delighted.
> 
> -- Sam
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

There is no "interesting direction".  I'm pretty sure customs
gets the same sort of search and ceasure rights on exit and
it does on arrival.  They do here in Australia.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Tools to Publish I-Ds with pre-5378 Content

[Ray Pelletier]

All;

Several tools to publish Internet Drafts have implemented the IETF  
Trust's recent policy changes that provide a work-around to the issues  
raised by the inclusion of material from contributions published  
before 10 November 2008.  You may have already been aware of one or  
more of the tools from other lists, or discussions on this list, but  
the Trust wanted to consolidate the information to ensure its general  
and aggregated availability, even at this time, just 24 hours before  
the -00 deadline for IETF 74.


If your Internet Draft  contains pre-5378 Material as to which the  
IETF Trust has not been granted, or may not have been granted, the  
necessary permissions to allow modification of such pre-5378 Material  
outside the IETF Standards Process then section 6.c.iii from http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf 
 must be included in the draft.


Volunteers who created and maintain the tools have implemented the  
updates:


1. idnits - (thanks Henrik Levkowetz)
2. Word template - (thanks Joe Touch)
3. xml2rfc - (thanks Bill Fenner and Marshall Rose)

The tools can be found at:
1. idnits - http://tools.ietf.org/tools/
2. Word template - http://tools.ietf.org/inventory/author-tools.shtml
3. xml2rfc - http://xml.resource.org/experimental.html

A little more info on the xml2rfc variants (borrowed from Julian  
Reschke - thanks)


This version, v1.34pre3, implements the IETF Trust language of  
November, 2008 and

February, 2009.

Briefly, you want to set the 'ipr' attribute of the  element to  
one of these values:


trust200811
noModificationTrust200811
noDerivativesTrust200811
trust200902
noModificationTrust200902
noDerivativesTrust200902
pre5378Trust20090

The final value in the list above is probably the one of interest to  
most folks.


At this point, only the *200902* variants should be relevant (not all of
those changed from 200811, but we added all of them for consistency).

(1) "trust200902" is the value to choose when no restrictions are  
being made.


(2) "noModificationTrust200902" adds

"This document may not be modified, and derivative works of it may not
be created, except to format it for publication as an RFC or to
translate it into languages other than English."

as defined in Section 6.c.i of
.


(3) "noDerivativesTrust200902" adds

"This document may not be modified, and derivative works of it may not
be created, and it may not be published except as an Internet-Draft."

as defined in Section 6.c.ii of
.


(4) "pre5378Trust200902" adds

"This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow modifications of
such material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in such
materials, this document may not be modified outside the IETF Standards
Process, and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC or to
translate it into languages other than English."

as defined in Section 6.c.iii of
.
This is the new variant that was introduced because of the problems
discovered in November with RFC 5378.

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

RE: Internet Society joins Liberty Alliance Management Board: Why?

[Hannes Tschofenig]

> So at this point the rule in the identity space is safety in numbers. The
major waring factions are now spending considerable 
> time and effort to show that the war is over and there is going to be a
concerted joint effort. Thus ISOC joining liberty does > not represent the
IETF taking sides in a Betamax/VHS battle. That would have been an issue
three years ago, it is not really an > issue at this point.
 
So, who is the winner? (Or are there only loosers, more like in a real war?)
 

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

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[ned+ietf]

s...@resistor.net writes:
> If there isn't an authoritative reference and there are differences in
> semantics or syntax between the draft and RFC5321/5322 or future
> revisions of these documents, it can lead to serious issues.
> Standards Track documents are around years.  The documents may be
> edited by different authors as they get updated.  Errors can happen;
> the documents can diverge.
>
> In my opinion, it is better to clarify that now or else we will end up
> having discussions ten years from now to determine which
> interpretation is correct or which standard to follow.



So. RFC 3501 (page 50-51), says that the localpart of a From: address is
matched case-insensitively when IMAP servers process SEARCH or UID
SEARCH commands. RFC 5321 says that SMTP servers process localparts
case-sensitively. Both rules go back essentially unchanged to very old
RFCs.


But that's the problem - this is not what RFC 5321 says. It says:

  Consequently, and due to a
  long history of problems when intermediate hosts have attempted to
  optimize transport by modifying them, the local-part MUST be
  interpreted and assigned semantics only by the host specified in the
  domain part of the address.

SMTP server do stuff like expand lists all the time. For those tests to be 
done competently some amount of interpretation of local parts may be needed,

such as ignoring the possibility that the local part is case sensitive.

Now, if RFC 5321 instead said that interpretation of local parts MUST be
limited to comparison operations, and local parts MUST NOT be modified, the
problem mostly goes away. (There are probably still some odd corner cases left
for gateways, but after thinking about it some more I think we can ignore
those.)


Do we need to discuss which is correct or which standard to follow? I
fail to see any conflict.


I have to disagree. While there may not be any conflict between RFC 3501 and
RFC 5321 since they deal with separate components, the fact remains that
there's a conflict between what real world implementations do and what RFC 5321
says must not be done.

Ned 
___

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

Re: Terminal room at IETF74

[Samuel Weiler]

On Mon, 2 Mar 2009, John C Klensin wrote:

* Machines in the "netbook" category have gotten very cheap (cheaper 
than IETF registration fees, for example).  While I would not expect 
your company to change policy, obtaining a few of those machines and 
imaging them to contain nothing in local storage of corporate 
interest would seem economic - you are presumably not the only 
person who travels to the US.


I second this idea.

Given the duties on some of these systems in the EU, you might 
consider buying from a US vendor, having the machine shipped to the 
IETF hotel, and installing your choice of OS when you arrive.  And 
then you entirely avoid taking the system through US customs in the 
interesting direction.


Also consider used laptops: I just picked up a used Dell Latitude for 
about the same price as a netbook (and half the price of IETF 
registration), and I'm delighted.


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

Last Call: draft-ietf-avt-seed-srtp (The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)) to Proposed Standard

[The IESG]

The IESG has received a request from the Audio/Video Transport WG (avt) 
to consider the following document:

- 'The SEED Cipher Algorithm and Its Use with the Secure Real-time 
  Transport Protocol (SRTP) '
   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 2009-03-27. 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://www.ietf.org/internet-drafts/draft-ietf-avt-seed-srtp-09.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16505&rfc_flag=0


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

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[Arnt Gulbrandsen]

s...@resistor.net writes:
If there isn't an authoritative reference and there are differences in 
semantics or syntax between the draft and RFC5321/5322 or future 
revisions of these documents, it can lead to serious issues.  
Standards Track documents are around years.  The documents may be 
edited by different authors as they get updated.  Errors can happen; 
the documents can diverge.


In my opinion, it is better to clarify that now or else we will end up 
having discussions ten years from now to determine which 
interpretation is correct or which standard to follow.


So. RFC 3501 (page 50-51), says that the localpart of a From: address is 
matched case-insensitively when IMAP servers process SEARCH or UID 
SEARCH commands. RFC 5321 says that SMTP servers process localparts 
case-sensitively. Both rules go back essentially unchanged to very old 
RFCs.


Do we need to discuss which is correct or which standard to follow? I 
fail to see any conflict.


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

RE: Internet Society joins Liberty Alliance Management Board: Why?

[Hallam-Baker, Phillip]

I think that a rather more fundamental problem is the fact that the IETF 
constitution prevents any organization or party speaking on behalf of the IETF 
as a whole.

I agree that it would be rather better if the IAB could take on this particular 
role than ISOC. But even the IAB can only represent a subset of IETF views on 
this topic. The tendency of NOMCON is to pick an IAB that 'will work together', 
which tends to mean that conflicting technical views have already been excluded 
before the IAB discussion begins. 

At least the IAB could serve as a conduit for Liberty views into the IETF. I 
don't see ISOC playing that role.


>From a wider industry view, it is important to recognize here that the Liberty 
>Alliance of 2009 is not the same organization that it was at the start, nor do 
>the same conditions exist in the industry as then.

Liberty began at a time when the industry and mainstream press saw 'identity' 
as a gold rush. Many thought that the first company to establish a claim would 
gain control of cyberspace and so on. Liberty and AOL Magic Carpet were begun 
as an attempt to stop Microsoft Passport.

At this point we know that the original premise behind that particular industry 
battle was false. Deployment of an industry wide identity system is a much 
harder prospect than anyone thought then. There is really no risk that a 
proprietary system will grow like kudzu and engulf the net and this is now 
something that all the industry majors understand (but not some VC funded 
startups predicated on that strategy).


So at this point the rule in the identity space is safety in numbers. The major 
waring factions are now spending considerable time and effort to show that the 
war is over and there is going to be a concerted joint effort. Thus ISOC 
joining liberty does not represent the IETF taking sides in a Betamax/VHS 
battle. That would have been an issue three years ago, it is not really an 
issue at this point.


There are however some technical issues that need to be input to the debate 
that the IETF does need to take a stand on:

1) The DNS is the sole naming system for the Internet.

Identity is not an opportunity to roll out a new naming scheme whether the 
protocols are proprietary or not, whether the registry is open or not. Uniform 
naming schemes arise very infrequently. We have only had five uniform 
addressing schemes since the industrial revolution - latitude/longitude, the 
postal address system, telephone numbers, UPC barcodes and DNS names. If you 
can think of another, please let me know, I am thinking of writing a brief 
history of names.

Attempting to create a new naming basis inevitably attracts antibodies. My 
strong belief is that it is only possible to establish a naming system if 
people are not really paying attention. At this point everything connected to 
the Internet is scrutinized by people and organizations and governments that 
much prefer nothing to happen than for something to happen than might 
subsequently create a control point that is outside their control.

2) Make the base protocol simple

One of the big issues I take with many of the schemes out there is that they 
take an ISAKMP type approach to technology. Rather than commit to an actual 
decision we have mechanisms to negotiate mechanisms. It is not necessary to do 
that. Factor the authentication question out of the federation problem. 
Authentication technology is a bilateral choice between the end user and the 
authentication service. The relying party does not need to know anything about 
the technology or protocol employed. 

3) Make the protocol comprehensible

The most irritating phenomena in the 'identity' world is the proliferation of 
jargon. Rather than attempting to learn existing nomenclature, some have 
invented their own. As a result technical progress tends to be slow.



-Original Message-
From: ietf-boun...@ietf.org on behalf of John C Klensin
Sent: Sun 3/1/2009 10:12 PM
To: Patrik Fältström; Dave CROCKER
Cc: Hannes Tschofenig; ietf@ietf.org; Lynn St. Amour; dai...@isoc.org
Subject: Re: Internet Society joins Liberty Alliance Management Board:  Why?
 
Patrik,

I fear that I need to side with Dave on this (!).  For issues at
the technology-policy boundary, ISOC is seen in the outside
community as the representative and "voice" of the IETF.  That
is generally a good thing and it is an impression many of us
have worked for years to create.  However, its side-effect is
that, if ISOC ventures into a management/policy role with one
particular consortium, the same folks we have been trying to
persuade that ISOC should be seen as the lead policy body in the
Internet technical community --in large measure because it does
represent the IETF-- are likely to infer (and reasonably so)
IETF endorsement of that consortium and its efforts.

That ultimately has little or nothing to do with whether the
IETF has active work in the area or how that work is organized.
It is the presumption

RE: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU

[Tex Texin]

Hi guys,

I sent the message to this list (as well as LTRU) in the belief I was
following the instructions given to me...
(My mail actually preceded Martin's request to the AD.)

I admit to confusion about the suggestion I can register the change after
4645bis is accepted.
4645bis changes a code that exists already. I shouldn't have to reregister
it to restore it.
If anything, have 4645bis go forward without the change, and the change can
be discussed separately.

I'll pursue the discussion on the ltru list as requested and respond to
Randy's other comments there.

tex


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Randy Presuhn
Sent: Monday, March 02, 2009 5:36 PM
To: ietf@ietf.org
Subject: Re: draft-ietf-ltru-4645bis-10.txt issue with preferred value for
YU

Hi -

> From: "Phillips, Addison" 
> To: 
> Sent: Monday, March 02, 2009 9:49 AM
> Subject: RE: draft-ietf-ltru-4645bis-10.txt issue with preferred value for
YU
>
> Hi Tex,
> 
> I don't think this is probably appropriate, at least for this list to
consider.

Tex's posting came after the document shepherd (co-chair Martin Duerst)
had sent the information to our AD requesting that the IESG consider
publishing it.  So although the IESG has not yet (AFAIK) acted on the
request, much less issued an IETF last call, I can understand why
ietf@ietf.org might be included.

I have already responded to it on both lists, even though I think the
issue is probably of little interest to most on the ietf@ietf.org list.
Unless instructed to do otherwise by our AD, I would suggest that
all follow-on discussion be directed to l...@ietf.org

> 1. You haven't posted to LTRU's mailing list, only ietf-languages@, yet.

Tex's message was posted to *both* lists.

> 2. Even if draft-4645bis is approved, the process for language tags
> (in either RFC 4646 or its proposed successor) allow you to register
> the information you want, if you think it was inappropriately omitted.
...

Correct.

Randy

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

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

RE: Terminal room at IETF74

[Dearlove, Christopher (UK)]

Alexa Morris
> Actually, the Terminal Room will have two laptops set up for attendee

> use; these are traditionally used primarily for printing (boarding  
> passes, etc) but are available for other uses as well.

That's useful to know. I did enquire of the Secretariat
(reference rt.amsl.com #13335) as to whether there would
be any such machines, and got a negative answer before
raising it here.


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.


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

Re: Terminal room at IETF74

[Dean Willis]

On Mar 2, 2009, at 1:52 PM, Joel Jaeggli wrote:


Dearlove, Christopher (UK) wrote:

But now, if I come to IETF74, I won't have a laptop with me.
Corporate policy, based on recent US legal decisions, is that
I may not take a laptop (or PDA etc.) into the USA. This is
not subject to modification. Obviously even a machine in the
terminal room would be a very poor second, but it seems even
that is out.


I don't know about you but I wouldn't trust a public terminal no  
matter

how well maintained for the applications which I carry a laptop.

Depending on your bent, either a personal laptop (with no corporate  
data

on it) or a mobile phone with the appropriate email conduit but no
pre-existing configuration might be a more desirable (and secure)  
way to go.




The worry is not that the border goons will expose confidential  
information on one's device, but that they'll CLAIM they did (even if  
they have to insert it themselves), and there's no way to disprove  
this when the device is writable.


Hence the need to carry no writable devices across the border, not  
even a USB memory stick or a camera. Or a modern cellphone, for that  
matter.


Of course, that doesn't keep them from claiming that you had a  
writable device in your possession, then planting one there. Given  
sufficient paranoia in one's threat model, there's just no way to  
justify waking up in the morning.


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