Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 140 messages in the last 7 days.
 
script run at: Fri Jul 19 00:53:02 EDT 2013
 
Messages   |  Bytes| Who
+--++--+
  5.71% |8 |  8.08% |97324 | hal...@gmail.com
  6.43% |9 |  6.96% |83850 | denghu...@gmail.com
  4.29% |6 |  4.53% |54622 | stefan.win...@restena.lu
  3.57% |5 |  4.57% |55051 | abdussalambar...@gmail.com
  3.57% |5 |  4.25% |51253 | bernard_ab...@hotmail.com
  2.86% |4 |  4.62% |55730 | mary.h.bar...@gmail.com
  3.57% |5 |  3.02% |36363 | john-i...@jck.com
  3.57% |5 |  2.92% |35224 | ted.le...@nominum.com
  2.14% |3 |  4.28% |51567 | adr...@olddog.co.uk
  2.86% |4 |  2.49% |29961 | p...@nohats.ca
  2.86% |4 |  2.42% |29197 | hsan...@isdg.net
  2.86% |4 |  2.41% |29071 | jo...@taugh.com
  2.86% |4 |  2.39% |28792 | hartmans-i...@mit.edu
  2.86% |4 |  2.30% |27727 | bob.hin...@gmail.com
  2.86% |4 |  1.98% |23903 | d...@dcrocker.net
  2.14% |3 |  1.90% |22957 | do...@dougbarton.us
  2.14% |3 |  1.54% |18617 | y...@checkpoint.com
  1.43% |2 |  1.93% |23242 | ya...@cnnic.cn
  2.14% |3 |  1.20% |14449 | ra...@psg.com
  1.43% |2 |  1.76% |21270 | sanjay.mis...@verizon.com
  1.43% |2 |  1.63% |19615 | david.bl...@emc.com
  1.43% |2 |  1.54% |18571 | mo...@network-heretics.com
  1.43% |2 |  1.32% |15922 | jason_living...@cable.comcast.com
  1.43% |2 |  1.29% |15570 | b...@nostrum.com
  1.43% |2 |  1.29% |15566 | sm+i...@elandsys.com
  1.43% |2 |  1.12% |13496 | brian.e.carpen...@gmail.com
  1.43% |2 |  1.04% |12564 | c...@a.org
  1.43% |2 |  0.90% |10822 | j...@mercury.lcs.mit.edu
  1.43% |2 |  0.84% |10168 | ietf-secretar...@ietf.org
  0.71% |1 |  1.17% |14159 | mary.ietf.bar...@gmail.com
  0.71% |1 |  1.09% |13117 | hous...@vigilsec.com
  0.71% |1 |  1.08% |13018 | ted.i...@gmail.com
  0.71% |1 |  1.00% |12082 | s...@resistor.net
  0.71% |1 |  0.99% |11935 | afab...@hotmail.com
  0.71% |1 |  0.86% |10393 | nar...@us.ibm.com
  0.71% |1 |  0.84% |10151 | joseph@gmail.com
  0.71% |1 |  0.77% | 9267 | bdick...@verisign.com
  0.71% |1 |  0.76% | 9199 | ma...@isc.org
  0.71% |1 |  0.74% | 8911 | l.w...@surrey.ac.uk
  0.71% |1 |  0.72% | 8624 | stephen.farr...@cs.tcd.ie
  0.71% |1 |  0.67% | 8033 | p...@frobbit.se
  0.71% |1 |  0.66% | 7910 | margaret...@gmail.com
  0.71% |1 |  0.65% | 7858 | me...@globetel.com.ph
  0.71% |1 |  0.65% | 7792 | pait...@cisco.com
  0.71% |1 |  0.63% | 7594 | ebur...@standardstrack.com
  0.71% |1 |  0.62% | 7504 | d3e...@gmail.com
  0.71% |1 |  0.62% | 7428 | ptha...@broadcom.com
  0.71% |1 |  0.61% | 7345 | t...@dropfuse.com
  0.71% |1 |  0.59% | 7124 | s...@harvard.edu
  0.71% |1 |  0.59% | 7109 | war...@kumari.net
  0.71% |1 |  0.58% | 6934 | zehn@gmail.com
  0.71% |1 |  0.57% | 6874 | wesley.geo...@twcable.com
  0.71% |1 |  0.55% | 6656 | ferna...@gont.com.ar
  0.71% |1 |  0.55% | 6603 | iab-ch...@iab.org
  0.71% |1 |  0.54% | 6560 | arturo.ser...@gmail.com
  0.71% |1 |  0.54% | 6450 | o...@gih.com
  0.71% |1 |  0.52% | 6322 | due...@it.aoyama.ac.jp
  0.71% |1 |  0.50% | 6028 | a...@yumaworks.com
  0.71% |1 |  0.49% | 5936 | fa...@isi.edu
  0.71% |1 |  0.48% | 5815 | ch...@ietf.org
  0.71% |1 |  0.46% | 5598 | scott.b...@gmail.com
  0.71% |1 |  0.46% | 5568 | yd...@cs.helsinki.fi
  0.71% |1 |  0.46% | 5491 | jari.ar...@piuha.net
  0.71% |1 |  0.44% | 5301 | a...@hxr.us
