Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

[Alexey Melnikov]

Hi Ben,
Thank you for your comments. Responding to most of them below (I will
respond to the rest in a separate message).

On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell  wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-sasl-scram-07
> Reviewer: Ben Campbell
> Review Date: 2009-08-23
> IETF LC End Date: 2009-08-28
> IESG Telechat date: (if known)
>
> Summary:
>
> This draft is almost ready for publication as a proposed standard. I have a
> few questions and editorial comments that might be worth considering prior
> to publication.
>
> Major issues:
>
> None.
>
>
> Minor issues:
>
> - Section 2, 1st paragraph: "...addresses the requirements necessary to
> deploy a challenge- response mechanism more widely than past attempts."
>
> What are these requirements? Are they documented somewhere? Do you mean for
> appendix A or B to express them?

Yes. I've added forward references.

[...]

> I'm no crypto expert, so please forgive me if this is silly--but isn't there
> a movement to phase out sha-1? If so, should that be the default "must
> implement" hash for a new mechanism?

My understanding is that use of SHA-1 under HMAC is still considered reasonable.
The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided
to proceed with SHA-1, because it is more frequently implemented in libraries
and hardware.

> -- section 5.1, definition of "r:", "It is important that this value be
> different for each authentication."
>
> Are there any best practices for nonce generation that can be mentioned or
> referenced?

The reference to RFC 4086 is already present elsewhere in the document,
but I added it here.

> -- Section 9, 1st paragraph:
>
> Can you describe the required properties expected from a "strong security
> layer"? (i.e. confidentiality, integrity protection, etc.)

I've added "(such as TLS with data confidentiality)". I hope this is clearer.

 [...]

> --3rd paragraph:
>
> I gather you are saying that there are techniques that mitigate the damage
> of a stolen authorization database, but the work group chose not to use
> them. Can you elaborate on the wg motivation for not doing so?

IPR claims on authentication mechanisms such as SRP.
Text commenting on IPR was removed as per Pasi's request.

> Nits/editorial comments:
>
> -- 1.1, 2nd bullet: Can you include an informational reference for RADIUS?

Added.

> -- 1.2, last bullet:
>
> What is the referent for "this"? Is there perhaps a missing word(s), or
> maybe this paragraph belongs with the previous bullet?

The latter. (This == Hi())

> -- 2, last paragraph:
>
> Do you plan for this paragraph to stay in the RFC? Is the work group mail
> list permanent enough to be published in the RFC?

Deleted.

> -- 5.1, definition of "c:", 2nd bullet: "(recall: a channel binding flag and
> an optional authzid.)
>
> I'm not sure I follow the sentence. Do you mean to say something like
> "Recall the G2 header contains a..."

Yes. Changed.

> -- IDNits reports the following:
>
>  == Outdated reference: A later version (-03) exists of
> draft-melnikov-sasl-scram-ldap-02

The two documents would be published simultaneously, so this will go away
during editing by the RFC Editor.

> It also reports a number of false errors about undefined references. I think
> it's confused by your non-standard reference sections, which I think make
> sense under the circumstances.

Right.

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

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

[Alexey Melnikov]

On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell  wrote:
 [...]
> Minor issues:
 [...]
> -- section 4, first paragraph: "...as long as this alternative name doesn’t
> conflict with any other hash function name from the IANA "Hash Function
> Textual Names" registry."
>
> What prevents future conflicts if someone registers a name that conflicts
> with the short name?

Good point.

> Should the short-names be IANA registered to prevent
> this?

This is a good idea. I've added:
  Such alternative name SHOULD be registered in the IANA
  "Hash Function Textual Names" registry.

> (Should future names be limited to 9 chars?)

I would rather not put extra restrictions on another registry due to
limitations on SASL mechanism names.

I would also note that the likelyhood of registering another SCRAM
mechanism name is quite low, and the likelyhood of the conflict
described above is even lower, so I wouldn't worry too much about this
case anyway.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10)

[Ahmad Muhanna]

Thank you Ben for reviewing and taking the time to go through the
document once more!
Agreed; Sorry, I missed that one.

I will make sure it is included in the next revision. I am sure you are
okay not to spin another revision unless this is the only outstanding
comment.

Thanks again!

Regards,
Ahmad
 

> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com] 
> Sent: Friday, October 02, 2009 2:47 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; 
> kchowdh...@starentnetworks.com; pyeg...@juniper.net; General 
> Area Review Team; IETF-Discussion list; Jari Arkko; 
> marc...@it.uc3m.es; Julien Laganier
> Subject: Followup on Gen-ART review of 
> draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and 
> Telechat Review of draft-ietf-mext-binding-revocation-10)
> 
> Hi,
> 
> This is a followup of my Gen-ART review of 
> draft-ietf-mext-binding- revocation, updated based on 
> revision 13 of that draft.
> 
> This revision addresses all of my substantive issues, and 
> most of the editorial issues. I had one outstanding minor 
> editorial comment where the author proposed a specific 
> change, but that change did not make it into revision 13 as 
> far as I can tell:
> 
> >>
> >> -- Section 11, (InitMINDelayBRIs) (I think I commented on 
> this, but 
> >> can't find the resolution)
> >>
> >> Did you intend for the _default_ to be a range (between .5 and 1 
> >> sec), or did you mean to say the default was 1 second, and it must 
> >> not be configured to less than .5 seconds? I suspect the 
> latter, but 
> >> it's not clear from the text.
> >
> > [Ahmad]
> > Sure, will fix this as follows:
> >
> >   Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)
> >
> >  This variable specifies the initial delay timeout in seconds
> >  before the revoking mobility entity retransmits a BRI message.
> >  The default is 1 second but not to be configured less than 0.5 
> > seconds.
> 
> Revision 13 still appears to have the old text.
> 
> 
> Thanks!
> 
> Ben.
> 
> 
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10)

[Ben Campbell]

Hi,

This is a followup of my Gen-ART review of draft-ietf-mext-binding- 
revocation, updated based on revision 13 of that draft.


This revision addresses all of my substantive issues, and most of the  
editorial issues. I had one outstanding minor editorial comment where  
the author proposed a specific change, but that change did not make it  
into revision 13 as far as I can tell:




-- Section 11, (InitMINDelayBRIs) (I think I commented on 
this, but can't find the resolution)


Did you intend for the _default_ to be a range (between .5
and 1 sec), or did you mean to say the default was 1 second,
and it must not be configured to less than .5 seconds? I
suspect the latter, but it's not clear from the text.


[Ahmad]
Sure, will fix this as follows:

  Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)

 This variable specifies the initial delay timeout in seconds
 before the revoking mobility entity retransmits a BRI message.
 The default is 1 second but not to be configured less than 0.5
seconds.


Revision 13 still appears to have the old text.


Thanks!

Ben.


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

Re: [Gen-art] Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10)

[Ben Campbell]

On Oct 2, 2009, at 3:25 PM, Ahmad Muhanna wrote:



Thank you Ben for reviewing and taking the time to go through the
document once more!
Agreed; Sorry, I missed that one.

I will make sure it is included in the next revision. I am sure you  
are

okay not to spin another revision unless this is the only outstanding
comment.


Yes, no problem. That one could be done as an editor note (or not at  
all, really--it's pretty minor.)




Thanks again!

Regards,
Ahmad



-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com]
Sent: Friday, October 02, 2009 2:47 PM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com;
kchowdh...@starentnetworks.com; pyeg...@juniper.net; General
Area Review Team; IETF-Discussion list; Jari Arkko;
marc...@it.uc3m.es; Julien Laganier
Subject: Followup on Gen-ART review of
draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and
Telechat Review of draft-ietf-mext-binding-revocation-10)

