RE: Comments for Humorous RFCs or uncategorised RFCs or dated April the first

[l.wood]

There's a lot of hysteresis... because calling it funny is often a stretch.

Lloyd Wood
http://sat-net.com/L.Wood/



From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Scott Brim 
[s...@internet2.edu]
Sent: 08 April 2013 20:34
To: Lucy Lynch
Cc: ietf; Abdussalam Baryun
Subject: Re: Comments for Humorous RFCs or uncategorised RFCs or dated April
the first

On 04/08/13 13:35, Lucy Lynch allegedly wrote:
> On Mon, 8 Apr 2013, Wes Beebee (wbeebee) wrote:
>
>>
>>> If the date is special then thoes RFCs SHOULD be *historical*.
>>
>> I thought they should be classified as "hysterical".
>
> there is an echo (echo) ((echo) ) in here (here) ((here))

IETF humor has lots of hysteresis.

Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07

[Peter Yee]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments you
may receive. 

Document: draft-ietf-pcp-upnp-igd-interworking-07
Reviewer: Peter Yee
Review Date: Apr-08-2013
IETF LC End Date: Apr-08-2013
IESG Telechat date: Unknown

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

This is a well-written draft describing how Universal Plug-and-Play Internet
Gateway Devices interwork with NAT devices that use the Port Control
Protocol.  My review is mostly nits with otherwise minor issues.  I have no
problems with the general concept and enjoyed reading a clearly articulated
concept.

Major Issues:

None.

Minor Issues:

Section 4.1: is the mapping of the state variables between the UPnP IGD
function and the PCP Client function really straightforward such that it
does not need further description?  I'm asking if an implementor would
naturally gravitate to the correct use of the mapping without further
instructions.  Similar questions arise for Sections 4.2 and 4.3, although I
believe those are more straightforward mappings.

Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error
other than a short-lifetime error, or in the case of a failed resend, any
PCP error at all.  The wording makes it seem like the short-lifetime errors
are somehow not PCP errors and is therefore confusing.  It also doesn't
explicitly deal with how many repeats should be done on a resend.  

Nits:

General: replace "re-send" with "resend".

Page 3, 1st paragraph, 2nd sentence: insert "a" before each occurrence of
UPnP.  

Page 4, section 3, 4th bullet: consider changing "in" to "on" or "over".

Page 4, 1st paragraph after the bullet items: bracket "for instance" with
commas.

Page 5, Figure 3: perhaps the "LAN Side" label could move a bit to the left
to give it better delineation from the "External Side" label?

Page 5, 1st paragraph after Figure 4, 2nd sentence: add a comma after "
[I-D.ietf-pcp-base]".

Page 5, 2nd paragraph after Figure 4: change "can not" to "cannot".

Page 9, section 5, 3rd paragraph: insert "the same way" or "the same" before
"as any PCP Client".

Page 9, section 5.1, 2nd paragraph: insert "whether" before "it should".

Page 9, section 5.1, 3rd paragraph: insert "the" before "requesting UPnP
Control Point".

Page 10, Section 5.3, 2nd paragraph, 1st sentence: consider changing
"retrieve" to "extract".

Page 11, 1st paragraph after bullet items, 2nd sentence: change "to" to
"than".

Page 11, Section 5.6: swap the order of "AddPortMapping()" and
"AddAnyPortMapping()" to match the order of the subsequent subsections.

Page 11, Section 5.6.1, 2nd paragraph, 2nd sentence: change "30s" to "30
seconds".

Page 13, 1st paragraph, 4th sentence: change "re-issue" to "issue"; change
"new requested" to "different requested".

Page 14, last paragraph: delete the comma after "4 times)".

Page 15, Section 5.7, 1st paragraph: append a comma after
"GetSpecificPortMappingEntry()".

Page 15, Section 5.7, 3rd paragraph, 3rd sentence: replace "60s" with "60
seconds".

Page 15, Section 5.7, 3rd paragraph, last sentence: insert "the" before
"error code"; change "enquried" to "queried".

Page 15, Section 5.8, 1st paragraph: insert ", respectively" before the
period.