+--++--+
100.00% |  140 |100.00% |  1205153 | Total

RE: IAOC overview clash

[Mishra, Sanjay]

Brian - thank you. Yes, I certainly plan to to attend the newcomer orientation. 
My point was that moving to the time slot still did not avoid the conflict. But 
i agree with you that new comer orientation is helpful now and there will be 
plenty of opportunity later to pick up on IOAC administrative functions.

Thanks
Sanjay



Thanks
Sanjay Mishra
Cell:301-452-2595
Sent with Good (www.good.com)

-Original Message-
From: Brian E Carpenter 
[brian.e.carpen...@gmail.com]
Sent: Thursday, July 18, 2013 04:34 PM Eastern Standard Time
To: Mishra, Sanjay
Cc: ietf@ietf.org
Subject: IAOC overview clash


Sanjay,

A comment from an old-timer: if you want to understand the IETF as a whole,
put your priority on the Newcomer's orientation. There's plenty of time
in the future to understand details of the IETF's administration.

Unfortunately, clashes between interesting sessions are unavoidable
at the IETF, because there is just too much going on. If they move the
IAOC overview again, it will clash with something else, even on Sunday.

Regards
   Brian Carpenter

On 19/07/2013 08:14, Mishra, Sanjay wrote:
> Moving IAOC Overview session now conflicts with Newcomer's orientation. The 
> original schedule for IAOC conflicted only for the 2nd hour with newcomer 
> meet and greet and I had figured to attend at least the first hour but now 
> the IAOC session overlaps fully with Newcomer's orientation so those first 
> time attendees like me will have to likely pick newcomer orientation over 
> IAOC overview which if not conflicting would have been helpful.
>
> Is it possible to start sooner on Sunday?
>
> Thanks
> Sanjay
>
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
> ietf-requ...@ietf.org
> Sent: Tuesday, July 16, 2013 8:33 PM
> To: ietf@ietf.org
> Subject: Ietf Digest, Vol 62, Issue 57
>
> If you have received this digest without all the individual message 
> attachments you will need to update your digest options in your list 
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/ietf
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or 
> Plain Text Digests?" to MIME.  You can set this option globally for all the 
> list digests you receive at this point.
>
>
>
> Send Ietf mailing list submissions to
>   ietf@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
>   ietf-requ...@ietf.org
>
> You can reach the person managing the list at
>   ietf-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of Ietf digest..."
>

Re: IAOC overview clash

[Randy Bush]

global bgp never converges (and how would you know if it did?)
all devices fail, and two will fail at once
there is no more ipv4 free pool, get over it
there is not enough time on sunday for everything without conflict
there are never enough social tickets (but there is heavy last minute trading)
the cookies are bad and bad for you, and they are too small (~= w allen)

welcome to the internet and the ietf!

IAOC overview clash

[Brian E Carpenter]

Sanjay,

A comment from an old-timer: if you want to understand the IETF as a whole,
put your priority on the Newcomer's orientation. There's plenty of time
in the future to understand details of the IETF's administration.

Unfortunately, clashes between interesting sessions are unavoidable
at the IETF, because there is just too much going on. If they move the
IAOC overview again, it will clash with something else, even on Sunday.