Hi,

This is a followup of my Gen-ART review of
draft-ietf-mext-binding- revocation, updated based on
revision 13 of that draft.

This revision addresses all of my substantive issues, and
most of the editorial issues. I had one outstanding minor
editorial comment where the author proposed a specific
change, but that change did not make it into revision 13 as
far as I can tell:



-- Section 11, (InitMINDelayBRIs) (I think I commented on 

this, but

can't find the resolution)

Did you intend for the _default_ to be a range (between .5 and 1
sec), or did you mean to say the default was 1 second, and it must
not be configured to less than .5 seconds? I suspect the

latter, but

it's not clear from the text.


[Ahmad]
Sure, will fix this as follows:

 Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)

This variable specifies the initial delay timeout in seconds
before the revoking mobility entity retransmits a BRI message.
The default is 1 second but not to be configured less than 0.5
seconds.


Revision 13 still appears to have the old text.


Thanks!

Ben.




___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


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

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

[Ben Campbell]

Hi Alexey,

Your responses in this and your other email address all of my comments.

Thanks!

Ben.


On Oct 2, 2009, at 12:31 PM, Alexey Melnikov wrote:

On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell   
wrote:

[...]

Minor issues:

[...]
-- section 4, first paragraph: "...as long as this alternative name  
doesn’t
conflict with any other hash function name from the IANA "Hash  
Function

Textual Names" registry."

What prevents future conflicts if someone registers a name that  
conflicts

with the short name?


Good point.


Should the short-names be IANA registered to prevent
this?


This is a good idea. I've added:
 Such alternative name SHOULD be registered in the IANA
 "Hash Function Textual Names" registry.


(Should future names be limited to 9 chars?)


I would rather not put extra restrictions on another registry due to
limitations on SASL mechanism names.

I would also note that the likelyhood of registering another SCRAM
mechanism name is quite low, and the likelyhood of the conflict
described above is even lower, so I wouldn't worry too much about this
case anyway.


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

Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard

[Sadler, Jonathan B.]

To the IETF area directors, MPLS and PWE3 working group chairs, document 
authors and IETF community,

I've recently started looking at the MPLS-TP drafts and only this past week 
have had an opportunity to review the OAM requirements draft for MPLS-TP.  I 
realize the IESG has requested Last Call comments for this draft, and am 
sensative that these comments would have been better received earlier.  That 
said, these comments are not trivial and should be considered before 
progressing the draft.

ITU-T SG15 has a history of OAM protocol development for transport 
technologies.  This expertise has led to development of an OAM methodology and 
definition approach as documented in G.806.  Two key characteristics exist in 
this document that I don't see being reflected in the OAM requirements draft:

- A requirement for consistancy in OAM approach with other transport technology 
layers.

This characteristic is necessary to enable existing transport network 
management systems to easily integrate new transport technologies.  It further 
enables existing Methods and Procedures to be easily adapted for new 
technologies.  Considering the familiarity that exists with existing transport 
OAM approaches, deviation should only be considered after receiving significant 
input from transport network operators.  Please be aware that transport network 
operators typically participate in the work of the ITU, not the IETF and 
therefore many are not aware of this work.

- A requirement for OAM interactions between transport technology layers.

This characteristic is key when a network utilizes multiple transport 
technology layers to carry customer traffic.  This is very common in Transport 
networks. G.806 provides a framework for this interaction.  An example 
embodiment  can be found in G.782 and its definition of OAM interactions 
between the RS and MS layers, as well as the MS and Path layers.  MPLS-TP is 
not an island of technology -- it runs over other transport layers (e.g. 
OTN/DWDM, Ethernet layers) and other transport layers are targeted to run on 
top of it (e.g. Ethernet over PseduoWire, SONET/SDH over PseudoWire).   The OAM 
mechanisms used in the layers found in Transport networks were developed with 
G.806 in mind.  Interactions between the OAM indications from lower layers and 
MPLS-TP as well as between MPLS-TP and higher layers must be handled as 
described in G.806 when considering the design for MPLS-TP OAM.

The work of IETF and ITU-T has endevored to meet many different requirements 
for MPLS-TP Networks.  Many good results have come from this process.  And the 
process allows for comments like these to be made to avoid key areas from being 
overlooked.  I appreciate the opportunity to provide them to the IETF community 
and IESG as the MPLS-TP OAM Requirements document is considered.

Thanks,

Jonathan Sadler

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

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

[Nicolas Williams]

On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote:
> On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell  wrote:
> > I'm no crypto expert, so please forgive me if this is silly--but isn't there
> > a movement to phase out sha-1? If so, should that be the default "must
> > implement" hash for a new mechanism?
> 
> My understanding is that use of SHA-1 under HMAC is still considered 
> reasonable.
> The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided
> to proceed with SHA-1, because it is more frequently implemented in libraries
> and hardware.

This matter has come up elsewhere, such as in the KRB-WG.  NIST has not
obsoleted the use of HMAC-SHA-1, though I don't have a reference handy
at the moment (but a quick search of the KRB-WG mailing list and, maybe,
the krb...@mit.edu list should yield one).

> > -- 1.2, last bullet:
> >
> > What is the referent for "this"? Is there perhaps a missing word(s), or
> > maybe this paragraph belongs with the previous bullet?
> 
> The latter. (This == Hi())

Incidentally, Hi() should be shown as taking the iteration count as an
argument.

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

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

[Nicolas Williams]

On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote:
> -- 2nd paragraph: " ...increase the iteration count over time."
> 
> Can  you elaborate on how this helps, and possibly offer guidance on  
> how implementations should use it?