Page 15, Section 5.8, 2nd paragraph, 2nd sentence: insert "the" before '"606
Action Not'.

Page 16, last paragraph, 2nd sentence: insert "the" before'"731
PortMappingNotFound'.

Page 19, 1st continuation paragraph, 1st sentence fragment: change "of" to
"in".

Page 19, 1st continuation paragraph, 1st full sentence: consider swapping
the positions of "renew" and "periodically" for readability.

Page 19, Section 5.10, 1st paragraph, 2nd sentence: I prefer "In particular"
to "Particularly" here.

Page 19, Section 5.10, 3rd paragraph, 3rd sentence: replace "signalled" with
"signaled".

videos and blog posts on home networking, buffer bloat

[IETF Chair]

The good folks at ISOC shot a number of videos during IETF-86 with experts on 
various topics. These videos are now available, take a look at the blog post 
John and I wrote:

http://www.ietf.org/blog/2013/04/bits-n-bytes-on-video/

The videos can also be accessed directly at:

http://www.youtube.com/watch?v=3SvhtLl8aTg (John Brzozowski on HIPnet)
http://www.youtube.com/watch?v=d-vwdD3Xtyg (Mark Townsley on HOMENET)
http://www.youtube.com/watch?v=NuHYOu4aAqg (Chris Griffiths and Dave Täht on 
buffer bloat)

There was also an earlier blog post that focused on the importance on running 
code, written together with Chris:

http://www.ietf.org/blog/2013/03/running-code-at-ietf-86-2/

All in all, I thought these demos and videos were very interesting. It is 
excellent that we are building implementations of the things that we specify in 
the working groups. And interestingly, Bits-n-Bytes has become a place to show 
some these results. Thanks to everyone who was involved, and the sponsors who 
made it possible! I also think it would be great to have even more of this in 
the coming IETFs. If you have ideas, let us know!

Jari Arkko

RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07

[mohamed.boucadair]

Dear Peter,

Thanks for the review. 
Please see inline.

Cheers,
Med

>-Message d'origine-
>De : Peter Yee [mailto:pe...@akayla.com]
>Envoyé : mardi 9 avril 2013 10:13
>À : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org
>Cc : gen-...@ietf.org; ietf@ietf.org
>Objet : Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07
>
>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
>
>
>Please resolve these comments along with any other Last Call comments you
>may receive.
>
>Document: draft-ietf-pcp-upnp-igd-interworking-07
>Reviewer: Peter Yee
>Review Date: Apr-08-2013
>IETF LC End Date: Apr-08-2013
>IESG Telechat date: Unknown
>
>Summary: This draft is on the right track but has open issues, described in
>the review. [Ready with issues]
>
>This is a well-written draft describing how Universal Plug-and-Play
>Internet
>Gateway Devices interwork with NAT devices that use the Port Control
>Protocol.  My review is mostly nits with otherwise minor issues.  I have no
>problems with the general concept and enjoyed reading a clearly articulated
>concept.

[Med] Thanks.

>
>Major Issues:
>
>None.
>
>Minor Issues:
>
>Section 4.1: is the mapping of the state variables between the UPnP IGD
>function and the PCP Client function really straightforward such that it
>does not need further description?  I'm asking if an implementor would
>naturally gravitate to the correct use of the mapping without further
>instructions.  Similar questions arise for Sections 4.2 and 4.3, although I
>believe those are more straightforward mappings.

[Med] I don't think further explanation is needed. Pointers to the appropriate 
sections is included in Section 4.2 and Section 4.3. FWIW, there are already 
existing implementations of the IWF and no "complaint" was received from these 
implementers.

>
>Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP error
>other than a short-lifetime error, or in the case of a failed resend, any
>PCP error at all.  The wording makes it seem like the short-lifetime errors
>are somehow not PCP errors and is therefore confusing.  It also doesn't
>explicitly deal with how many repeats should be done on a resend.

[Med] The basic behavior is to relay the received error to the UPnP CP. For the 
short-lifetime errors, the IWF may decide to resend the request and not relay 
those errors immediately to the UPnP CP. The number of repeats is not specified 
here as it can be implementation-specific. 


>Nits:

[Med] Fixed. 