Regards
   Brian Carpenter

On 19/07/2013 08:14, Mishra, Sanjay wrote:
> Moving IAOC Overview session now conflicts with Newcomer's orientation. The 
> original schedule for IAOC conflicted only for the 2nd hour with newcomer 
> meet and greet and I had figured to attend at least the first hour but now 
> the IAOC session overlaps fully with Newcomer's orientation so those first 
> time attendees like me will have to likely pick newcomer orientation over 
> IAOC overview which if not conflicting would have been helpful.
> 
> Is it possible to start sooner on Sunday?
> 
> Thanks
> Sanjay
> 
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
> ietf-requ...@ietf.org
> Sent: Tuesday, July 16, 2013 8:33 PM
> To: ietf@ietf.org
> Subject: Ietf Digest, Vol 62, Issue 57
> 
> If you have received this digest without all the individual message 
> attachments you will need to update your digest options in your list 
> subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/ietf
> 
> Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or 
> Plain Text Digests?" to MIME.  You can set this option globally for all the 
> list digests you receive at this point.
> 
> 
> 
> Send Ietf mailing list submissions to
>   ietf@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
>   ietf-requ...@ietf.org
> 
> You can reach the person managing the list at
>   ietf-ow...@ietf.org
> 
> When replying, please edit your Subject line so it is more specific than "Re: 
> Contents of Ietf digest..."
> 

RE: Ietf Digest, Vol 62, Issue 57

[Mishra, Sanjay]

Moving IAOC Overview session now conflicts with Newcomer's orientation. The 
original schedule for IAOC conflicted only for the 2nd hour with newcomer meet 
and greet and I had figured to attend at least the first hour but now the IAOC 
session overlaps fully with Newcomer's orientation so those first time 
attendees like me will have to likely pick newcomer orientation over IAOC 
overview which if not conflicting would have been helpful.

Is it possible to start sooner on Sunday?

Thanks
Sanjay

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
ietf-requ...@ietf.org
Sent: Tuesday, July 16, 2013 8:33 PM
To: ietf@ietf.org
Subject: Ietf Digest, Vol 62, Issue 57

If you have received this digest without all the individual message attachments 
you will need to update your digest options in your list subscription.  To do 
so, go to 

https://www.ietf.org/mailman/listinfo/ietf

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or 
Plain Text Digests?" to MIME.  You can set this option globally for all the 
list digests you receive at this point.



Send Ietf mailing list submissions to
ietf@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
ietf-requ...@ietf.org

You can reach the person managing the list at
ietf-ow...@ietf.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Ietf digest..."

Gen-ART review of draft-ietf-trill-directory-framework-05

[Black, David]

Document: draft-ietf-trill-directory-framework-05
Reviewer: David L. Black
Review Date: July 17, 2013
IETF LC End Date: July 18, 2013

Summary:
This draft is on the right track but has open issues, described in the review.

This draft describes a framework for using directory servers to provide
address mappings (address -> destination RBridge) to TRILL Rbridges as an
alternative to data plane learning and use of the TRILL ESADI protocol.

The draft's generally well written and clear.  I found a couple of minor
issues.

Major issues: None.

Minor issues:

[1] The last bullet in Section 3.1 says:

   - In an environment where VMs migrate, there is a higher chance
 of cached information becoming invalid, causing traffic to be
 black-holed by the ingress RBridge, that is, persistently sent
 to the wrong egress RBridge. If VMs do not flood gratuitous
 ARP/ND or VDP [802.1Qbg] messages upon arriving at new
 locations, the ingress nodes might not have MAC entries for the
 MAC of the newly arrived VMs, causing unknown address flooding.

This is incorrect in multiple ways and should just be removed:

- Persistent black-holing is rare in practice because all common
VM migration implementations issue the gratuitous messages.
- VMs don't send the gratuitous messages, hypervisors do.
- VDP is not flooded.  The receiver's always a bridge.
- At least one common VM migration implementation actually uses a gratuitous
RARP, not ARP.
- Flooding is done by the bridges and Rbridges, not the VMs.