Good point.  With SCRAM as specified, a server cannot increase the
iteration count without somehow getting access to the cleartext
password.  If the server were to store SaltedPassword _and_
U_iteration_count (from Hi()'s internals), then the server could compute
a new SaltedPassword and U_iteration_count with a higher iteration
count.  However, the server isn't intended to store SaltedPassword,
rather, the server stores StoredKey and ServerKey, and there's a reason
for this: a server that's never authenticated a given user before cannot
impersonate that user, but if the server were to store SaltedPassword,
then the server could impersonate the user.

Thus, to "increase the iteration count over time" requires, effectively,
changing the user's password.  This is probably worth pointing out.

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

Re: Gen-ART LC Review of draft-ietf-sasl-scram-07

[Nicolas Williams]

On Fri, Oct 02, 2009 at 01:17:26PM -0500, Nicolas Williams wrote:
> On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote:
> > On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell  wrote:
> > > I'm no crypto expert, so please forgive me if this is silly--but isn't 
> > > there
> > > a movement to phase out sha-1? If so, should that be the default "must
> > > implement" hash for a new mechanism?
> > 
> > My understanding is that use of SHA-1 under HMAC is still considered 
> > reasonable.
> > The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided
> > to proceed with SHA-1, because it is more frequently implemented in 
> > libraries
> > and hardware.
> 
> This matter has come up elsewhere, such as in the KRB-WG.  NIST has not
> obsoleted the use of HMAC-SHA-1, though I don't have a reference handy
> at the moment (but a quick search of the KRB-WG mailing list and, maybe,
> the krb...@mit.edu list should yield one).

http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

"After 2010, Federal agencies may use SHA-1 only for the following
applications: hash-based message authentication codes (HMACs); key
derivation functions (KDFs); and random number generators (RNGs).
Regardless of use, NIST encourages application and protocol designers to
use the SHA-2 family of hash functions for all new applications and
protocols."

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

RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

[Rui Costa]

SDH and EoSDH networks are widely used by Portugal Telecom Comunicacoes 
(PTC) and TMN (respectively the incumbent operator in Portugal and PT   
group's mobile operator), as well as foreign PT's clients (Brazilian "Vivo",
for instance). These operators are used to both SDH and Ethernet's OAM  
paradigm. We ask you therefore to consider that MPLS-TP OAM protocols MUST  
allow equivalent OAM mechanisms.

Being more precise, we would like to use the same protocol messages, to 
give/have   
the same "touch&feel" we had in SDH and for less time in ETH.   

In SDH...   
-it allows you at each end to check you have signal reception and notify the 
other end when you don't (RDI)  
-it does so at different levels (in SDH you can have it both for each VC and 
for the STM)
-it has a means by which to exchange an APS protocol

In ETH...   
-we've been using Y.1731 in EoSDH systems; it was the ITU standard developed 
for this purpose and was thought in the same principles stated for SDH; the 
most logical evolution would hence be to use the same PDUs and mechanisms as 
faithfully as possible with an adequate MPLS-TP encapsulation   
-MEF defined performance monitoring functions for frame loss measurement 
[FL], delay measurement, delay variation measurement, which are also addressed  
in Y.1731   

The main reason to use the same PDUs as in Y.1731 is probably the same i guess  
and respect in RFC5654 2nd general requirements: economy. We can't though 
forget this   
requirement list will have impact on ITU standards and that, although much of   
the work in MPLS-TP is IETF's merit and sweat, probably no one would need it if 
ITU 
didn't start T-MPLS (whose interoperability problems with MPLS/IP were 
afterwards   
pointed out by IETF and originated all the work we can see now).

I would also like to point out that the mechanisms in Y.1731 are sufficiently 
simple
to allow some "hardwarization", which would ease more vendor's implementations 
to   
converge to the 50ms protection timescale, allowing a way to do this in a 
cheaper,  
more scalable and miniaturized way. 

Thank You for your time. Best Regards,  
Rui Costa   

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

Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard

[Stewart Bryant]

Sadler, Jonathan B. wrote:
ITU-T SG15 has a history of OAM protocol development for transport 
technologies.  This expertise has led to development of an OAM 
methodology and definition approach as documented in G.806.

Jonathan

Unfortunately the latest version of G.806 is showing up as 
pre-published, only available for purchase at a cost of 64CHF, please 
can you make a copy of this available to the IETF so that we can review 
the relevant content in order to consider this as input to this last 
call process.


Regards

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

Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Cullen Jennings]

I have done a little digging around on the questions I asked and  
thought I might summarize some of the responses I got back to my email.


More inline  Note all the comments below do not refer to the  
"Special Administrative Regions". I strongly support Ted's suggestion  
that running the meeting in one of theses zones would eliminate the  
concerns I have raised.


On Sep 23, 2009, at 9:45 PM, Cullen Jennings (fluffy) wrote:



IAOC,

I'm trying to understand what is political speech in China. The
Geopriv WG deals with protecting users' location privacy. The policies
of more than one country have come up in geopriv meetings in very
derogatory terms. There have been very derogatory comments made by
people about the US's wiretap policy. Unless someone can point me at
specifics of what is or is not OK, I would find this very concerning.
We also regularly discuss issues around Taiwan/China, cryptography,
wiretap, DNS root server location, reverse engineering, and so on.
Clearly most the people involved with IETF would never want to break
the laws of the country they are visiting but the question is do we
actually understand the laws and what impact do they have on our
technical work? To help us make informed decision about whether these
terms are issues or not:

1) What is political speech in China? And can we explain that to IETF
participants well enough that they know what is OK and what is not.



Got a few reposes to this - none very solid but they seemed generally  
along the lines of "If you are looking for something crisp, forget it"


2) Are there any special rules about publishing and broadcasting? I
note that the IETF, unlike most other groups having meetings,
broadcasts the meetings live over the internet, which will be both
publishing the material and exporting it outside of the PRC.



Got answer from non legal person of yes you need a license for this  
but they could not point me to the actually regulations. Still hoping  
to get a better answer. Hs the IAOC got legal advice on this?




3) Are there any rules around discussion, publication, or export of of
cryptography algorithms and technology? publishing weaknesses of
national crypto algorithms?



The advice I got was that unless we got a license if the IETF  
developed crypto in China and we exported it out, then this would be  
illegal in PRC. It was pointed out PRC is not part of  Wassenaar  
Arrangement. I was advised our broadcasts of and export of minutes  
from meetings would be "Deemed Export". It seems pretty hard to argue  
that the IETF does not develop any crypto.  Has the IAOC received any  
legal advice on this?


4) Many of our participants use communications products (like jabber
clients) that they helped develop and include strong cryptography. Do
they need permission to use these in China?



One person with what I view as a reasonable background in PRC law told  
me this would be illegal and violate State Council Order No. 273,  
"Commercial Use Password Management Regulations" among other things.  
The "clarification letter" does not seem to change this. It seems this  
would be illegal there without a license. Has the IAOC received legal  
advice on how this  impacts us.





5) When discussing what I think of as technical issues, many
participants regularly treat Taiwan and PRC as two different countries
and currently recognize both of them as separate countries in their
own right. I'd actually venture a guess that there is strong IETF
consensus they should be treated this way.  Could any discussions like
this be viewed as political speech? What are the rules on this?

Still gathering data on this one. If you know something, let me know.  
I heard a rumor that on our registration form, when we asked what  
country you are from, we would not be allowed to ask Taiwan or PRC.  
Does anyone know any truth value to this rumor?




6) It is not core to IETF work but some of us do some interop of
running code for IETF protocols under development sometimes at IETF.
This would be about the right timing for running P2PSIP code, but that
requires us to to run a local CA. Is any special permission needed to
run a CA in China?



A license is needed to run a CA in PRC. What we normally do would be  
illegal there.




7) Would we be OK running a BOF on techniques for firewall advancement
in general and in particular on getting around any firewalls China
runs? [Seriously, you know someone will propose this BOF, the
questions is could we run it or not?]



Answer I got was discussion of security policies of PRC's firewall and  
methods to get around it would definitely not be OK to discuss. Two of  
the many problems would be:


1) this is defamatory towards the state agency that run the firewalls
2) this could be considered release of state secrets

Answer seemed pretty solid that this topic was not one that most  
people would consider a really bad idea to discuss in PRC.




8) Given the Chairs for WG set the agendas and 

Re: [IAOC] Request for community guidance on issue concerning afuture meeting of the IETF

[Cullen Jennings]

On Sep 24, 2009, at 9:43 AM, Ole Jacobsen (ole) wrote:



>
> Does your above response mean that the host would not consider
> slides and oral presentations made during working group sessions to
> be part of "the Group's activities, visual or audio presentations at
> the conference"? Or does your response mean that the host is going
> to take the risk of having the event terminated for reasons having
> to do with slide or presentation content that was not pre-approved
> by the government? Or does it mean that you do not think that the
> content of working group sessions falls under the category of
> "topics regarding human rights"?
>
> Thanks much.
> Alissa
>


Dear IAOC,

The questions from the chair of Geopriv WG which is the WG in RAI most  
likely to have problems meeting in China are fairly relevant in  
determining if we can run a "business as usual" meeting in China. I  
would greatly appreciate the IAOC reposing to them so we can plan  
appropriately.


Thank you,
Cullen 


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

Re: Request for community guidance on issue concerning afuture meeting of the IETF

[Cullen Jennings]