>
>General: replace "re-send" with "resend".
>
>Page 3, 1st paragraph, 2nd sentence: insert "a" before each occurrence of
>UPnP.
>
>Page 4, section 3, 4th bullet: consider changing "in" to "on" or "over".
>
>Page 4, 1st paragraph after the bullet items: bracket "for instance" with
>commas.
>
>Page 5, Figure 3: perhaps the "LAN Side" label could move a bit to the left
>to give it better delineation from the "External Side" label?
>
>Page 5, 1st paragraph after Figure 4, 2nd sentence: add a comma after "
>[I-D.ietf-pcp-base]".
>
>Page 5, 2nd paragraph after Figure 4: change "can not" to "cannot".
>
>Page 9, section 5, 3rd paragraph: insert "the same way" or "the same"
>before
>"as any PCP Client".
>
>Page 9, section 5.1, 2nd paragraph: insert "whether" before "it should".
>
>Page 9, section 5.1, 3rd paragraph: insert "the" before "requesting UPnP
>Control Point".
>
>Page 10, Section 5.3, 2nd paragraph, 1st sentence: consider changing
>"retrieve" to "extract".
>
>Page 11, 1st paragraph after bullet items, 2nd sentence: change "to" to
>"than".
>
>Page 11, Section 5.6: swap the order of "AddPortMapping()" and
>"AddAnyPortMapping()" to match the order of the subsequent subsections.
>
>Page 11, Section 5.6.1, 2nd paragraph, 2nd sentence: change "30s" to "30
>seconds".
>
>Page 13, 1st paragraph, 4th sentence: change "re-issue" to "issue"; change
>"new requested" to "different requested".
>
>Page 14, last paragraph: delete the comma after "4 times)".
>
>Page 15, Section 5.7, 1st paragraph: append a comma after
>"GetSpecificPortMappingEntry()".
>
>Page 15, Section 5.7, 3rd paragraph, 3rd sentence: replace "60s" with "60
>seconds".
>
>Page 15, Section 5.7, 3rd paragraph, last sentence: insert "the" before
>"error code"; change "enquried" to "queried".
>
>Page 15, Section 5.8, 1st paragraph: insert ", respectively" before the
>period.
>
>Page 15, Section 5.8, 2nd paragraph, 2nd sentence: insert "the" before
>'"606
>Action Not'.
>
>Page 16, last paragraph, 2nd sentence: insert "the" before'"731
>PortMappingNotFound'.
>
>Page 19, 1st continuation paragraph, 1st sentence fragment: change "of" to
>"in".
>
>Page 19, 1st continuation paragraph, 1st full sentence: consider swapping
>the positions of "renew" and "periodically" for readability.
>
>Page 19, Section 5.10, 1st paragraph, 2nd sentence: I prefer "In
>particular"
>to "Particularly" here.
>
>Page 19, Section 5.10, 3rd pa

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

[Henry B. Hotz]

Actually, what I get from this and all the other discussions is that it's 
unclear if the updated OCSP satisfies the "suitability for the intended 
purpose" test.  Or at least it fails the KISS principle w.r.t. that.

Rephrasing:  an OCSP client should be able to tell from an OCSP response if:  
a) the subject cert is on the CAs white list, b) the subject cert is on the CAs 
black list, c) the subject cert is not on either list, or finally d) the OCSP 
server is obsolete, and doesn't support making those distinctions.  It's not 
trivial to see how to parse 2560bis responses w.r.t. those cases, therefore 
it's highly likely that computational complexity will prevent us from doing so. 
 Even if that's not actually the case, then implementor misunderstandings will 
prevent us from doing so in practice.

Therefore I vote against moving this draft forward.  I just don't see the point.

If someone were to write an informational RFC which explained how to determine 
which of the 4 cases an OCSP response fell into, AND if said RFC also convinced 
me that the decision process was easy to understand, THEN I would change my 
vote.  Obviously an appendix in 2560bis would serve just as well.

RE: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

[Piyush Jain]

+1. 