[2] There are some unfortunate notation problems in Section 5.1 that carry
into the following sections, based on the logical data structure:

   [{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
   interested RBridges}]

- The first open curly brace ('{') is unmatched.
- Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MAC&VLAN,
none of which appear in that structure.

Nits/editorial comments:

Section 1 - item 1 in the numbered list does not explain why it makes
a directory approach attractive.  This should be added, as it is
present for the other three items .

Section 2 - Say that IS-IS is a routing protocol.
The definition of Station should say that the node or virtual node
is on a network.  Also, please define or explain "virtual node".

Section 3.2 - Add the number of entries to be learned to scenario #1
in order to parallel the scenario # 2 discussion.

Section 4 - remove "(distributed model)" from first paragraph,
as it's not explained.

Section 5.3, top of p.13:

   therefore, there needs to be some mechanism by which RBridges that
   have pulled information that has not expired can be informed when
   that information changes or the like.

"or the like" is vague.  I suggest "or becomes invalid for other
 reasons".

idnits 2.12.17 didn't find any nits that need attention.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754

Last Call: (Location Information Server (LIS) Discovery using IP address and Reverse DNS) to Informational RFC

[Dickson, Brian]

I have a question about the use of STUN, as a way of discovering IP 
address(es), in draft-ietf-geopriv-res-gw-lis-discovery.

Section 4.1 refers to STUN by way of RFC 5389, but reading both the present 
draft and 5389 leaves one critical item unspecified:

  oWhat domain name is to be used, in the SRV query ("_stun._udp.domain" or 
"_stuns._tcp.domain" -- what value of "domain" is to be used in the query)?

Without that being specified, implementers/users have nothing specific to try, 
and without that, I do not see how STUN could be used at all.

Similarly, recommending that STUN be provisioned (section 4.6) leaves the 
question of "under which domain", unanswered and ambiguous.

Section 4.4 suggests that STUN servers be able to see the public IP used, but 
again, how should the STUN server be found?

This may have been an oversight by the authors, and they may already have 
envisioned answers to these questions.

Even section 7 (IAB considerations) is IMHO incomplete without the necessary 
"domain" specification for STUN usage.

I think resolving this issue is critical  for the document to serve its stated 
purpose.

(Is there perhaps a companion STUN RFC that does discuss this? If so, adding 
that as a normative reference may suffice, and linking to that in sections 4.1, 
4.4, 4.6, and 8.

Modulo this oversight, I believe this is a well-written document and fills in 
an important gap in LIS deployment and use.

Brian Dickson

Re: Internationalization and draft-ietf-abfab-eapapplicability

[Stefan Winter]

Hi,

> We don't get to place requirements on applications except to say what
> they need to do to use EAP.  The protocol requirement for that is that
> applications using EAP need to know what character set they have so that
> EAP can convert the identity to UTF-8 and so that EAP methods can do any
> needed conversions.

That text sounds pretty good, and is probably all ABFAB needs to say
about this.

I'm still not happy with the i18n situation in EAP; especially that EAP
itself doesn't always know its requirements regarding encoding and
normalization.

I think the basic problem is that identities and other credentials are
eap-type specific and one might expect that neither core EAP nor the AAA
transport have to care about what an EAP method thinks it wants as encoding.
But that isn't true, since at least the Identity part (not the
passwords; I'm not saying these would need to be normalised at all) may
be needed by the EAP method, but they transpire through to the
EAP-Identity and RADIUS/other-AAA User-Names. It's a spill-over effect,
where an EAP method's decisions re encoding and normalisation impose
something on other protocols.

Due to that, an EAP method's way of constructing *identities* needs to
be regulated so that the method, core EAP, and AAA transports can get along.

Nothing of this needs to happen in ABFAB, but I think work needs to be done.

Either by modifying EAP itself to impose a common encoding and maybe
normalisation on EAP-Identity (which in turn forces EAP methods to use
that same encoding and/or normalisation in their "outer" or "only"
phase), or by making sure all EAP methods use an encoding that does not
create problems on EAP core and the AAA layer.

I think this really has "force use of UTF-8" written all over it. The
question for me is which path to take, and where/who does the work.

Greetings,

Stefan Winter


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473



signature.asc
Description: OpenPGP digital signature