+1 to Adrian's suggestion. I'd love to hear from people who live in  
the PRC about any of the legal questions I have raised. Using specific  
previous IETF discussions seems a fine way to look at it in a very  
concrete way.


So far I have heard in private from more than one person that is not  
willing to comment publicly. Roughly what I have been hearing is "yes  
it is illegal, no you won't be arrested for it." If that is the  
answer, I can certainly understand why no one wants to put it out on a  
public list.



On Sep 20, 2009, at 12:51 PM, Adrian Farrel wrote:


On Sep 20, 2009, at 12:37 PM, Michael StJohns wrote:

I'd be happy to have a WG meeting in the PRC - on topics other  
than  those common to the security area, but I remain concerned  
about  prior restraint for the IETF as a whole as a price of  
holding a  meeting there.


I wonder if we could ask. Is that too simple?

We have plenty of minutes of previous meetings, slidesets, and I-Ds/ 
RFCs. We even have audio recordings.


There have been loads of Chinese nationals at the meetings who could  
comment.


Can we find out in advance whether the material is even close to  
being an issue to the Chinese government?


My guess is that it would not be and that clearing the air in this  
way would be welcomed.


Thanks,
Adrian
___
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: [IAOC] Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Ole Jacobsen]

Cullen,

I will only answer #5 here, since I am not a lawyer (the rest will 
have to wait for now):

Most organizations, including the IETF, asks for ISO-3166 codes on the 
registration form. Not all those codes are necessarily "countries" by 
some other countries' definition, or even by the definition in that 
document. We are certainly allowed to ask "where are you from" and we 
even have a "other" field in case the pull-down is incomplete.

This particular concern is not an issue. Public demonstrations 
regarding the underlying issues might be.

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



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

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Dave CROCKER]

Cullen Jennings wrote:


I have done a little digging around on the questions I asked and thought 
I might summarize some of the responses I got back to my email.


More inline  Note all the comments below do not refer to the 
"Special Administrative Regions". I strongly support Ted's suggestion 
that running the meeting in one of theses zones would eliminate the 
concerns I have raised.



Cullen,

At its base, your exercise seems to be an effort at doing the IAOC's job for it. 
 It's their job to research venue details and make choices and to ensure the 
logistics for productive IETF meetings.  The IETF as a body is not likely to 
become experts in the details of holding a meeting in China.  Nor is it our job to.


The IAOC came to us with a very specific question.  To the extent we pursue 
other questions, we dilute the help we can give them to resolve this one, 
difficult issue that they've asked us about.  By virtue of the public ruckus a 
debate on the IETF list can cause, it also could de-stabilize the considerable 
10-year effort that has been put in, to get arrangements to their current point.


It's not that suggesting paths for resolving the issue they raised is 
unproductive or inappropriate.  It's that pursuing ancillary details, paths and 
issues is.


The suggestion to have the meeting in a China SAR has already been made. 
Whether it can pragmatically resolve the issue we've been asked about is 
something the IAOC can juggle best.


If the goal of your effort is to review and change IAOC responsibilities or 
procedures for site selection and event management, then that ought to be 
pursued independently of the China meeting discussion.


d/

--

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

Re: [IAOC] Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Ole Jacobsen]

And just to be 100% clear: Holding the meeting in Hong Kong is not an 
option for the current discussion. There is neither a host nor a venue 
available there for the time period in question. It is entirely 
possible, I will even go so far as to say "probable," that we indeed 
WILL meet in Hong Kong some day, but that isn't what the current 
discussion is about.

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



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

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[John C Klensin]

--On Monday, October 05, 2009 10:45 -0700 Dave CROCKER
 wrote:

> Cullen Jennings wrote:
>> 
>> I have done a little digging around on the questions I asked
>> and thought  I might summarize some of the responses I got
>> back to my email.
>> 
>> More inline  Note all the comments below do not refer to
>> the  "Special Administrative Regions". I strongly support
>> Ted's suggestion  that running the meeting in one of theses
>> zones would eliminate the  concerns I have raised.
> 
> 
> Cullen,
> 
> At its base, your exercise seems to be an effort at doing the
> IAOC's job for it.   It's their job to research venue details
> and make choices and to ensure the logistics for productive
> IETF meetings.  The IETF as a body is not likely to become
> experts in the details of holding a meeting in China.  Nor is
> it our job to.
> 
> The IAOC came to us with a very specific question.  To the
> extent we pursue other questions, we dilute the help we can
> give them to resolve this one, difficult issue that they've
> asked us about.  By virtue of the public ruckus a debate on
> the IETF list can cause, it also could de-stabilize the
> considerable 10-year effort that has been put in, to get
> arrangements to their current point.
>...

Dave, I disagree, at least slightly, but that is because I
suffer from a concern --documented in a "request for review" and
previous notes to this list-- that the IAOC/Trustees are _not_
doing their job, or at least the part of that job that requires
keeping the community informed about the decisions they are
making and the reasons for them.

In Cullen's situation, I would have asked the questions a little
differently.  And I agree that he is trying to do their job for
them, but, other than more "requests for review" that get
responses that amount to "things are Under Control and Just
Fine", I don't know what else I would suggest that he do... and
wonder what you would suggest.

Suppose he posted a list of questions to which he thought we
should have answers before we put a meeting in any location that
has a reputation (justified or not) for regulating the free flow
of information, asked whether the IAOC had answers to those
questions for a particular case, and, if they did, that they
share those answers with the community?  I think that would be
reasonable and that the IAOC could reasonably respond to such a
question by saying "yes, similar questions were asked, we think
the answers are reasonable, and the discussion is documented in
the IAOC Minutes of ...".   Except that he did ask, hasn't
gotten an answer like that and, by the way, there are no minutes
of enough substance to be pointed to on that (or any other)
issue.

What is to be done?

john

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

Re: Update on IETF 76 ANA Hotel Availability

[Ben Campbell]

Hi Alexa,

How should one go about expressing to the hotel that they preferred  
non-smoking but were unable to get it? I assume they need some lead  
time for this, so mentioning it at arrival time might be too late.


Thanks!

Ben.

On Oct 1, 2009, at 5:15 PM, Alexa Morris wrote:

There are still a limited number of rooms available at the ANA Hotel  
(the IETF 76 venue) from November 5 through November 15th. We  
anticipate that these rooms will be sold out in the next couple of  
days. so please book now if you want one.


Currently non-smoking rooms are available only on the block shoulder  
dates -- November 5-7 and 12-15. However, all smoking rooms will be  
ozone-deodorized prior to occupation by any IETF attendee who wanted  
a non-smoking room but was unable to secure one.  The ozone  
deodorization process is considered one of the more effective odor  
removal methods. In addition, all sleeping rooms at the ANA have  
windows that do open several inches, allowing for fresh air.


We are waiting to hear more about the availability of non smoking  
rooms at the overflow properties and hope to have an update for you  
shortly.


37 days until IETF 76!

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


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

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Cullen Jennings]

On Oct 5, 2009, at 11:53 AM, John C Klensin wrote:


Cullen,

For purposes of discussion, one comment below and one addition
to your list...

--On Monday, October 05, 2009 11:07 -0600 Cullen Jennings
 wrote:

> I have done a little digging around on the questions I asked
> and thought I might summarize some of the responses I got back
> to my email.

>...
>> 3) Are there any rules around discussion, publication, or
>> export of of cryptography algorithms and technology?
>> publishing weaknesses of national crypto algorithms?
>>
>
> The advice I got was that unless we got a license if the IETF
> developed crypto in China and we exported it out, then this
> would be illegal in PRC. It was pointed out PRC is not part of
> Wassenaar Arrangement. I was advised our broadcasts of and
> export of minutes from meetings would be "Deemed Export". It
> seems pretty hard to argue that the IETF does not develop any
> crypto.  Has the IAOC received any legal advice on this?