> -Original Message-
> From: pkix-boun...@ietf.org [mailto:pkix-boun...@ietf.org] On Behalf Of
> Henry B. Hotz
> Sent: Monday, April 08, 2013 1:35 PM
> To: Sean Turner
> Cc: p...@ietf.org; ietf@ietf.org
> Subject: Re: [pkix] Last Call:  (X.509
> Internet Public Key Infrastructure Online Certificate Status Protocol -
OCSP)
> to Proposed Standard
> 
> Actually, what I get from this and all the other discussions is that it's
unclear if
> the updated OCSP satisfies the "suitability for the intended purpose"
test.
> Or at least it fails the KISS principle w.r.t. that.
> 
> Rephrasing:  an OCSP client should be able to tell from an OCSP response
if:
> a) the subject cert is on the CAs white list, b) the subject cert is on
the CAs
> black list, c) the subject cert is not on either list, or finally d) the
OCSP server
> is obsolete, and doesn't support making those distinctions.  It's not
trivial to
> see how to parse 2560bis responses w.r.t. those cases, therefore it's
highly
> likely that computational complexity will prevent us from doing so.  Even
if
> that's not actually the case, then implementor misunderstandings will
> prevent us from doing so in practice.
> 
> Therefore I vote against moving this draft forward.  I just don't see the
point.
> 
> If someone were to write an informational RFC which explained how to
> determine which of the 4 cases an OCSP response fell into, AND if said RFC
> also convinced me that the decision process was easy to understand, THEN I
> would change my vote.  Obviously an appendix in 2560bis would serve just
as
> well.
> ___
> pkix mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

R: Last Call Expired:

