secdir review of draft-ietf-csi-send-cert-03
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a certificate profile for use in the Secure Neighbor Discovery protocol for IPv6. Starting from the RPKI cert profile, it adds some refinements for SEND, e.g., EKUs that authorize the subject to act in certain roles within SEND (router, proxy, host). Overall, the document is reasonably well-written, but could benefit from more precision in its use of terminology. There are a few points (noted below) where certificate processing rules are unclear. With regard to the security considerations in particular, I would prefer if they stated the risks slightly more directly (text is suggested below), but in general, the authors address the major security concerns. Detailed comments follow. --Richard Sec 2 Para 1 Suggest changing "authority over an" to "authorization to advertise an". Sec 2 Para 2 Suggest rewording to avoid referring to SIDR WG (which is temporary). Suggested text: "The Resource Public Key Infrastructure (RPKI) is the global PKI that attests to allocation of IP address space." Also, instead of "SIDR certificate profile", use "RPKI certificate profile". Sec 2 Para 3, General I'm confused by the several instances of the phrase "address owner" in the document (the phrase is not used in RFC 3971). Do you mean "host"? Sec 3 Para "End Entity" This definition is incorrect. Refer to RFC 4949. Sec 4 Para 1 The RPKI profile should be applied in *addition* to the RFC 3971 profile, right? Please clarify. Sec 4 Para 2 Why can there only be one RFC 3779 extensions? It doesn't seem like there's a risk in including IPv4 space (e.g., for a dual-stack router that was vouching for IPv4 space in some other application?), or multiple extensions for IPv6 space. Sec 5 This section should note that another deployment model (arguably the most likely) is a combination of these two, in which most resources are certified under the global RPKI, while some (e.g., ULAs) are certified under local TAs. Sec 6 Para 4 The requirement for RFC 3779 extension seems to contradict the use of ETAs as Trust Anchor Material, i.e., the last sentence of the first paragraph in this section. Sec 7 Para "The inclusion of ..." et seq. It would be helpful for the document to specify how prefix matching should be done when validating these extensions. Which of the following should the RP use? -- Exact matching -- Subset matching (RA within cert) -- The weird subset/intersection algorithm that RFC 3971 defines What prefix should the RP be matching against from SEND, per EKU? E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should match against any RAs the router emits. It may be useful to refer to the ROA validation document [draft-ietf-sidr-roa-validation]. Sec 7 Para "Certificate-using applications..." Suggest changing "Certificate-using applications" to "Relying Parties". Sec 8 This section correctly identifies the main risk with these extensions (namely, issuance of certs with incorrect roles assigned), but it would be helpful to clarify the application-level impact of these bad issuances. Suggested text: " Since a SEND certificate attest that its subject is authorized to play a given role in the SEND protocol, certificates that contain incorrect EKU values can enable some of the same attacks that SEND was meant to prevent. For example, if a malicious host can obtain a certificate that authorizes it to act as a router for a given prefix, then it can masquerade as a router for that prefix, e.g., in order to attract traffic from local nodes. " ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
Which hotel was it? Two of the hotels (NH Maastricht and Crowne Plaza Maastricht) show two sets of rates, a refundable rate and a non-refundable rate. It says that if you choose the non-refundable rate your credit card will be charged immediately. Janet ietf-boun...@ietf.org wrote on 05/18/2010 02:55:24 PM: > [image removed] > > Re: Advance travel info for IETF-78 Maastricht > > Behcet Sarikaya > > to: > > Marshall Eubanks > > 05/18/2010 02:55 PM > > Sent by: > > ietf-boun...@ietf.org > > Cc: > > IETF Discussion > > Please respond to Behcet Sarikaya > > > > > Hi, > > I noticed that IETF 78 Hotel that I made reservation already > > charged my credit card for the whole duration of my stay. > > > > > > > Charged, or "authorized" ? (In the authorized case, the charge will > > generally show up as "pending".) > > I saw it as a fixed charge in my credit card statement not as pending. > > > Frequently authorization is ~ 150% of > > the nominal room charge, but doing it in advance seems quite > > excessive. > > You mean one night's charge? In my case it was for the whole week. > > I am hoping that Ray will do something. > > Regards, > > Behcet > > > > ___ > 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
IETF Meeting Room Space Availability Policy
All, The IAOC has adopted a Meeting Room Policy regarding the use of available IETF meeting room space, the approval process, and charges for the rooms and services based upon the category of the group requesting the room. An IETF Meeting requires nearly 4,000 square meters in meeting space for working group sessions, the NOC, terminal room, offices, storage and other specific uses. Occasionally not all of the space is needed for every part of the meeting, or the IETF controls additional space. When there is available space, and space is available in non-meeting hours, the IAOC desires to make it available in a manner that considers the work of the IETF, fairness, and its expenses. The policy can be found on the IAOC site at: http://iaoc.ietf.org/docs/Meeting-Rooms-Policy-05-13-10.txt It will also be posted with each meeting, such as at: http://www.ietf.org/meeting/78/index.html Requests should be made as soon as they are known. Thanks Ray IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
> > Hi, > I noticed that IETF 78 Hotel that I made reservation already > charged my credit card for the whole duration of my stay. > > > Charged, or "authorized" ? (In the authorized case, the charge will > generally show up as "pending".) I saw it as a fixed charge in my credit card statement not as pending. > Frequently authorization is ~ 150% of > the nominal room charge, but doing it in advance seems quite > excessive. You mean one night's charge? In my case it was for the whole week. I am hoping that Ray will do something. Regards, Behcet ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)
> "Marc" == Marc Blanchet writes: Marc> we had a discussion about the same subject: i.e. should we Marc> restrict the scope to a specific set of documents to Marc> review/update/... or do we keep some provision for other Marc> documents coming in the stream that require "help" of the Marc> newprep. I was arguing for the latter. To me, what you are Marc> talking about is the latter. Obviously, some people wanted the Marc> charter to be restrictive in order to not go all over the Marc> place, and I agree in principle... However, this work is kinda Marc> horizontal: touches many areas, so having a more large view of Marc> the problem space and documents that depends on this newprep Marc> work would be very valuable to the working group Marc> work. Therefore, I'm more for opening a bit the charter for Marc> the cases like the ones you are talking about. I'm happy with a restrictive charter so long as the work areas identified today (including mine) are included. I'm happy drawing a line in the sand and saying "here's what we'll touch first," so long as people who bring up items now get included. I'd probably be happier with a reasonably open charter. I'm not at all happy if the items I bring up or other similar items brought up now are excluded. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
At 12:48 14-05-10, The IESG wrote: This is an update to the Last Call that is currently in progress. The IESG is considering the following Statement on the Day Pass Experiment. The IESG plans to make a decision in the next few weeks on Is the IESG referring to the "One-day Guest Pass Experiment"? [1] So far, only one person has registered for the IETF 78 meeting with a day pass, and that person has not paid yet. 11% of the people in Hiroshima used the "day pass". There were two NomCom members who used the "day pass". The NomCom report [2] submitted by Mary Barnes mentions that there was "an issue with regards to individuals lobbying for specific nominees. In addition, there were attempts to exert undue influence on the process by suggesting that NomCom members should support a specific nominee due to business relationships between the NomCom member's sponsor and the organization exerting the pressure". I could not find any reference to an issue in regards to the "day pass". to address IETF participants that make use of a day pass. An update to RFC 3777 will be needed to address this situation if at the end of the experiment the IAOC decides to make day passes a regular meeting registration alternative. This statement provides guidance until an Where is the experiment documented? How long will the experiment be run? How long will this IESG statement be applicable? I leave it to the IETF Community to appreciate the message posted by Robert Elz [3]. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06415.html 2. http://www.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt 3. http://www.ietf.org/mail-archive/web/ietf/current/msg61729.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Taxicabs (was: Re: Advance travel info for IETF-78 Maastricht)
(subject line adjusted -- this has long ago ceased to be Maastricht-specific in any way) --On Tuesday, May 18, 2010 13:11 -0400 Phillip Hallam-Baker wrote: >... > Mandating credit card acceptance should in theory merely > reduce the amount the rent that the medallion owners can > extract from the drivers and thus not affect the proportion of > the fares the drivers receive. The reason the drivers do not > like them is that they make their earnings more transparent to > the medallion owners and thus enable them to maximize their > rent extraction. A closely-related reason the drivers don't like them is concern that credit card charges leave a paper trail that can, in principle, make it harder to distort income for taxation purposes. None of this makes the comments of Ted and others less true. The equation is, as usual, a little more complicated than credit card charges or perceived "float" alone. There is no "the reason", only a whole complex of reasons, some of which may be more important to some drivers in some areas than others. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Stringprep after IDNA2008 WG (newprep)
Hi. I think there are two items that should be considered with the scope of this working grou. The first is RFC 4282. RFC 4282 section 2.4 discusses internationalization strategies based on stringprep and IDNA2003. It does not define its own profile. Apparently, in addition to all the reasons you would probably want to update anything based on IDNA 2003, RFC 4282 does not meet the needs of the implementor community. One proposal for addressing RFC 4282 is draft-dekok-radext-nai-01.txt I think any proposal in this space will require both help from newprep and from the radext/aaa community. Based on my past experience in emu, the aaa community, like the rest of the IETF, can use i18n help. Secondly, I'd like to see Kerberos considered as newprep thinks about saslprep. Kerberos's formal internationalization is confused and spotty as a specification level. At the last time that there was active work on this within krb-wg, the plan was to use saslprep; a prior stringprep profile was explicitly dropped in favor of saslprep. For this reason, I think that considering and working with the Kerberos community would be really useful. I'm not sure if either of these needs an explicit charter change; I suspect the first probably does and the second may not. However I think these both are well within the spirit of the proposed charter. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Draft IETF Meeting Calendar 2014 - 2017
All; The IAOC proposes the following IETF meeting dates for the years 2014 through 2017 and requests your feedback before adopting a final calendar. Meeting dates are adopted to avoid conflicts with other organizations when known and possible. The IETF's policy with regard to clashes can be found here: http://www.ietf.org/meeting/clash-list.html For the most part, only the IEEE 802 has calendar dates this far in advance and they are also reflected below. Later this year the IAOC will select the regional target for each of these meeting dates. The goal at this point is to set the dates. Proposed IETF Meeting Calendar 2014 IEEE Mar 16 - 21 IETF Mar 2 - 7 IEEE Jul 13-18 IETF Jul 20 - 25 IEEE Nov 2 - 7 IETF Nov 9 - 14 2015 IEEE Mar 8 - 13 IETF Mar 22 - 27 IEEE Jul 12 - 17 IETF Jul 19 - 24 IEEE Nov 8 - 13 IETF Nov 1 - 6 2016 IEEE Mar 13 - 18 IETF Mar 27 - Apr 1 IEEE Jul 10 - 15 IETF Jul 17 - 22 IEEE Nov 6 - 11 IETF Nov 13 - 18 2017 IEEE Mar (not set) IETF Mar 26 - 31 IEEE Jul (not set) IETF Jul 16 - 21 IEEE Nov (not set) IETF Nov 12 - 17 Thank you for your feedback. This is version -00. There will be several more. Ray ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
Its all about money, but not necessarily the fees. The cabs in most parts of the US are run through a licensed monopoly scheme which is frequently corrupt. In NYC the guy who drives the cab gets a pittance while the medallions sell for huge sums. Raising taxi fares does not improve the pay of the drivers, the surplus all goes to the controllers of the monopoly. Mandating credit card acceptance should in theory merely reduce the amount the rent that the medallion owners can extract from the drivers and thus not affect the proportion of the fares the drivers receive. The reason the drivers do not like them is that they make their earnings more transparent to the medallion owners and thus enable them to maximize their rent extraction. It may not appear to be IETF related, but there are many, many circumstances where deployment of a security protocol will be blocked because similar effects are at work under the covers. On Mon, May 10, 2010 at 10:15 AM, Nathaniel Borenstein wrote: > I think it's really all about the credit card fees. Cab drivers, at least in > the US, are often on a small enough margin, with high fixed costs, that the > few percent taken by the card companies can be the difference between a > worthwhile and a wasted fare. Next time a cabbie doesn't want your card, > offer him 10% more and watch him change his tune. > > > On May 9, 2010, at 11:01 PM, ty...@mit.edu wrote: > >> On Sun, May 09, 2010 at 06:31:14PM -0700, Dan Harkins wrote: >>> >>> I have had cab drivers in the US try to force me to pay cash >>> in similar situations. Saying they don't accept credit cards and >>> then, when I say that's all I have, telling me how much longer >>> it will take to get me out of their cab if I really want to use >>> a credit card. In these cases I just kept insisting on the card >>> and eventually (like, within a minute) all was settled the way I >>> wanted it to be settled: with the credit card. >>> >>> It may seem anachronistic to some, but the rule of law does >>> apply in the US today and asking to have a police officer settle >>> the dispute is a good way of getting quick resolution. If all >>> else fails maybe taking a picture or two (driver and taxi permit) >>> with a camera phone might tend to elicit a change of attitude. >> >> I talked to a cab driver in Boston, and he's not very happy with >> credit cards, because he was forced to use a new system for credit >> cards, and it takes what he considered an unfairly large percentage >> when customers pay by credit cards. After learning that, I've >> generally tried to pay cash when I can, and if I really have to pay by >> credit card, I'll give a bigger tip as compensation. >> >> - Ted >> ___ >> 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 > -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Charlie, Thank you for your review and comments. Please note that the WG has spent a lot of time on this topic of same vs. separate BCEs. We have had two consensus calls on it after discussion at a meeting. As you have seen from the thread, the chairs did see rough consensus to move on (specifically, please see http://www.ietf.org/mail-archive/web/netlmm/current/msg05551.html). Explicit text on this topic was also provided to our AD along with the shepherding write-up: "There have been some disagreements on the approach used to solve the collocated LMA and HA case in the document. The present approach uses logically separate binding cache entries for the LMA and HA, which is based on consensus. Some members of the WG strongly preferred the approach of having the same binding cache entry for the LMA and HA - however, the approach needed additional solutions to address race conditions that arose from it and it did not gain consensus in the WG. It should be noted that this was not raised by anyone in the WG during WGLC of the document and the document as a whole had strong consensus to be published." As you see, the disagreement has been noted and we've moved on. We don't plan on re-opening this discussion at this time. Let's resolve any remaining issues with the document. Thanks, Vidya -Original Message- From: netlmm-boun...@ietf.org [mailto:netlmm-boun...@ietf.org] On Behalf Of Charles E. Perkins Sent: Monday, May 17, 2010 9:49 AM To: Giaretta, Gerardo Cc: net...@ietf.org; ietf@ietf.org Subject: Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC Hello Gerardo, Comments below... On 5/17/2010 8:17 AM, Giaretta, Gerardo wrote: > You have one comment on the recommendation in the draft to have > separate binding cache entries. This was extensively discussed > in the NETLMM WG and also at the IETF Dublin meeting. There was > a mailing list discussion after that in September/October 2008 > which led to the conclusion in the current version of the draft. > > You can find more information in the archives at: > http://www.ietf.org/mail-archive/web/netlmm/current/msg05533.html Thanks for that link. It was most enlightening, especially in the context of the ensuing discussion. Having reviewed the latter, it seems to me quite likely that the consensus call was (at least) premature. For instance: > I object to this. There was absolutely no consensus on this for > you guys to decide. There were clarifying questions that people > had on what exactly you meant by multi-homing. You didn't respond > to any of those emails. and > I am sorry, but I thought the discussion was either incomplete or did > not steer towards one particular way or the other. For instance, I > didn't get a clear answer for my question on why there would be a single > BCE when two different interfaces are in use. Could you please clarify? I could go on. And, without naming names, I want to emphasize that the abovementioned objections were made by some real experts. Do you have any links to discussion that _supports_ the consensus call? Furthermore, I still suggest (constructively) that _at the minimum_ a system architect ought to be allowed to have the design freedom to identify the two mobile node identities (and thus the relevant BCEs). What is the downside of enabling new systems to offer such obvious improvements? Or, would it be better to start writing the ...bis document already (just kidding...)? Regards, Charlie P. ___ netlmm mailing list net...@ietf.org https://www.ietf.org/mailman/listinfo/netlmm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Hello Gerardo, Comments below... On 5/17/2010 8:17 AM, Giaretta, Gerardo wrote: You have one comment on the recommendation in the draft to have separate binding cache entries. This was extensively discussed in the NETLMM WG and also at the IETF Dublin meeting. There was a mailing list discussion after that in September/October 2008 which led to the conclusion in the current version of the draft. You can find more information in the archives at: http://www.ietf.org/mail-archive/web/netlmm/current/msg05533.html Thanks for that link. It was most enlightening, especially in the context of the ensuing discussion. Having reviewed the latter, it seems to me quite likely that the consensus call was (at least) premature. For instance: I object to this. There was absolutely no consensus on this for you guys to decide. There were clarifying questions that people had on what exactly you meant by multi-homing. You didn't respond to any of those emails. and I am sorry, but I thought the discussion was either incomplete or did not steer towards one particular way or the other. For instance, I didn't get a clear answer for my question on why there would be a single BCE when two different interfaces are in use. Could you please clarify? I could go on. And, without naming names, I want to emphasize that the abovementioned objections were made by some real experts. Do you have any links to discussion that _supports_ the consensus call? Furthermore, I still suggest (constructively) that _at the minimum_ a system architect ought to be allowed to have the design freedom to identify the two mobile node identities (and thus the relevant BCEs). What is the downside of enabling new systems to offer such obvious improvements? Or, would it be better to start writing the ...bis document already (just kidding...)? Regards, Charlie P. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
Thanks Charlie for the comments and sorry for the delay in addressing them. Most of your comments are editorial and I can produce a new revision since I received also comments from Gen-Art review. You have one comment on the recommendation in the draft to have separate binding cache entries. This was extensively discussed in the NETLMM WG and also at the IETF Dublin meeting. There was a mailing list discussion after that in September/October 2008 which led to the conclusion in the current version of the draft. You can find more information in the archives at: http://www.ietf.org/mail-archive/web/netlmm/current/msg05533.html Thanks Gerardo > -Original Message- > From: netlmm-boun...@ietf.org [mailto:netlmm-boun...@ietf.org] On > Behalf Of Charles E. Perkins > Sent: Monday, May 03, 2010 1:45 PM > To: ietf@ietf.org; net...@ietf.org > Subject: Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions > (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to > Informational RFC > > > Hello folks, > > Here is a first installment of comments on the > abovementioned Internet Draft. > > > > > > The list is not > >meant to be exhaustive. Moreover, this document presents and > >identifies all issues pertained to these scenarios and discusses > >possible means and mechanisms that are recommended to enable > them. > > These two sentences clash, even though it's true > a logician can make sense of them. > > Figure 2 is out of order. > > The captions to all figures ought to be centered. > > >The following figure illustrates an example > > "following figure" --> "Figure 3 below" > > >of this scenario, where the MN is moving from an access network > >where PMIPv6 is supported (i.e. MAG functionality is supported) > >to a network where PMIPv6 is not supported (i.e. MAG > >functionality is not supported by the AR). This implies that the > >home link of the MN is actually a PMIPv6 domain. > > It's true that the figure is drawn this way, but there > might be an unwanted inference that such heterogeneous > network support _always_ requires PMIP support in the > home network. I reckon that was not intended. > > >This scenario is very similar to other hierarchical mobility > >schemes, including a HMIPv6-MIPv6 scheme. > > Please make the relevant citations. > > >Note that a race condition where the MN registers the > >CoA at the HA before the CoA is actually bound to the MAG at the > >LMA is not possible. > > Better: > Note that there is no race condition whereby the MN registers > the CoA at the HA before the CoA is actually bound to the MAG > at the LMA. > > > In particular, based on the base > > specification [RFC3775], > > Better: > In particular, based on [RFC3775], > Or, even better: > In particular, the base >specification [RFC3775] doesn't require the MN to include > any >identifier, such as the MN-ID [RFC4283], in the Binding > Update >message other than its Home Address. > > > As described in > > [RFC4877], the identifier of the MN is known by the Home > Agent > > after the IKEv2 exchange, but this is not used in the MIPv6 > > signaling, nor as a lookup key for the binding cache. > > Which naturally leads to the question, "Why Not?"! > This is a problem that really needs to be fixed. > > > Therefore PMIPv6 and MIPv6 will > > always create two different binding cache entries in the HA/ > > LMA which implies that the HA and LMA are logically > separated. > > I think this statement is too strong. If I were building such > a system, my HA/LMA would probably be aware that the MN-ID was > tightly bound to the MN-HoA. So I would almost certainly make > sure that there was a single binding cache entry. > > If you replace "will always" by "might well", and "are" > by "might be", then I would agree. > > Also, it's unfortunate if the typography separates "HA" from > "LMA" in "HA/LMA". > > >* When the mobile node moves from a MIPv6 foreign network to the > > PMIPv6 home domain, the MAG registers the mobile node at the > > LMA by sending a Proxy Binding Update. Subsequently, the LMA > > updates the mobile node's binding cache entry with the MAG > > address and the MAG emulates the mobile node's home link. > > Upon detection of the home link, the mobile node will send a > > de-registration Binding Update to its home agent. It is > > necessary to make sure that the de-registration of the MIPv6 > > BU does not change the PM
open protocols x proprietary protocols
Hello, I have a question about how to open protocols x proprietary protocols, and I think that the IETF can help me. the open protocols can I study them and learn how they work. However, proprietary protocols, it is possible to study them? way they operate, their packages and other features?. For example, if I wanted to write a book about an article or book on some proprietary protocols, I'd have to ask permission for the patent holders of their protocols? Thanks, Victor -- “Encarada do ponto de vista da juventude, a vida parece um futuro indefinidamente longo, ao passo que, na velhice, ela parece um passado deveras curto. Assim, a vida no seu início se apresenta do mesmo modo que as coisas quando as olhamos através de um binóculo usado ao contrário; mas, ao seu final, ela se parece com as coisas tal qual são vistas quando o binóculo é usado de modo normal. Um homem precisa ter envelhecido e vivido bastante para perceber como a vida é curta”. (Poema de Arthur Schopenhauer) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On May 18, 2010, at 11:03 AM, Behcet Sarikaya wrote: Hi, I noticed that IETF 78 Hotel that I made reservation already charged my credit card for the whole duration of my stay. Charged, or "authorized" ? (In the authorized case, the charge will generally show up as "pending".) Frequently authorization is ~ 150% of the nominal room charge, but doing it in advance seems quite excessive. Marshall Should I be thankful because euro is low these days or complain about it? Thx. Behcet ___ 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
Advance travel info for IETF-78 Maastricht
Hi, I noticed that IETF 78 Hotel that I made reservation already charged my credit card for the whole duration of my stay. Should I be thankful because euro is low these days or complain about it? Thx. Behcet ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre-evaluation-05
Hi Roni, At 05:49 18-05-10, Roni Even wrote: I was referring to section 4.1.2 of RFC 2026 "The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed." RFC 2821 was published as Proposed Standard. RFC 5321 is the Draft Standard and it obsoletes RFC 2821. The text you quoted from Section 4.1.2 is about advancement to Draft Standard, i.e. from RFC 2821 to RFC 5321. If it is the consensus of the IETF, the revision of RFC 5321 will be the Internet Standard (Full Standard) and it will replace STD 10. Section 4.1.3 is applicable. And now, the obligatory quote: "Ed Jankiewicz pointed out that the Vatican named more saints this year [2009] than the IETF named Full Standards. The Vatican doesn't make saints, they recognize saints on their own merits." Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
One final message from me on this topic, then I'm done ... Date:Mon, 17 May 2010 08:10:01 +0200 From:Eliot Lear Message-ID: <4bf0ddb9.60...@cisco.com> | but I do accept that they have the authority to make such a statement, | if rough consensus could have been shown. I didn't ever say that the authority wasn't there, in fact, if I recall correctly, in my original message I think I explicitly agreed that the IESG has the ability to issue such statements when circumstances warrant. What I said was that they shouldn't here. There are two reasons. One is the conflict of interest, the nomcom is a topic, where (just possibly extreme emergency excepted - which is really hard to imagine here) the IESG should always ensure the full IETF procedure is carried out. I said enough about this before so I won't say more here. [Aside: nomcom procedure as I recall it has always been that if there's an area of ambiguity or doubt, the nomcom chair makes a ruling, if there was an urgent problem here that needed fixing, that would be the way to do it ...] Second, is that there is no need for any kind of statement here, from anyone. If the IESG simply did nothing, everything would continue working just the way it has in the past, nothing would break, or fail to work, in any way at all, nothing that needs a quick fix anyway, and there is no ambiguity that needs clearing up. I know there are people who believe that the requirements for nomcom membership should change, or should be interpreted differently than they have been, or now that it is practically possible in some cases to interpret things differently than it has been in the past, we should do do - and all of that is fine, I don't agree with all of that, but they're all legitimate viewpoints - but they all represent changes to the process, and should be achieved via the working group route, and not via the back door method of an IESG statement changing the rules. I have seen the argument that RFC3777 always meant "attended for the whole IETF meeting" and not just "attended" as it says. I'll explain more below why I think this is an incorrect interpretation, but for now let's just accept that is what 3777 means, and that (because of that) the IESG's statement is just a clarification, because attendance on a day pass cannot mean "attended for all 5 days" (I'll explain below why that's incorrect too, but let's ignore that problem for now). I would note that in the revised IESG statement, even the IESG agree that what they are doing is changing the rules - the only justification for allowing day pass attendees from the past 2 meetings to volunteer, and not those for future meetings, is that the rules previously allowed them, but they are not to allow them any more. If 3777 really meant "attended the whole meeting" then the original IESG statement would have been the way to go - people who attended one of the last two meetings on a day pass, clearly did not attend the whole meeting, and if 3777 does require attendance at the whole meeting, they should not be eligible. By making the change made in the revised statement, the IESG is making it clear that they are changing the eligibility rules for the nomcom - that's something only a WG should do. But if "attended the whole meeting" is what 3777 really means, then the IESG statement doesn't go far enough (not the current version, nor the original), we know from Rus Housley's message ... hous...@vigilsec.com said (Sat, 15 May 2010 11:15:03 -0400): | Attendance was determined by the presence of a check-in date. That is, the | person's registration packet was picked up at the registration desk. that the secretariat have the ability to determine who was actually present, and what's more, when they were first there (the check-in date mentioned.) Even if they didn't have that now, we could easily ask them to collect that information for the future, as (just as been done in the modified IESG statement), if we are actually making a change, no matter what change is made, or how - via WG or IESG statement, we don't want to apply retroactively, only to the future. With this information, we can (or could) disqualify from counting towards nomcom eligibility anyone who hasn't collected their badge by (say) 11:00 (11am) on the Monday morning - if the intent is that the volunteer must have attended all 5 days, then certainly anyone who wasn't there Monday morning (maybe pick some other time instead of 11:00 - that's the kind of issue a working group could hash out, of course) was not there for the full 5 days, and we would know that just as certainly as we do for someone who attended via a day pass. Now we have excluded everyone who arrived too late to have garnered enough IETF experience to be a nomcom volunteer, we just need some way to detect all of those who leave too early - this one the secretariat would currently be unable to handle I suspect, but we could ask them to collect
RE: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre-evaluation-05
OK Thanks Roni > -Original Message- > From: Tony Hansen [mailto:t...@att.com] > Sent: Tuesday, May 18, 2010 3:29 PM > To: Roni Even > Cc: dcroc...@bbiw.net; 'General Area Review Team'; draft-ietf-yam- > 5321bis-smtp-pre-evaluation@tools.ietf.org; ietf@ietf.org > Subject: Re: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre- > evaluation-05 > > The IESG members I know are quite familiar with the requirements of > 2026 > and are expecting a deployment analysis for going to full standard, but > not a repeat of the interoperability analysis that was already done > years ago. > > Tony Hansen > YAM WG co-chair > > On 5/18/2010 2:37 AM, Roni Even wrote: > > Hi, > > I am not the expert on the requirements and it will be up to the > IESG. I > > think that when you go to full standard you need to take out any > commands > > and tags that are not used by interoperable products. If that was > done > > previously than it is OK but I suggest that you mention it to the > IESG. > > Roni Even > > > > > >> -Original Message- > >> From: Dave CROCKER [mailto:d...@dcrocker.net] > >> Sent: Tuesday, May 18, 2010 12:47 AM > >> To: Roni Even > >> Cc: 'General Area Review Team'; draft-ietf-yam-5321bis-smtp-pre- > >> evaluation@tools.ietf.org; ietf@ietf.org > >> Subject: Re: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre- > >> evaluation-05 > >> > >> > >> > >> On 5/17/2010 12:07 PM, Roni Even wrote: > >> > >>> In general it looks good, what I did not see is a summary of an > >>> > >> analysis > >> > >>> that evaluate if all commands and tags are used in interoperable > >>> > >> products > >> > >> > >> That's correct. The working group has been diligent in restricting > its > >> work to > >> the chartered scope, namely satisfying only requirements for full > >> Internet Standard. > >> > >> I believe your comment is, instead, applicable for Draft. RFC 5321 > >> satisifed > >> that quite a long time ago, since it is already at Draft status. > >> > >> d/ > >> -- > >> > >> Dave Crocker > >> Brandenburg InternetWorking > >> bbiw.net > >> > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre-evaluation-05
Hi, I was referring to section 4.1.2 of RFC 2026 "The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed." Roni Even > -Original Message- > From: SM [mailto:s...@resistor.net] > Sent: Tuesday, May 18, 2010 12:37 PM > To: Roni Even > Cc: ietf@ietf.org > Subject: RE: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre- > evaluation-05 > > Hi Roni, > At 23:37 17-05-10, Roni Even wrote: > >I am not the expert on the requirements and it will be up to the IESG. > I > > I don't know whether you are pondering what I'm pondering. Do you > mean that it is up to the IESG to define what the requirements are? > > >think that when you go to full standard you need to take out any > commands > >and tags that are not used by interoperable products. If that was done > >previously than it is OK but I suggest that you mention it to the > IESG. > > Quoting Section 4.1.2 of RFC 2026: > >"A Draft Standard is normally considered to be a final > specification, > and changes are likely to be made only to solve specific problems > encountered." > > According to Section 4.1.3 of RFC 2026, an Internet Standard, or what > is sometimes referred to as Full Standard, is a "specification for > which significant implementation and successful operational > experience has been obtained". > > The YAM WG Charter states that: > > "The working group does not intend to revise the actual protocols >in any way and will avoid document changes that might even >accidentally introduce protocol changes, destabilize a protocol, >or introduce semantic or syntactic changes." > > "If an existing protocol implementation is conforming to the Draft > Standard version of the protocol specification, it must also be > conforming to the resulting Full Standard version." > > the "success in the WG requires that there be a good-faith > commitment by both its participants and the IESG to avoid seeking > changes that (a) do not contribute in a substantial and substantive > way to the quality and comprehensibility of the specification, or > that (b) force a change to the existing protocol." > > There is an expectation that the IESG is aware of the requirements > specified in RFC 2026 and what is written in the YAM WG Charter. > > Regards, > -sm > > P.S. If there are any false expectations, the IETF will have to > review the biological recombinant algorithmic intelligence nexus. :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre-evaluation-05
The IESG members I know are quite familiar with the requirements of 2026 and are expecting a deployment analysis for going to full standard, but not a repeat of the interoperability analysis that was already done years ago. Tony Hansen YAM WG co-chair On 5/18/2010 2:37 AM, Roni Even wrote: Hi, I am not the expert on the requirements and it will be up to the IESG. I think that when you go to full standard you need to take out any commands and tags that are not used by interoperable products. If that was done previously than it is OK but I suggest that you mention it to the IESG. Roni Even -Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Tuesday, May 18, 2010 12:47 AM To: Roni Even Cc: 'General Area Review Team'; draft-ietf-yam-5321bis-smtp-pre- evaluation@tools.ietf.org; ietf@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre- evaluation-05 On 5/17/2010 12:07 PM, Roni Even wrote: In general it looks good, what I did not see is a summary of an analysis that evaluate if all commands and tags are used in interoperable products That's correct. The working group has been diligent in restricting its work to the chartered scope, namely satisfying only requirements for full Internet Standard. I believe your comment is, instead, applicable for Draft. RFC 5321 satisifed that quite a long time ago, since it is already at Draft status. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-yam-5321bis-smtp-pre-evaluation-05
Hi Roni, At 23:37 17-05-10, Roni Even wrote: I am not the expert on the requirements and it will be up to the IESG. I I don't know whether you are pondering what I'm pondering. Do you mean that it is up to the IESG to define what the requirements are? think that when you go to full standard you need to take out any commands and tags that are not used by interoperable products. If that was done previously than it is OK but I suggest that you mention it to the IESG. Quoting Section 4.1.2 of RFC 2026: "A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered." According to Section 4.1.3 of RFC 2026, an Internet Standard, or what is sometimes referred to as Full Standard, is a "specification for which significant implementation and successful operational experience has been obtained". The YAM WG Charter states that: "The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes." "If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version." the "success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol." There is an expectation that the IESG is aware of the requirements specified in RFC 2026 and what is written in the YAM WG Charter. Regards, -sm P.S. If there are any false expectations, the IETF will have to review the biological recombinant algorithmic intelligence nexus. :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [netlmm] Last Call: draft-ietf-netlmm-mip-interactions (Interactions betweenPMIPv6 and MIPv6: scenarios and related issues) to Informational RFC
I support what Vidya said about opening that one issue. However, I think we should address Charlie's other comments. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tsv-dir review Re: Last Call: draft-ietf-mext-flow-binding
Thank you for your review, Allison! Authors, please take these comments into account. My understanding about the traffic selector format is that the previously approved document is the only one that we intend to have in the standards track at the moment, and that should be referenced from this document. (While allowing a registry to remain and the possibility of other formats retained, of course.) Jari Allison Mankin kirjoitti: Review for the Transport Directorate draft-ietf-mext-flow-bindings-06.txt 2010-05-06 Allison Mankin I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they have received. Please always CC tsv-...@ietf.org if you reply to or forward this review. This draft is on the right track but has open issues, described in the review. Overview - It's interesting that flow routing keeps appearing in disparate Internet protocols. In this one, mobile nodes bind diverse CoAs to flows based on traffic selector specs. The draft is carefully generic and gives no use cases, sample policies or traffic selectors. It has a helpful example, but it is abstract. I do find three drafts that make use of flow bindings and give some picture of how they might be used. The WG has an approved standards track document specifying a binary traffic selector. The present draft doesn't reference it even informationally - is that purposeful for neutrality? The other two are individual submissions. One specifies a traffic selector for 3GPP. The final one sets out to massively extend flow binding options so that they can originate from the home agent, not only from the mobile node. This final draft presents 3G provider scenarios in which the HA creates, deletes or modifies flow bindings or uses flow binding actions, to accomplish goals such as enforcing a usage cap or ensuring that an MN uses the provider's link even when a non-provider wifi may also be available. I bring up the two individual submissions with 3G themes without any information about how they are viewed in the WG or about how they'll fare in the IETF. They do reveal ways that draft-ietf-mext-flow-bindings can be read and thus they place it in an architectural context. Comments - Lifetime - What should be done with the Lifetime field on BUs carrying flow binding options? Is it a meaningful field? Section 4.3 doesn't mention Lifetime as information that is maintained with flow bindings. If you do intend that both systems are available, time-based deletion, and non-refresh-based deletion, it needs stating (and it raises the complexity). Suggested action: write some guidance about this. Design Limits - 4.2.1.4. Traffic Selector sub-option TS Format An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and SHOULD NOT be used. This seems too small a space for traffic selector format identification. It's been my experience that any two groups that want to classify traffic specify at 3-4 (at least) similar but incompatible traffic selector formats. Instead of reserving the 0 value with a SHOULD NOT, why don't you reserve it with a MUST NOT, and conceive that in a future standards document it could be used as an extension bit to signal an expanded space? Section 5.2 The requirement that there be only one flow summary option in a binding update but that all FIDs be refreshed in that binding update, means that the upper limit for flow bindings for a MN at any one time is 128 (the length field in the option will only count this many 16 bit FIDs). This seems limiting? What if an application decides to use flow bindings in an innovative way that can make use of lots more? Suggested action: discuss why it was decided that there could be only one flow summary option. Does the WG believe that a maximum of 128 flow bindings is a good tradeoff? Priority - The draft illustrates specific uses of BID-PRI and FID-PRI. The draft is open enough that these priorities could also be used more classically as traffic priorities. I think this draft should pat itself on the back for describing a simple robust use of the PRI fields. My sense is that the dynamics of mobility and the interaction of the two sets of priorities lend themselves to complications, including priority inversion. Suggested action: write guidance that simple use of the PRI fields is envisioned to be most robust. Section 4.2 FID-PRI MUST be unique to each of the flows pertaining to a given MN. This sentence should be more precise. I think it means that there should be no duplication of FID-PRIs, but I'm not sure, and I'm not sure why it says "pertaining to a given MN" Section