Another piece of this question is whether PGP (or CACert)
key-signing activities, with signed private keys being taken out
of the country afterwards, would violate any law or require a
license.  I had previously assumed that the answer would be
"no", but the answers you have given to this question, the
P2PSIP/CA one, and maybe others, leads me to wonder a bit.



The PGP Key signing is a good question - I have no idea - it's  
certainly something we have done in the past but if it is not legal in  
the PRC, I could live with a meeting where we did not do any PGP key  
signing. It detracts a bit from the meeting but is not in what I  
consider the mediatory must have core of the meeting. Of course this  
would mean that a group of people that did not often travel out of the  
PRC would be missing a great opportunity to sign with a group of  
people outside of China which I view as one of the benefits of having  
a meeting in Beijing.


>> 7) Would we be OK running a BOF on techniques for firewall
>> advancement in general and in particular on getting around
>> any firewalls China runs? [Seriously, you know someone will
>> propose this BOF, the questions is could we run it or not?]
>
> Answer I got was discussion of security policies of PRC's
> firewall and methods to get around it would definitely not be
> OK to discuss. Two of the many problems would be:
>
> 1) this is defamatory towards the state agency that run the
> firewalls
> 2) this could be considered release of state secrets
>
> Answer seemed pretty solid that this topic was not one that
> most people would consider a really bad idea to discuss in PRC.

Too many negatives in that sentence for me to parse.  Did you
mean "was one that ...bad idea to discuss" or "ok to discuss"?



Oops - sorry. I meant to try and say, that most the people I had  
talked to advised me *not* to have any such discussion in PRC.


>> 10) If the meeting is canceled, will the IETF be reimbursing
>> the registration fees?

That question may have an answer under US or European law (and
probably other places): if someone paid the registration fee for
a meeting, and paid for non-refundable airline tickets, hotel
room, etc., on the basis of a good-faith assumption that the
meeting would be held, would he or she have the right to a
reasonable expectation of recovering those costs if the meeting
were called off?  Called off on any basis other than what I
believe some lawyers call an Act of God?  If the IAOC has gotten
legal advice on this --from the IAOC's point of view, IASA's
liability to participants if a meeting were cancelled-- could
that advice be shared.

> As an interesting side note, it seems that some people think
> that many of these things are officially illegal but they are
> fine to do anyway because other meetings are doing them etc.
> This is not a position I share and more importantly, it is not
> a position where I am willing to ask our WG Chairs, authors,
> and other volunteers to do something illegal because it will
> all be fine. Even if there are no short term consequences, I
> can imagine a case where 10 years later someone is seeking
> security clearance and this comes back to bite them.

Concur

For the record, I'm still generally in favor of a meeting in
Beijing.  But I agree with Cullen that answers to these types of
questions should be extremely clear before a decision to go is
made and that, if any of the answers are sub-optimal, that the
IESG should make a formal decision, after reviewing community
input, etc., as to whether they believe that a satisfactory
meeting can be held in spite of them.  And I believe we should
hold any potential meeting site to those standards, i.e., that
this is not about the PRC.



+1, and speaking of other countries, I also thing it is a very  
reasonable requirement that "most of the participants can get a visa  
in a reasonable time". Not sure what the values of most and reasonable  
time are but I would say something like we only meet in countries  
where 95% 

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Dave CROCKER]

John C Klensin wrote:
Dave, I disagree, at least slightly, 


The last paragraph of my note covered agendas like yours:

   "If the goal of your effort is to review and change IAOC responsibilities or 
procedures for site selection and event management, then that ought to be 
pursued independently of the China meeting discussion."




What is to be done?


Respect the goal of the original query.

If you have a different goal, persue it separately.

d/
--

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

Re: [IAB] Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[John C Klensin]

--On Monday, October 05, 2009 12:30 -0600 Cullen Jennings
 wrote:

>...

>> Another piece of this question is whether PGP (or CACert)
>> key-signing activities, with signed private keys being taken
>> out of the country afterwards, would violate any law or
>> require a license.  I had previously assumed that the answer
>> would be "no", but the answers you have given to this
>> question, the P2PSIP/CA one, and maybe others, leads me to
>> wonder a bit.
> 
> The PGP Key signing is a good question - I have no idea - it's
> certainly something we have done in the past but if it is not
> legal in the PRC, I could live with a meeting where we did not
> do any PGP key signing. It detracts a bit from the meeting but
> is not in what I consider the mediatory must have core of the
> meeting. Of course this would mean that a group of people that
> did not often travel out of the PRC would be missing a great
> opportunity to sign with a group of people outside of China
> which I view as one of the benefits of having a meeting in
> Beijing.

I am suggesting only that this is another question --perhaps on
a par with some of your other ones and perhaps not-- where we
need to know the answer for planning purposes.  We might not
need to know the answer in order to decide whether to hold a
meeting or not, but would certainly want to know before we
started scheduling.   In principle, I believe that, if there are
other strong reasons for holding a meeting in a particular
place, we might be able to live without holding meetings of one
or two WGs (e.g., by forcing them into interim meetings at some
other time and place), so the issues are not all that different.

>...
>> > Answer seemed pretty solid that this topic was not one that
>> > most people would consider a really bad idea to discuss in
>> > PRC.
>> 
>> Too many negatives in that sentence for me to parse.  Did you
>> mean "was one that ...bad idea to discuss" or "ok to discuss"?
> 
> Oops - sorry. I meant to try and say, that most the people I
> had talked to advised me *not* to have any such discussion in
> PRC.

Ack.  Thanks.  Again, just wanted to understand what you were
reporting.

>...
>> For the record, I'm still generally in favor of a meeting in
>> Beijing.  But I agree with Cullen that answers to these types
>> of questions should be extremely clear before a decision to
>> go is made and that, if any of the answers are sub-optimal,
>> that the IESG should make a formal decision, after reviewing
>> community input, etc., as to whether they believe that a
>> satisfactory meeting can be held in spite of them.  And I
>> believe we should hold any potential meeting site to those
>> standards, i.e., that this is not about the PRC.
> 
> +1, and speaking of other countries, I also thing it is a very
> reasonable requirement that "most of the participants can get
> a visa in a reasonable time". Not sure what the values of most
> and reasonable time are but I would say something like we only
> meet in countries where 95% of the participants can get a visa
> in under 4 months.

FWIW, I believe the PRC meets that requirement.  It is not clear
that the US would if it were not the case that a significant
fraction of our participants are either US citizens, US
permanent residents, or qualify for some sort of visa waiver
program.  If you looked only at how long it takes for someone
who needs a visa to get one, I believe the answer for China
would be well over 95% in under four months and that that answer
for the US would be, at best, unclear.

   john

> 
>> 
>>john
>> 
>> 
>> 
> 




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

Re: [IAOC] Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Theodore Tso]

On Mon, Oct 05, 2009 at 10:42:44AM -0700, Ole Jacobsen wrote:
> 
> I will only answer #5 here, since I am not a lawyer (the rest will 
> have to wait for now):

I would hope the IAOC would see fit get formal legal advice on the
various issues which Cullen has raised before green-lighting an IETF
meeting in the PRC.  (Especially since his further research seems to
show that they are indeed may be some real problems!)  Is that a
reasonable expectation?

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

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Cullen Jennings]

On Oct 5, 2009, at 11:45 AM, Dave CROCKER wrote:



At its base, your exercise seems to be an effort at doing the IAOC's  
job for it.
  It's their job to research venue details and make choices and to  
ensure the
logistics for productive IETF meetings.  The IETF as a body is not  
likely to

become experts in the details of holding a meeting in China.


Well it sounds like we both agree that it is the IAOC job to make sure  
they have answers to the questions I am raising before making a  
decision.


I asked about legalities of discussing crypto a few years ago when  
this China meeting was raised to IESG. I did not get an answer. I  
asked about it around the time of the Stockholm meeting and got no  
answer. I am asking publicly on the IETF list when the topic finally  
got brought to a public list. I think it is a reasonable question.


I'm not asking about if someone stands up at a plenary and asked some  
questions that is totally tangental to the IETF. I am asking about the  
legality of discussions we regularly have to produce the type of  
things that we have put in RFCs. If the IAOC was telling me, "yep, we  
contacted these lawyers in PRC and here is what they told us, we think  
we can run a normal IETF discussion in PRC" then I'd feel like they  
looked at this and it is all fine. I do understand the IAOC is a  
thankless job where arm chair experts complain about everything you do  
on the IETF list. (I'm sort of familiar with a job that is similar to  
that).



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

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Dave CROCKER]

Cullen Jennings wrote:

Well it sounds like we both agree that it is the IAOC job to make sure they
have answers to the questions I am raising before making a decision.


We are seeing a solid pattern to suggest that U.S. reading skills have declined 
seriously.


I neither expressed nor implied any opinion at all about your questions, except 
that they are out of scope for the query being made by the IAOC and that any 
pursuit of your questions ought to be done *separately*.


d/
--

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

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Cullen Jennings]

On Oct 5, 2009, at 1:28 PM, Dave CROCKER wrote:



Cullen Jennings wrote:
> Well it sounds like we both agree that it is the IAOC job to make  
sure they

> have answers to the questions I am raising before making a decision.

We are seeing a solid pattern to suggest that U.S. reading skills  
have declined

seriously.


Sorry but I'm Canadian, Eh, so don't blame the US. Besides, as Spencer  
correctly points out, my writing is worse than many ESL people.




I neither expressed nor implied any opinion at all about your  
questions, except
that they are out of scope for the query being made by the IAOC and  
that any

pursuit of your questions ought to be done *separately*.


By "separately" you mean doing something like changing the subject  
line? But on to the serious answer 


As an IESG member, I was aware the IAOC was considering a meeting in  
China before the IAOC announced it on a public list. I felt that I  
should not discuss it as an individual contributor on a a public list  
until the IAOC made the topic public. To my knowledge this query from  
the IAOC was the first time it had been made public so I brought up  
the issues at the first point in time available. I'm not sure what  
else you would have suggested I do to ask for information that I think  
is important.


The question from the IAOC, as far as I can read it, asks if we are OK  
with having the meeting be canceled for everyone if one person discuss  
various under specified things that includes topics that are illegal  
in China. It seems to me the questions of if our normal discussions  
are illegal or not is very relevant to making that decision.




d/


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

The IETF and the SmartGrid

[Richard Shockey]

The general internet community needs to be aware of activities in North
America that directly relate to the use of IETF protocols in the Electric
Utility industry. This activity is generally referred to as the SmartGrid.
Though the issues immediately deal with technical and policy decisions in
the US and Canada, the SmartGrid concept is gaining significant momentum in
Europe and Asia as well.

http://www.smartgrids.eu/

http://en.wikipedia.org/wiki/Smart_grid#Countries


The SmartGrid has many definitions but as a practical matter it is a
substantial re-architecture of the data communications networks that
utilities use to maintain the stability and reliability of their power
grids. Many of the requirements for the SmartGrid in North America came out
of the 2003 North East power outage which demonstrated a substantial lack of
investment in Utility IT systems.

http://www.ferc.gov/EventCalendar/Files/20040915141105-blackout.pdf

Of particular note, is the desire by utilities to extend the reach of their
communications networks directly to the utility meter and beyond ultimately
into the customer premise itself. This is generally referred to as the
Advanced Meter Interface (AMI).  One of the use cases driving this
requirement is the next generation of plug-in hybrid electric vehicles. The
utilities, correctly IMHO, want to precisely control the timing of how these
vehicles are recharged so not to create a unique form of DOS attack and take
out the grid when everyone goes home at night.  This is a principal use case
in 6lowpan ( ID below ). Increasingly energy flows are becoming
bi-directional creating needs for more computational intelligence and
capability at the edge.  

What is going on? Why should the IETF community care?

The United States Government, as part of the Energy Independence and
Security Act of 2007 gave the National Institute of Standards and Technology
( NIST ) principal responsibility "to coordinate development of a framework
that includes protocols and model standards" for the SmartGrid.

http://www.nist.gov/smartgrid/


After several meetings sponsored by NIST in recent months, NIST released a
preliminary report. Several folks from the IETF community attended those
meetings, myself included. There multiple troubling stories about how those
meetings were organized but I'll leave those tales to others. 

http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf

One of the requests from NIST and the SmartGrid community was a list of Core
Internet protocols that NIST could refer to.  Fred Baker has been working on
that task. ( below )  

Myself and others are deeply concerned by how this effort is developing.
There is no current consensus on what the communications architecture of the
SmartGrid is or how IP actually fits into it.

The Utility Industry does not understand the current IPv4 number exhaust
problem and the consequences of that if they want to put a IP address on
every Utility Meter in North America. 

What is equally troubling is that many of the underlying protocols that
utilities wish to deploy are not engineered for IPv6. We have an example of
that in a recent ID.

http://tools.ietf.org/html/draft-c1222-transport-over-ip-01.txt


Obviously, there are significant CyberSecurity issues in the SmartGrid
concept and NIST has produced a useful document outlining the requirements
and usecases.

http://csrc.nist.gov/publications/drafts/nistir-7628/draft-nistir-7628.pdf

How the SmartGrid interfaces with or bridges with Home Area or Enterprise
Local Area networks is unclear, to put it mildly. 

I want to use this message to encourage the community to read the attached
documents and get involved in this effort as appropriate.  Additional NIST
documents will be published shortly with a open public comment period. 

I strongly urge members of the IETF community to participate in this comment
period and lend its expertise as necessary. 

It's useful and important work. 




Title  : Core Protocols in the Internet Protocol Suite
Author(s)   : F. Baker
Filename: draft-baker-ietf-core-03.txt
Pages   : 32
Date: 2009-10-03

This note attempts to identify the core of the Internet Protocol Suite.  The
target audience is NIST, in the Smart Grid discussion, as they have
requested guidance on how to profile the Internet Protocol Suite.  In
general, that would mean selecting what they need from the picture presented
here.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-baker-ietf-core-03.txt




Title  : Design and Application Spaces for 6LoWPANs
Author(s)   : E. Kim, et al.
Filename: draft-ietf-6lowpan-usecases-04.txt
Pages   : 30
Date: 2009-10-01

This document investigates potential application scenarios and use cases for
low-power wireless personal area networks (LoWPANs).  This document provides
dim

Re: The IETF and the SmartGrid

[Fred Baker]

Thanks. You already know this, as does Russ Housley, but I'll say it  
out loud for others to hear.


At the third NIST workshop on the Smart Grid, which was the week  
following the IETF meeting, several IETFers were invited by David Su  
of NIST to a workshop on the role of the Internet Architecture in the  
Smart Grid. He specifically asked for a document that could be used to  
discuss and describe the Internet Architecture, specifically to  
support the "profiling" (eg, subseting) of its architecture for the  
purpose. To that end, I started