[Salvatore D'Antonio]

Dear all,

 

A new version of the Internet Draft on Flow Selection Techniques has been 
submitted. It contains the following changes:

-  A new section illustrating the difference between Intermediate Flow 
Selection Process and Intermediate Selection Process has been added,

-  The sentence "In order to be compliant with this document, at least 
the Property  Match Filtering MUST be implemented." has been removed in Section 
1,

-  “MUST” has been replaced with “SHOULD” in Section 5.1,

-  “The flowSelectorAlgorithm registry is maintained by IANA." has been 
replaced with “IANA is requested to create the flowSelectorAlgorithm registry.”

-  The sentence "The registry can be updated when specifications of the 
new  technique(s) and any new Information Elements are provided." has been 
removed since it did not clarify how the registry will be managed.

-   Section 6.1.1 “Property Match Filtering” has been changed by adding 
some text on how Property Match Filtering can be  used by an Intermediate Flow 
Selection Process in the Metering Process, in the  Exporting Process and within 
an IPFIX Mediator.

 

Best regards,

 

Salvatore

 

Da: Benoit Claise [mailto:bcla...@cisco.com] 
Inviato: lunedì 8 aprile 2013 15:21
A: draft-ietf-ipfix-flow-selection-t...@tools.ietf.org
Cc: ipfix-cha...@tools.ietf.org
Oggetto: Fwd: Last Call Expired: 

 

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit



 Original Message  


Subject: 

Last Call Expired: 


Date: 

Mon, 01 Apr 2013 00:28:46 -0700


From: 

DraftTracker Mail System   



To: 

i...@ietf.org, ipfix-cha...@tools.ietf.org, 
draft-ietf-ipfix-flow-selection-t...@tools.ietf.org


CC: 

iesg-secret...@ietf.org

 

Please DO NOT reply to this email.
 
I-D: 
ID Tracker URL: 
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
 
IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.
 
 
 

 

 

  _  

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di rilascio: 
07/04/2013


**  

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

 

Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le 
borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille 

 

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

 

Questa informativa e' inserita in automatico dal sistema al fine esclusivo 
della realizzazione dei fini istituzionali dell'ente.

Re: Sufficient email authentication requirements for IPv6

[Keith Moore]

On 03/29/2013 01:28 PM, Douglas Otis wrote:
> The Internet is under a DDoS attack specifically against an email 
address reputation service.


You have it backwards.  Internet email has long been under DDoS attack 
from email address reputation services.


Keith

Re: Sufficient email authentication requirements for IPv6

[Douglas Otis]

On Apr 8, 2013, at 10:27 PM, joel jaeggli  wrote:

> On 4/8/13 9:18 PM, Douglas Otis wrote:
>> 
>> On Mar 31, 2013, at 1:23 AM, Doug Barton > > wrote:
>> 
>>> On 03/30/2013 11:26 PM, Christian Huitema wrote:
> IPv6 makes publishing IP address reputations impractical.  Since IP 
> address reputation has been a primary method for identifying abusive 
> sources with IPv4, imposing ineffective and flaky > replacement 
> strategies has an effect of deterring IPv6 use.
 
 In practice, the /64 prefix of the IPv6 address has very much the same 
 "administrative" properties as the /32 value of the IPv4 address. It 
 should be fairly straightforward to update a reputation system to manage 
 the /64 prefixes of IPv6. This seems somewhat more practical than trying 
 to change the behavior of mail agent if their connectivity happens to use 
 IPv6.
>>> 
>>> That only works insofar as the provider does not follow the standard 
>>> recommendation to issue a /48. If they do, the abuser has 65k /64s to 
>>> operate in.
>>> 
>>> What's needed is a little more intelligence about how the networks which 
>>> the IPv6 addresses are located are structured. Similar to the way that 
>>> reputation lists nowadays will black list a whole /24 if 1 or a few 
>>> addresses within it send spam.
>>> 
>>> The problems are not insoluble, they're just different, and arguably more 
>>> complex in v6. It's also likely that in the end more work on reputation 
>>> lists will provide less benefit than it did in the v4 world. But that's the 
>>> world we live in now.
>> 
>> Dear Doug,
>> 
>> Why aggregate into groups of 64k prefixes?  After all, this still does not 
>> offer a practical way to ascertain a granularity that isolates different 
>> entities at /64 or /48.  It is not possible to ascertain these boundaries 
>> even at a single prefix.  There is 37k BGP entries offering IPv6 
>> connectivity.  Why not hold each announcement accountable and make 
>> consolidated reputation a problem ISPs must handle?  Of course, such an 
>> approach would carry an inordinate level of support and litigation costs due 
>> to inadvertent collateral blocking.  Such consolidation would be as 
>> impractical as would an arbitrary consolidation at /48.
>> 
> Plently of people use IP to ASN mappings as part of their input for 
> reputation today.

Dear Joel,

Unfortunately, ISPs are bad at responding to email abuse complaints.  There are 
exceptions where reputation needs to be escalated to the ASN, as was the case 
in Brazil which then involved litigation.  You're welcome, but operations at 
that level will not scale and might lead to balkanization.

With respect to IPv6 granularity, there is only ~7k ASNs.  As IPv6 adoption 
increases, this should approach 37k.  In addition, there are more /32 prefixes 
than /48.  Each /32 represents a span greater than the entire IPv4 Internet.  
The network covered by each prefix represents an address span IPv4 squared in 
size.  The sparse nature of abuse and the size of IPv6 prefix space makes 
collecting evidence and distributing detected abuse by IP address or prefix 
both expensive and slow, where any IP address query mechanism is likely to 
result in self inflicted DDoS. 

If email offered authentication of the sourcing domain or that of a domain 
certificate, then reputation could be fairly applied and easily distributed. 
This ability is essential for IPv6.

Regards,
Douglas Otis

RE: Gen-ART review of draft-ietf-pcp-upnp-igd-interworking-07

[Peter Yee]

Med,
Thanks for the swift response to my review.  See my one reply
inline.

Kind regards,
-Peter

>>Page 13, 1st paragraph, 3rd sentence: what's meant here is if any PCP 
>>error other than a short-lifetime error, or in the case of a failed 
>>resend, any PCP error at all.  The wording makes it seem like the 
>>short-lifetime errors are somehow not PCP errors and is therefore 
>>confusing.  It also doesn't explicitly deal with how many repeats should
be done on a resend.

>[Med] The basic behavior is to relay the received error to the UPnP CP. For
the short-lifetime errors, the IWF may decide to resend the request and not
relay those errors immediately to the UPnP CP. The number of repeats is not
specified here as it can be implementation-specific. 

Your explanation is fine.  I just found the wording "If a PCP  error
response is received" to sound ambiguously as if the short-lifetime errors
were not a subset of PCP errors.

Re: Sufficient email authentication requirements for IPv6

[SM]

Hi Keith,
At 09:56 09-04-2013, Keith Moore wrote:
You have it backwards.  Internet email has long been under DDoS 
attack from email address reputation services.


Quoting Nathaniel Borenstein  [1]:

  "One man's blacklist is another's denial-of-service attack."

Email reputation services have a bad reputation.  In some respect it 
is similar to the email delivery problem where the smaller set of 
good people are negatively affected because of the larger set of "bad" people.


Regards,
-sm

P.S. You are the only participant who has been able to override the 
existing consensus during a Last Call. :-)


1. http://www.ietf.org/mail-archive/web/ietf/current/msg29826.html 

Re: Sufficient email authentication requirements for IPv6

[Douglas Otis]

On Apr 9, 2013, at 11:28 AM, SM  wrote:

> Hi Keith,
> At 09:56 09-04-2013, Keith Moore wrote:
>> You have it backwards.  Internet email has long been under DDoS attack from 
>> email address reputation services.
> 
> Quoting Nathaniel Borenstein  [1]:
> 
>  "One man's blacklist is another's denial-of-service attack."
> 
> Email reputation services have a bad reputation.  In some respect it is 
> similar to the email delivery problem where the smaller set of good people 
> are negatively affected because of the larger set of "bad" people.
> 
> Regards,
> -sm
> 
> P.S. You are the only participant who has been able to override the existing 
> consensus during a Last Call. :-)
> 
> 1. http://www.ietf.org/mail-archive/web/ietf/current/msg29826.html 

Dear SM,

In full agreement with Nathaniel.  Avoiding unfair collateral blocking is why 
source domain authentication, not authorization, is vital.

Regards,
Douglas Otis

Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.

[Donald Eastlake]

The theory that all April 1 dates RFCs are simply jokes and nothing
else is also easily refuted. Consider RFC 3092. It is an April 1st RFC
produced through that process and has certainly produced some
chuckles. Yet I've lost count of the number of emails I've gotten over
the years from non-English speakers thanking me for the RFC and saying
it was helpful to them...

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Mon, Apr 8, 2013 at 3:21 AM, Måns Nilsson  wrote:
> Subject: Proposed solution  for DPEP (Diversity Problem Entry Point) - IETF 
> April 1 jokes. Date: Sun, Apr 07, 2013 at 04:58:52PM -0400 Quoting Hector 
> Santos (hsan...@isdg.net):
>> This is one of those DPEP (Diversity Problem Entry Point) arising
>> from globalization, April 1 HRC (Humor Recognition Culture)
>> differences,  IETF "stalization" and the growth of I-D submissions.
>> I suggest there is a direct correlation among these factors with the
>> end goal efficacy of the submission.  Fortunately, there is a
>> technical solution for this particular DPEP:
>>
>> if Date is April.1 then
>>  id.filename = "joke-"+id.filename.
>> end if
>
> This solution has all the virtues of carpet-bombing. Mission accomplished
> but cost and collateral damage are improportionally large.  To me, both
> as humour /per se/ and as sorting help when selecting vendors (cf. my
> message in this thread yesterday), the value almost totally lies in the
> subtle play with form and the resulting ambigousness. In other words,
> if we make it possible to determine by simple logic whether a document
> is a pun or dead serious, it is useless.
>
> I am aware that my position as stated above will be possible to interpret
> as excluding. As parent of a child diagnosed with Aspergers syndrome,
> I fully well know the potential consequences of failure to interpret
> social hints.
>
> I believe that
>
> * transient failure to get a joke not is cause for "safing" jokes. The
> failure is part of the process.
>
> * the speed with which  we "unfail" and start to appreciate this art
> form is personal and differs according to our experience, background
> and intellectual skills but that the initial failure is necessary. There
> are subtler ways than policy and procedure to nudge people along when
> they persist in failing.
>
> * the Internet idea of loosely cooperating networks REQUIRES autonomous
> judgement from the people operating the system. Fostering a culture
> where IETF texts are seen as close to faultless holy scripture does
> nothing to encourage skepticism and personal responsibility.
>
> * enough has been said in this that we already are risking the sweet
> uncertainity. Accordingly, I'll try to not communicate further on this,
> and definitely not propose any procedure work.
>
> --
> Måns Nilsson primary/secondary/besserwisser/machina
> MN-1334-RIPE +46 705 989668
> I am deeply CONCERNED and I want something GOOD for BREAKFAST!
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlFib/gACgkQ02/pMZDM1cVp0wCePKf4nLxF85ZBOACv1itL0G8s
> pDwAoKPsjMy06MZRr2eMHiOegi5vCs/g
> =UNMB
> -END PGP SIGNATURE-
>