http://tools.ietf.org/html/draft-baker-ietf-core
  "Core Protocols in the Internet Protocol Suite", Fred Baker, 3- 
Oct-09,

  

The initial document essentially described the protocols appropriate  
to a host; at the request and behest of several commentators, I have  
since added a brief description of unicast and multicast routing, QoS,  
address allocation and assignment (DHCP and ND), NTP, DNSSEC, SIP, the  
ISO Transport Service Interfaces (necessary for ACSE, which is used in  
the Smart Grid) and something of the business architecture of the  
Internet and therefore firewalls, NATs, and VPNs. I have in the can a  
version that puts in references for MPLS, and given that NIST is  
asking about calendaring and SNMP will likely include a few sentences  
on those.


I'm trying to walk what is at best a grey line; The things that are at  
the Internet Architecture's absolute core, at least to my mind, are  
described in RFCs 1122, 1123, and 1812. However, NIST is asking about  
the place of more things (like calendaring and timekeeping) and other  
possible users of the document are also asking for things that are  
more core to the business than the architecture, like NATs and MPLS.  
So I am trying to describe things that are core, and also answer  
useful questions about less-core things, all without trying to provide  
a list of all 1574 proposed standards, 89 draft standards, and 82  
standards.


Individuals who have noticed the draft have commented; folks who care  
should also do so. I have asked the IESG for directorate reviews, but  
have not gotten anything from any directorates.


As you say, NIST is requesting commentary on http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf 
. Those of us that work for US corporations or educational  
institutions would likely be wise to be involved in corporate reviews  
and replies, as that is how most review of this type comes back. The  
exact structure to reply in has not yet been announced, but I would  
imagine that will be remedied soon.


On Oct 5, 2009, at 2:20 PM, Richard Shockey wrote:



The general internet community needs to be aware of activities in  
North
America that directly relate to the use of IETF protocols in the  
Electric
Utility industry. This activity is generally referred to as the  
SmartGrid.
Though the issues immediately deal with technical and policy  
decisions in
the US and Canada, the SmartGrid concept is gaining significant  
momentum in

Europe and Asia as well.

http://www.smartgrids.eu/

http://en.wikipedia.org/wiki/Smart_grid#Countries


The SmartGrid has many definitions but as a practical matter it is a
substantial re-architecture of the data communications networks that
utilities use to maintain the stability and reliability of their power
grids. Many of the requirements for the SmartGrid in North America  
came out
of the 2003 North East power outage which demonstrated a substantial  
lack of

investment in Utility IT systems.

http://www.ferc.gov/EventCalendar/Files/20040915141105-blackout.pdf

Of particular note, is the desire by utilities to extend the reach  
of their
communications networks directly to the utility meter and beyond  
ultimately

into the customer premise itself. This is generally referred to as the
Advanced Meter Interface (AMI).  One of the use cases driving this
requirement is the next generation of plug-in hybrid electric  
vehicles. The
utilities, correctly IMHO, want to precisely control the timing of  
how these
vehicles are recharged so not to create a unique form of DOS attack  
and take
out the grid when everyone goes home at night.  This is a principal  
use case

in 6lowpan ( ID below ). Increasingly energy flows are becoming
bi-directional creating needs for more computational intelligence and
capability at the edge.

What is going on? Why should the IETF community care?

The United States Government, as part of the Energy Independence and
Security Act of 2007 gave the National Institute of Standards and  
Technology
( NIST ) principal responsibility "to coordinate development of a  
framework

that includes protocols and model standards" for the SmartGrid.

http://www.nist.gov/smartgrid/


After several meetings sponsored by NIST in recent months, NIST  
released a
preliminary report. Several folks from the IETF community attended  
those
meetings, myself included. There multiple troubling stories about  
how th

Re: The IETF and the SmartGrid

[Michael Dillon]

> Myself and others are deeply concerned by how this effort is developing.
> There is no current consensus on what the communications architecture of the
> SmartGrid is or how IP actually fits into it.
>
> The Utility Industry does not understand the current IPv4 number exhaust
> problem and the consequences of that if they want to put a IP address on
> every Utility Meter in North America.
>
> What is equally troubling is that many of the underlying protocols that
> utilities wish to deploy are not engineered for IPv6. We have an example of
> that in a recent ID.

I've asked the ARIN Public Policy mailing list how people would feel about
banning the Electric Utility industry (and sub contractors) from receiving
any IPv4 addresses for use on the Smart Grid. This would include direct
ARIN allocations and assignment from ISPs.

I think that you are right to raise this issue in discussion since we badly
need to shine a light on the details of transitioning the Internet to IPv6.

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

RE: The IETF and the SmartGrid

[Richard Shockey]

It will certainly get their attention ... :-) 

>  -Original Message-
>  From: Michael Dillon [mailto:wavetos...@googlemail.com]
>  Sent: Monday, October 05, 2009 5:54 PM
>  To: Richard Shockey
>  Cc: ietf@ietf.org
>  Subject: Re: The IETF and the SmartGrid
>  
>  > Myself and others are deeply concerned by how this effort is
>  developing.
>  > There is no current consensus on what the communications
>  architecture of the
>  > SmartGrid is or how IP actually fits into it.
>  >
>  > The Utility Industry does not understand the current IPv4 number
>  exhaust
>  > problem and the consequences of that if they want to put a IP
>  address on
>  > every Utility Meter in North America.
>  >
>  > What is equally troubling is that many of the underlying protocols
>  that
>  > utilities wish to deploy are not engineered for IPv6. We have an
>  example of
>  > that in a recent ID.
>  
>  I've asked the ARIN Public Policy mailing list how people would feel
>  about
>  banning the Electric Utility industry (and sub contractors) from
>  receiving
>  any IPv4 addresses for use on the Smart Grid. This would include
>  direct
>  ARIN allocations and assignment from ISPs.
>  
>  I think that you are right to raise this issue in discussion since we
>  badly
>  need to shine a light on the details of transitioning the Internet to
>  IPv6.
>  
>  --Michael Dillon

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

Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Jeffrey Hutzelman]

On Mon, 5 Oct 2009, Cullen Jennings wrote:


On Oct 5, 2009, at 11:45 AM, Dave CROCKER wrote:



At its base, your exercise seems to be an effort at doing the IAOC's job 
for it.
 It's their job to research venue details and make choices and to ensure 
the
logistics for productive IETF meetings.  The IETF as a body is not likely 
to

become experts in the details of holding a meeting in China.


Well it sounds like we both agree that it is the IAOC job to make sure they 
have answers to the questions I am raising before making a decision.


I asked about legalities of discussing crypto a few years ago when this China 
meeting was raised to IESG. I did not get an answer. I asked about it around 
the time of the Stockholm meeting and got no answer. I am asking publicly on 
the IETF list when the topic finally got brought to a public list. I think it 
is a reasonable question.



So do I.  While it is certainly the IAOC's job to reserach possible venues 
and select a meeting location, many of us have jobs which require knowing 
the answers to some of the questions you've raised.  For example...


I co-chair a working group which is responsible for a cryptographic
authentication protocol.  If it is not legal to discuss and develop
cryptographic algorithms and protocols in the PRC, or to export the
results of such work, then my working group cannot usefully meet there,
regardless of what the IAOC decides about the IETF as a whole being
able to meet.

I also normally organize PGP key-signing sessions at IETF meetings.
If the operation of a CA or other cryptographic signing service requires a 
license in the PRC, then we may not be able to hold such a session, or it 
may require a special license.


I consider it entirely appropriate for me in my role as a working group 
chair, or Cullen in his role as an AD, to ask that the IAOC obtain answers 
to these questions from competent experts, such as legal counsel familiar 
with PRC law.



Finally, I would note that I am all for appointing people to positions of 
responsibility, putting appropriate checks and appeal and recall 
mechanisms in place, and them letting them go about doing their jobs. 
However, in this instance, the IAOC _asked_ for community input, so it 
seems silly to object to someone providing such input on the grounds that 
they are "doing the IAOC's job for it".


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

Re: [IAOC] Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF

[Marshall Eubanks]

On Oct 5, 2009, at 7:03 PM, Jeffrey Hutzelman wrote:


On Mon, 5 Oct 2009, Cullen Jennings wrote:


On Oct 5, 2009, at 11:45 AM, Dave CROCKER wrote:

At its base, your exercise seems to be an effort at doing the  
IAOC's job for it.
It's their job to research venue details and make choices and to  
ensure the
logistics for productive IETF meetings.  The IETF as a body is not  
likely to

become experts in the details of holding a meeting in China.


Well it sounds like we both agree that it is the IAOC job to make  
sure they have answers to the questions I am raising before making  
a decision.


I asked about legalities of discussing crypto a few years ago when  
this China meeting was raised to IESG. I did not get an answer. I  
asked about it around the time of the Stockholm meeting and got no  
answer. I am asking publicly on the IETF list when the topic  
finally got brought to a public list. I think it is a reasonable  
question.



So do I.  While it is certainly the IAOC's job to reserach possible  
venues and select a meeting location, many of us have jobs which  
require knowing the answers to some of the questions you've raised.   
For example...


I co-chair a working group which is responsible for a cryptographic
authentication protocol.  If it is not legal to discuss and develop
cryptographic algorithms and protocols in the PRC, or to export the
results of such work, then my working group cannot usefully meet  
there,

regardless of what the IAOC decides about the IETF as a whole being
able to meet.

I also normally organize PGP key-signing sessions at IETF meetings.
If the operation of a CA or other cryptographic signing service  
requires a license in the PRC, then we may not be able to hold such  
a session, or it may require a special license.


I consider it entirely appropriate for me in my role as a working  
group chair, or Cullen in his role as an AD, to ask that the IAOC  
obtain answers to these questions from competent experts, such as  
legal counsel familiar with PRC law.



Finally, I would note that I am all for appointing people to  
positions of responsibility, putting appropriate checks and appeal  
and recall mechanisms in place, and them letting them go about doing  
their jobs. However, in this instance, the IAOC _asked_ for  
community input, so it seems silly to object to someone providing  
such input on the grounds that they are "doing the IAOC's job for it".




I would just note that no one on the IAOC has objected to this. I, for  
one, find all of this discussion useful and enlightening.


Regards
Marshall


-- Jeff
___
IAOC mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/iaoc



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

Re: The IETF and the SmartGrid

[Hiroshi Esaki]

Hi Fred and Michael,

This is Hiroshi Esaki of WIDE project, Japan.
We have long time worked on the introduction of IP technology into the
faculity networks, especially focusing on the usage of IPv6.
We run the Green University of Tokyo Project.
We have some professional operation using IPv6 on bulding automation
and lightening control system.
The most of exisiting and current system in this particular field is 
based on
non-IP system, however they are going to realize the benefit of IP 
technology

and open technology  in this field.

Thanks,
Hiroshi Esaki, WIDE Project

Michael Dillon wrote:

Myself and others are deeply concerned by how this effort is developing.
There is no current consensus on what the communications architecture of the
SmartGrid is or how IP actually fits into it.

The Utility Industry does not understand the current IPv4 number exhaust
problem and the consequences of that if they want to put a IP address on
every Utility Meter in North America.

What is equally troubling is that many of the underlying protocols that
utilities wish to deploy are not engineered for IPv6. We have an example of
that in a recent ID.



I've asked the ARIN Public Policy mailing list how people would feel about
banning the Electric Utility industry (and sub contractors) from receiving
any IPv4 addresses for use on the Smart Grid. This would include direct
ARIN allocations and assignment from ISPs.

I think that you are right to raise this issue in discussion since we badly
need to shine a light on the details of transitioning the Internet to IPv6.

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

  



--
===

Hiroshi ESAKI, Ph.D
Professor,
Graduate School of Information Science and Technology,
The University of Tokyo,
102A2, 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-8656, Japan
Email   hiro...@wide.ad.jp
TEL : +81-3-5841-7465
FAX : +81-3-5841-7465
http://www.i.u-tokyo.ac.jp/
http://hiroshi1.hongo.wide.ad.jp/hiroshi/index.html 


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

RE: The IETF and the SmartGrid

[Richard Shockey]

Thank you for your response.

Is there any documentation URL's etc ( hopefully in English ) that you could
share?

>  -Original Message-
>  From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
>  Of Hiroshi Esaki
>  Sent: Monday, October 05, 2009 8:39 PM
>  To: Michael Dillon; Richard Shockey; ietf@ietf.org
>  Subject: Re: The IETF and the SmartGrid
>  
>  Hi Fred and Michael,
>  
>  This is Hiroshi Esaki of WIDE project, Japan.
>  We have long time worked on the introduction of IP technology into the
>  faculity networks, especially focusing on the usage of IPv6.
>  We run the Green University of Tokyo Project.
>  We have some professional operation using IPv6 on bulding automation
>  and lightening control system.
>  The most of exisiting and current system in this particular field is
>  based on
>  non-IP system, however they are going to realize the benefit of IP
>  technology
>  and open technology  in this field.
>  
>  Thanks,
>  Hiroshi Esaki, WIDE Project

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

Re: The IETF and the SmartGrid

[Brian E Carpenter]

On 2009-10-06 10:20, Richard Shockey wrote:
...
> The Utility Industry does not understand the current IPv4 number exhaust
> problem and the consequences of that if they want to put a IP address on
> every Utility Meter in North America. 

Ironic, really, since IP addresses for every streetlight was one of
the favourite examples in the IPng days.

Let me quote from RFC 1673 "Electric Power Research Institute Comments on IPng",
authored by
   Ron Skelton
   Member of Technical Staff
   Advanced IT Group
   Electric Power Research Institute
   Palo Alto CA 94303

 "2. Basic Requirements.

  - Scaleability
The addressing scheme must have essentially an unlimited address
space to encompass an arbitrarily large number of information
objects.  Specifically it must solve the fundamental limitations
of 32 bit formats, a format for 20 octets and above is considered
suitable."

(The document was biased towards OSI addressing.)

  Brian

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

Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF

[Dean Willis]

On Oct 2, 2009, at 12:27 PM, John C Klensin wrote:

...
Perhaps the latter suggests a way for the IAOC to think about
this.  Assume that, however unlikely it is, the meeting were
called off mid-way and that every IETF participant who attended
sued the IASA to recover the costs of leaving China earlier than
expected, the prorata costs of unexpectedly attending only part
of a meeting, and possibly the value of lost time.   Suppose the
hotel also tried to recover lost revenue and lost reputation
costs as some have suggested in this discussion might be
possible.   Now consider going out and buying insurance against
those risks.  There are insurance companies who are happy to do
that sort of risk assessment and quote prices (and do it
professionally, as if their bottom line depends on it, which it
does) and with great skill.  If the cost of such insurance is a
reasonable add-on to the other costs of holding a meeting in
Beijing (or can be passed on to the host), then we go ahead with
the meeting.  If not, we make another plan.


That's the best suggestion for managing the risk side of this equation  
that I've heard. It's brilliant! Great thinking, John!


--
Dean

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