Re: Gen-ART review of draft-ietf-savi-threat-scope-07

[Russ Housley]

David:

Thanks for your efforts on this document.  Your first review was in May 2011, 
and the document has improved greatly for you continued pushing on the concerns.

Russ


On Apr 3, 2013, at 1:04 PM, Black, David wrote:

> The -07 version of this draft resolves all of the issues raised by the Gen-ART
> review of the -06 version.  Discussion of the review with the authors has
> resulted in a common understanding that there is no need for additional text
> on statically allowing all source addresses through all links in a set of
> teamed/aggregated links - that's at best "nice to have" for this draft, but
> not essential.
> 
> Thanks,
> --David
> 
>> -Original Message-
>> From: Black, David
>> Sent: Monday, March 25, 2013 9:04 PM
>> To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org
>> Cc: Jean-Michel Combes; Ted Lemon; s...@ietf.org; Black, David; ietf@ietf.org
>> Subject: Gen-ART review of draft-ietf-savi-threat-scope-06
>> 
>> 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 wait for direction from your document shepherd or
>> AD before posting a new version of the draft.
>> 
>> Document: draft-ietf-savi-threat-scope-06
>> Reviewer: David L. Black
>> Review Date: March 27, 2013
>> IESG Telechat Date: (if known)
>> 
>> Summary: This draft is on the right track, but has open issues, described in
>> the review.
>> 
>> Looking at the original Gen-ART review of the -05 draft and checking the 
>> diffs
>> between -05 and -06, the issues raised by that review have only been 
>> partially
>> addressed:
>> 
>>> There is no discussion of link teaming or aggregation (e.g., via LACP); this
>>> may affect source address validation functionality by requiring the same
>>> validation checks on all aggregated ports.  An important case to discuss
>>> is where the aggregated host links are connected to ports on different
>>> switches (e.g., in an active/passive configuration).
>> 
>> This is partially addressed on 4.1.2 (new section in -06), but only in terms
>> of moving validation state when something like LACP reconfigures.  This has a
>> couple of shortcomings:
>> a) the alternative of statically  allowing all source addresses through all
>>  teamed/aggregated links (decouples SAVI state from link
>> teaming/aggregation
>>  state) should also be mentioned, and
>> b) the new text implies that LACP is the only way to cause this situation -
>> it's
>>  not, so LACP should be used as an example.  VRRP is another example.
>> 
>>> (1) Some of the software switch implementations are single instance switches
>>> whose implementation is distributed across multiple physical servers.  This
>>> results in concerns similar to the link aggregation discussion above.
>> 
>> I don't think this has been addressed, but the notion of single-instance
>> switches
>> could be added to the generalization of the new text in 4.1.2.
>> 
>>> (2) Live migration of virtual machines among physical servers causes
>>> relocation of MAC addresses across switch ports.  A so-called "gratuitous
>> ARP"
>>> is often used to inform the network of the MAC address move; port-based
>>> source address validation information needs to move in response to such
>> ARPs.
>>> 
>>> (3) MAC address relocation is also used as a failure recovery technique; the
>>> surviving hardware element (e.g., host in a cluster) takes over the MAC
>>> addresses of the failed hardware; like the previous case, a "gratuitous ARP"
>>> is a common means of informing the network that the MAC address has moved,
>>> and source address validation information needs to move in response to it.
>>> 
>>> Minor issues:
>>> 
>>> There doesn't seem to be much discussion of dynamic network reconfiguration,
>>> which may change traffic egress points.  VRRP may be a useful example to
>>> discuss beyond the typical routing protocol updates to forwarding tables.
>> 
>> A paragraph has been added to 5.2.3 to address all three of the above
>> concerns.
>> I guess that's ok, but I would have liked to see some text pointing out that 
>> a
>> MAC move can be detected by the switches and used to update SAVI state about
>> which port(s) a MAC is accessed through.
>> 
>> Thanks,
>> --David
>> 
>>> -Original Message-
>>> From: Black, David
>>> Sent: Friday, May 13, 2011 1:03 AM
>>> To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-
>> a...@ietf.org
>>> Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko;
>>> s...@ietf.org
>>> Subject: Gen-ART review of draft-ietf-savi-threat-scope-05
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>> .
>>> 
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>> 
>>> Document: draft

Re: Sufficient email authentication requirements for IPv6

[John Levine]

>Quoting Nathaniel Borenstein  [1]:
>
>   "One man's blacklist is another's denial-of-service attack."
>
>Email reputation services have a bad reputation.

They have a good enough reputation that every non-trivial mail system
in the world uses them.  They're not all the same, and a Darwinian
process has caused the best run ones to be the most widely used.

There seems to be a faction that feel that 15 years ago someone once
blacklisted them and caused them some inconvenience, therefore all
DNSBLs suck forever.  I could say similar things about buggy PC
implementations of TCP/IP, but I think a few things have changed since
then, in both cases.

R's,
John

Re: Gen-ART review of draft-ietf-savi-threat-scope-07

[Ted Lemon]

On Apr 9, 2013, at 6:36 PM, Russ Housley  wrote:
> Thanks for your efforts on this document.  Your first review was in May 2011, 
> and the document has improved greatly for you continued pushing on the 
> concerns.

Can we take this to mean that the concerns expressed in your now-deprecated 
DISCUSS have been successfully addressed?

Re: [OPSEC] Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

[Fernando Gont]

Hi, Brian,

My apologies for the delay in my response. Please find my comments
in-line...


On 04/02/2013 06:45 AM, Brian E Carpenter wrote:
> Fernando,
> 
> Rather than repeating myself, I'll suggest a change to the Introduction
> that would (IMHO) improve the message:
> 
> OLD:
> 
> 1.  Introduction
> 
>Most general-purpose operating systems implement and enable native
>IPv6 [RFC2460] support and a number of transition/co-existence
>technologies by default.  For cases in which the corresponding
>devices are deployed on networks that are assumed to be IPv4-only,
> 
> NEW:
> 
> 1.  Introduction
> 
>Most general-purpose operating systems implement and enable native
>IPv6 [RFC2460] support and a number of transition/co-existence
>technologies by default [RFC6434]. Support of IPv6 by all nodes is
>intended to become best current practice [RFC6540]. As a result,
>networks will need to plan for and deploy IPv6 and its security
>mechanisms. Some enterprise networks might, however, choose to delay
>active use of IPv6. For networks that are assumed to be IPv4-only,

I've checked with a few folks, and it seems that the suggested text
would make everyone happy, except for the sentence that says "As a
result, networks will need to plan for and deploy IPv6 and its security
mechanisms.", on the basis that this is not the document to make a case
for v6 deployment. The suggestions has been to remove that sentence, and
apply the rest of your proposed text (or, alternatively, to tone down
that sentence).

For simplicity sake (and because I'm not sure how one would tone that
one down), my suggestion would be to apply you proposed text, modulo
that sentence.

Would that be okay with you? -- If not, please do let me know, so that
we can try to find a way forward that keeps everyone happy.

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: Sufficient email authentication requirements for IPv6

[SM]

Hi Doug,
At 12:22 09-04-2013, Douglas Otis wrote:
In full agreement with Nathaniel.  Avoiding unfair collateral 
blocking is why source domain authentication, not authorization, is vital.


I doubt that what's mentioned in the subject line will not face 
strong resistance within an IETF context.  However, as it seems 
important I suggest submitting the proposal as an Internet-Draft and 
getting IETF participants to support for the proposal.  I suggest 
taking the discussion at 
http://www.ietf.org/mail-archive/web/asrg/current/msg16672.html into account.


Regards,
-sm