Visa waivers, or not
I just wanted to remind people again that if you come from a visa waiver country, you will need a machine readable passport or an actual visa for the Dallas IETF. Please check carefully to avoid being blocked at the airport. The details are complicated: http://www.travel.state.gov/visa/temp/without/without_1990.html Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on disruptive posting
I think we all are in agreement except on an idea Eudardo Mendez gave me. I will rephrase it as if someting tastes as a WG, smells like a WG, its charter should be approved like for a WG. The non-WG list is only subject to the approbation of an AD. This opens the door to too many possible contention and COI suspicions. Logic and ethic calls for non-WG list receiving WG authority rights to be subject to WG creation cycle (obviously far faster). I think it should result from a simple change in the registration form and page display. It will say the status of the non-WG list approval and details. To be on the list an AD approval is enough. To get full WG priviledges the non-WG list will need to have the IAB reviewed, IESG approved, Area and ADs, etc. A last problem is the obsolescence of a non-WG list. I think it should be automatic. When the Registry or the RFC founding the interest of the non-WG list is obsoleted, the IAB and IESG stamps are automatically removed. This permits the list to continue operating. But it is no more liste delegated duties and rights. jfc At 18:56 21/02/2006, Brian E Carpenter wrote: Eric, Gray, Eric wrote: ... ... there is a need to define who is what, he has a valid point. I moderate the MPLS mailing list, but there are others who are authorized to do so as well - including the ADs and WG Chairs. I assume this is true of other mailing lists as well, and I do not think that it is obvious to everyone who is on the list of people with authority to manage each list. That is the reason for the specific reference to the administrators listed at https://datatracker.ietf.org/public/nwg_list.cgi. ... the comment that Brian's terminology use is not consistent (Brian says the moderators or maintainers of IETF mailing lists that are not WG mailing lists in the beginning of his message and where the administrators are listed later on), It's not *my* terminology, it's an IESG statement. The inconsistent language in the two parts of the statement has been noted. ... reasonable in saying that a decision should name the AD consulted Reasonable and should, yes. https://datatracker.ietf.org/public/nwg_list.cgi lists the Areas, which gets you to a choice of two ADs at most, so the responsible AD is not hard to find. I believe that at least a formal notification must occur and it must list those people involved in making the decision. Yes, I agree. It would also be good from the list administrator's perspective if the notification was at least backed up by the consulted AD - if it does not in fact come from the consulted AD(s). Not sure I see why, but I'd certainly expect the AD to be copied. ... if there are lists that are maintained by the IETF site that do not properly belong under IESG authority, Those would not be at https://datatracker.ietf.org/public/nwg_list.cgi, so would be out of scope. or if there are lists maintained elsewhere that are kept on behalf of the IETF, but do not fall under IESG authority. I don't know that such lists exist, but it is possible that they do. If they do, they *are* are at https://datatracker.ietf.org/public/nwg_list.cgi Would BoF mailing lists fall into this category? If they are listed at https://datatracker.ietf.org/public/nwg_list.cgi. ... there should be an announcement that such-and-such list now falls under the IESG authority Ideally yes, but since the list of such lists is public at https://datatracker.ietf.org/public/nwg_list.cgi, this is low on my list of change requests to the secretariat. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IESG Statement on disruptive posting
Brian, Thanks for the clarification! -- Eric -- -Original Message- -- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, February 21, 2006 12:57 PM -- To: Gray, Eric -- Cc: 'Sam Hartman'; ietf@ietf.org -- Subject: Re: IESG Statement on disruptive posting -- -- Eric, -- -- Gray, Eric wrote: -- ... --... there is a need to define who -- is what, he has a valid point. I moderate the MPLS -- mailing list, but -- there are others who are authorized to do so as well - -- including the -- ADs and WG Chairs. I assume this is true of other -- mailing lists as -- well, and I do not think that it is obvious to everyone -- who is on the -- list of people with authority to manage each list. -- -- That is the reason for the specific reference to the administrators -- listed at https://datatracker.ietf.org/public/nwg_list.cgi. -- --... the comment that Brian's terminology use -- is not consistent (Brian says the moderators or -- maintainers of IETF -- mailing lists that are not WG mailing lists in the -- beginning of his -- message and where the administrators are listed later on), -- -- It's not *my* terminology, it's an IESG statement. -- The inconsistent language in the two parts of the statement has -- been noted. -- -- ... reasonable in saying that a decision -- should name the AD consulted -- -- Reasonable and should, yes. -- https://datatracker.ietf.org/public/nwg_list.cgi lists the -- Areas, which gets you to a choice of two ADs at most, so the -- responsible AD is not hard to find. -- --I believe that at least a formal notification must occur and it -- must list those people involved in making the decision. -- -- Yes, I agree. -- --It would also be good from the list administrator's perspective -- if the notification was at least backed up by the -- consulted AD - if it -- does not in fact come from the consulted AD(s). -- -- Not sure I see why, but I'd certainly expect the AD to be -- copied. -- -- ... if there are lists that are -- maintained by the IETF site that do not properly belong under IESG -- authority, -- -- Those would not be at -- https://datatracker.ietf.org/public/nwg_list.cgi, -- so would be out of scope. -- -- or if there are lists maintained elsewhere that are kept on -- behalf of the IETF, but do not fall under IESG authority. -- I don't know -- that such lists exist, but it is possible that they do. -- -- If they do, they *are* are at -- https://datatracker.ietf.org/public/nwg_list.cgi -- --Would BoF mailing lists fall into this category? -- -- If they are listed at -- https://datatracker.ietf.org/public/nwg_list.cgi. -- -- ... there should -- be an announcement that such-and-such list now falls under the -- IESG authority -- -- Ideally yes, but since the list of such lists is public -- at https://datatracker.ietf.org/public/nwg_list.cgi, -- this is low on my list of change requests to the secretariat. -- -- Brian -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
NomCom 2005-2006 Announcement
I am pleased to announce that the 2005-2006 NomCom selection and confirmation process is complete. At this time, on behalf of the NomCom, here is the complete list of IAB, IESG and IAOC members selected for the positions under review by the NomCom: IAB --- Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG Lisa DusseaultApplication Area Director Jari ArrkoInternet Area Director Dan Romascanu Operations and Management Area Director Cullen Jennings Real-time App. and Infra. Area Director (2 year term) Jon Peterson Real-time App. and Infra. Area Director (1 year term) Ross Callon Routing Area Director Sam Hartman Security Area Director Magnus Westerlund Transport Area Director IAOC Ed Juskevicius The NomCom joins the rest of the IETF community in thanking all these individuals for taking these positions, and in thanking all those who volunteered to be considered as a candidate in the NomCom process. I thank everyone who volunteered to serve on the NomCom, and especially the volunteers who were selected to make up this NomCom: Voting volunteers: Joe Babiarz Ron Bonica Stewart Bryant Joao Damas Lakshminath Dondeti Vijay Gurbani Wassim Haddad Alan Hawrylyshen Dinesh Mohan Sam Weiler Non-voting liaisons and advisor: Steve Crocker ISOC liaison David Meyer IAB liaison Russ HousleyIESG liaison Danny McPherson Advisor (past chair) These members of the NomCom found time in their schedules to join twice-weekly teleconferences, solicit and review input from across the IETF, conduct a thorough and well-considered review of the candidates and develop a slate of excellent nominees for the positions we were asked to fill. Our liaisons and advisor provided us with sage and helpful guidance. Also, thanks to Henrik Levkowetz for his great work in developing the web-based input for our candidate review. As a reward, Henrik can expect requests from the NomCom in the future for help in automating more of the administrative tasks associated with the NomCom process. Finally, thanks to everyone who took the time to participate in the process through nominations, interviews and input on the candidates under review. - Ralph Droms (chair), for the 2005-2006 IESG Nominating Committee ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 'monotonic increasing'
- Original Message - From: Frank Ellermann [EMAIL PROTECTED] To: ietf@ietf.org Sent: Tuesday, February 21, 2006 3:57 PM Subject: Re: 'monotonic increasing' Marshall Eubanks wrote: a RFC-2119 type RFC to define mathematical terms ? Maybe more like some glossaries (Internet, security, I18N, ...), informational RFCs. But I think that's unnecessary. There are online math. dictionaries, authors can provide references for unlear terms, or say what they mean. Otherwise this thread is unlikely to do much to change the situation. It highlights why clear terms in RFC are good, defined by reference or inline. In some groups saying 'header' instead of 'header field', 'byte' instead of 'octet', or 'charset' instead of IIRC 'encoded character repertoire' is enough to start a thread. And 'monotonic increasing' instead of 'strictly (monotonic) increasing' is apparently a similar issue. Bye, Frank What I see from this thread is that there are two common interpretations to the phrase 'monotonic increasing', either a sequence in which each number is greater than or equal to its predecessor, or one in which each number is strictly greater than its predecessor, with the former meaning having somewhat the greater support (at least amongst those with access to text books): which, of itself, makes it a risky term to use in a specification. I still think that it is sometimes used in RFC and I-D in a third sense, of a sequence of integers increasing by one each time, not a meaning anyone has supported. But only the editor can know what is really intended. So, the next time I see it used, perhaps in a Last Call of a pkix, kink or secsh I-D, I will seek further clarification. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on disruptive posting
JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes: JFC I think we all are in agreement except on an idea Eudardo JFC Mendez gave me. I will rephrase it as if someting tastes as JFC a WG, smells like a WG, its charter should be approved like JFC for a WG. The non-WG list is only subject to the approbation JFC of an AD. This opens the door to too many possible contention JFC and COI suspicions. Logic and ethic calls for non-WG list JFC receiving WG authority rights to be subject to WG creation JFC cycle (obviously far faster). I think it should result from a JFC simple change in the registration form and page display. It JFC will say the status of the non-WG list approval and JFC details. To be on the list an AD approval is enough. To get JFC full WG priviledges the non-WG list will need to have the JFC IAB reviewed, IESG approved, Area and ADs, etc. In principle this sounds fine. My confusion stems from the fact that it's actually more restrictions that are applied to IETF lists than privileges. Here is what an IETf list implies to me: * open participation * an appeals path * open archive * IETf IPR What privileges do you see? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: 'monotonic increasing'
Tom, I'm sorry to disagree, but I feel that the term monotonic has a much better defined meaning than most terms in general (including - for example - the term term). There are definitely applications for the phrase monotonically increasing where the terminology is exactly correct and very hard to word-smith around. There are also cases in which the appropriate phrase might have been strictly monotonically increasing, and for one reason or another the word strictly was omitted. In such cases, it either was clear what was meant at the time, or it has become clear in the mean time. I really do not see why we need to get quite so retentive about terminology when we have the ability to ask questions about anything we don't understand completely. Nor do I believe that there is any way that we could avoid the need to ask questions strictly as a result of using perfect terminology (or phraseology). -- Eric -- -Original Message- -- From: Tom.Petch [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, February 22, 2006 3:50 PM -- To: ietf; Frank Ellermann -- Subject: Re: 'monotonic increasing' -- -- - Original Message - -- From: Frank Ellermann [EMAIL PROTECTED] -- To: ietf@ietf.org -- Sent: Tuesday, February 21, 2006 3:57 PM -- Subject: Re: 'monotonic increasing' -- -- Marshall Eubanks wrote: -- -- a RFC-2119 type RFC to define mathematical terms ? -- -- Maybe more like some glossaries (Internet, security, -- I18N, ...), informational RFCs. But I think that's -- unnecessary. There are online math. dictionaries, -- authors can provide references for unlear terms, or -- say what they mean. -- -- Otherwise this thread is unlikely to do much to -- change the situation. -- -- It highlights why clear terms in RFC are good, -- defined by reference or inline. In some groups -- saying 'header' instead of 'header field', 'byte' -- instead of 'octet', or 'charset' instead of IIRC -- 'encoded character repertoire' is enough to start -- a thread. And 'monotonic increasing' instead of -- 'strictly (monotonic) increasing' is apparently a -- similar issue. --Bye, Frank -- -- -- What I see from this thread is that there are two common -- interpretations to -- the phrase 'monotonic increasing', either a sequence in -- which each number is -- greater than or equal to its predecessor, or one in which -- each number is -- strictly greater than its predecessor, with the former -- meaning having somewhat -- the greater support (at least amongst those with access to -- text books): which, -- of itself, makes it a risky term to use in a specification. -- -- I still think that it is sometimes used in RFC and I-D in a -- third sense, of a sequence of integers increasing by one -- each time, not a -- meaning anyone has supported. But only the editor can know -- what is really -- intended. -- -- So, the next time I see it used, perhaps in a Last Call of -- a pkix, kink or secsh -- I-D, I will seek further clarification. -- -- Tom Petch -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard
Pasi: My personal comments about draft-santesson-tls-ume-01: The draft defines an extension to TLS that allows the client to send user mapping information to the TLS server. The server uses this information to fetch authentication/authorization-related information from a directory server. I do not think this is a good summary of the purpose of this document. Currently in the Microsoft environment, a Microsoft-specific certificate extension that contains the username is required. This extension allows certificates without this Microsoft-specific extension to be used. The document refers to these as legacy certificates. In fact, these are the certificates that are in common use in many large enterprises. The draft is quite similar to draft-housley-tls-authz-extns, which allows sending X.509 attribute certificates and SAML assertions in TLS. The main difference seems to be that we only send a pointer to the authorization information (a bit like IKEv2, which supports sending an URL of the certificate instead of the cert itself). From a purely technical point of view, it would probably make sense to merge these drafts. The tls-authz-extns draft does some details better: e.g., the information is sent encrypted, and only after the server has been authenticated. Based on the comments that I received from Eric Rescorla on draft-housley-tls-authz-extns, this draft is likely to move in a somewhat different direction; however, that is a discussion for a different thread. The solution is also quite similar to the client_certificate_url extension defined in RFC 3546 (the User Principal Name could be considered as one type of certificate URL). Here even the placement of the handshake messages is identical to tls-ume. Unfortunately, it seems that sending both CertificateURL and Certificate handshake messages is not allowed, complicating the situation. The change proposed here would require action by the TLS WG. And, this alternative approach was not raised at the Vancouver IETF when this solution was presented to the TLS WG. However, it might be that process and timing issues make mergers infeasible. Also, the authors of draft-santesson-tls-ume seem to be unwilling to make changes to the protocol. This is not the case. I raised a significant concern when I did my AD review, and after discussion of several alternative solutions, they picked one and changed the document. I understand that they are also changing their implementation to match the document. About the technical details: In general, the solution seems to work, and does not contain any serious flaws. I don't count sending the user mapping information unencrypted as a serious flaw -- this information is sent only when a client certificate is also sent, and the client certificate is not encrypted either (unless the double-handshake hack is used, in which case the user mapping information would be encrypted, too). I agree with this assessment. It's probably not the most elegant design possible (see e.g. Eric Rescorla's review). However, I think we should clearly distinguish between 'it won't work' and 'it could/should work better' (as Dave Crocker well put it in one email). The document solves a real (but maybe not extremely large or important) problem, and the solution works. That's better than many documents these days... I think that the folks that are using enterprise PKIs would like to see this capability, and Microsoft is prepared to make it available in Vista. Given these, I think this would be an excellent document for Informational, especially if the title was changed to Microsoft TLS User Mapping Extension to indicate that it's a proprietary extension where the IETF community had no chance to change anything. I also think vendors should be encouraged to publish their extensions, even if they are not perfect. I disagree with this point. When I did my AD review, I considered the Microsoft-specific nature of the document. The structure easily accommodates additional name forms. Thus, I do not think we should ask for Microsoft in the document title. However, due to the IANA allocation rules in 2246bis, this draft is being last called for standards track, and this is slightly more problematic. One observation is that the TLS allocation rules are quite strict, and not always totally logical. Specification Required is sufficient to get a ClientCertificateType number, and IETF Consensus gets you an ExtensionType number. But many extensions (including this one, and also some of the extensions in 3546bis) also require a handshake message number, and thus Standards Track. Or in other words: the degree of consensus and process required for a document that extends TLS depends heavily on minor technical details, not on what the extension actually does. RFC 2026 also says that A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be
Re: IESG Statement on disruptive posting
At 23:53 22/02/2006, Sam Hartman wrote: JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes: JFC I think we all are in agreement except on an idea Eudardo JFC Mendez gave me. I will rephrase it as if someting tastes as JFC a WG, smells like a WG, its charter should be approved like JFC for a WG. The non-WG list is only subject to the approbation JFC of an AD. This opens the door to too many possible contention JFC and COI suspicions. Logic and ethic calls for non-WG list JFC receiving WG authority rights to be subject to WG creation JFC cycle (obviously far faster). I think it should result from a JFC simple change in the registration form and page display. It JFC will say the status of the non-WG list approval and JFC details. To be on the list an AD approval is enough. To get JFC full WG priviledges the non-WG list will need to have the JFC IAB reviewed, IESG approved, Area and ADs, etc. In principle this sounds fine. My confusion stems from the fact that it's actually more restrictions that are applied to IETF lists than privileges. Here is what an IETf list implies to me: * open participation * an appeals path * open archive * IETf IPR What privileges do you see? I am not sure about what you ask. Their priviledge is to be an IETF list. This implies constraints (IESG approval, IAB charter review,...) Their priviledge is reduced contrainst. AD approval is enough for those not deciding for the IETF. No Charter, just a few lines describing their topic. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on disruptive posting
JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes: JFC At 23:53 22/02/2006, Sam Hartman wrote: JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes: JFC I think we all are in agreement except on an idea Eudardo JFC Mendez gave me. I will rephrase it as if someting tastes as JFC a WG, smells like a WG, its charter should be approved like JFC for a WG. The non-WG list is only subject to the approbation JFC of an AD. This opens the door to too many possible contention JFC and COI suspicions. Logic and ethic calls for non-WG list JFC receiving WG authority rights to be subject to WG creation JFC cycle (obviously far faster). I think it should result from a JFC simple change in the registration form and page display. It JFC will say the status of the non-WG list approval and JFC details. To be on the list an AD approval is enough. To get JFC full WG priviledges the non-WG list will need to have the JFC IAB reviewed, IESG approved, Area and ADs, etc. In principle this sounds fine. My confusion stems from the fact that it's actually more restrictions that are applied to IETF lists than privileges. Here is what an IETf list implies to me: * open participation * an appeals path * open archive * IETf IPR What privileges do you see? JFC I am not sure about what you ask. Their priviledge is to be JFC an IETF list. This implies constraints (IESG approval, IAB JFC charter review,...) Their priviledge is reduced JFC contrainst. AD approval is enough for those not deciding for JFC the IETF. No Charter, just a few lines describing their JFC topic. jfc Normally when you want to require an approval process like chartering it is because there is some power or authority being delegated to a list. If the only thing that being an IETF list gets you is additional constraints, why do we need to have a complicated chartering process? Now if you propose that whenever an IETF list is given authority--over a registry, over some approval process etc--it needs a charter and that charter needs community review, I agree with you. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
xml2rfc updates
I noticed during AUTH48 that the RFC Editor Acknowledgment has been revised. Is there any intention of updating xml2rfc to reflect this? Mark Funding for the RFC Editor function is currently provided by the Internet Society. vs Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on disruptive posting
At 01:35 23/02/2006, Sam Hartman wrote: JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes: JFC At 23:53 22/02/2006, Sam Hartman wrote: JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes: JFC I think we all are in agreement except on an idea Eudardo JFC Mendez gave me. I will rephrase it as if someting tastes as JFC a WG, smells like a WG, its charter should be approved like JFC for a WG. The non-WG list is only subject to the approbation JFC of an AD. This opens the door to too many possible contention JFC and COI suspicions. Logic and ethic calls for non-WG list JFC receiving WG authority rights to be subject to WG creation JFC cycle (obviously far faster). I think it should result from a JFC simple change in the registration form and page display. It JFC will say the status of the non-WG list approval and JFC details. To be on the list an AD approval is enough. To get JFC full WG priviledges the non-WG list will need to have the JFC IAB reviewed, IESG approved, Area and ADs, etc. In principle this sounds fine. My confusion stems from the fact that it's actually more restrictions that are applied to IETF lists than privileges. Here is what an IETf list implies to me: * open participation * an appeals path * open archive * IETf IPR What privileges do you see? JFC I am not sure about what you ask. Their priviledge is to be JFC an IETF list. This implies constraints (IESG approval, IAB JFC charter review,...) Their priviledge is reduced JFC contrainst. AD approval is enough for those not deciding for JFC the IETF. No Charter, just a few lines describing their JFC topic. jfc Normally when you want to require an approval process like chartering it is because there is some power or authority being delegated to a list. If the only thing that being an IETF list gets you is additional constraints, why do we need to have a complicated chartering process? Now if you propose that whenever an IETF list is given authority--over a registry, over some approval process etc--it needs a charter and that charter needs community review, I agree with you. All the lists on the non-WG page are IETF lists covered by the IETF copyrights, etc. These are their basic privilege. Obviously when you just keep alive a WG list, prepare a WG, investigate some testing, etc. you do not need something formal. But when it comes to a registry. Also, this is something Brian does not seem to want to consider too much, but there may be legal implications to registry management and certainly political ones (ex. names and numbers, languages, etc.). Then you want a mutual formal link - to control/protect. In the RFC 3066 Bis case, the question raised by Scott irt. the LSR could be IMHO addressed by a separate Draft. It would be a very formal way to describe a permanent organisation (but not more than in the case of names/numbers where there is an MoU with ICANN). The interest is that the Draft I propose would be formally approved by the IESG (under possible appeal to the IAB). It would be much more flexible and could serve as the IETF side in an MoU, if the job was delegated to another organization (I quoted Unicode, ICANN, ISOC, UNESCO,INCOTERM, ITU, etc.). Or accommodate its delegation to an individual like Michael Everson or me or anyone else. Even in the case the job is performed by a 20 people staff at UNESCO, the IETF/IAB/IESG would keep control over that non-WG list. We see all the difficulties we face and this flexible approach permits to address. In the 3066 Bis case technical appeals are to the IESG and IAB. This means that if an African university disagrees on the way a Chinese scholar think a Eskimo dialect is written in Cyrillic in Peru, the IESG will have to decide. May be of interest to define some kind of advisory committee. IMHO a graduated approach permits this, while keeping authority/delegation consistent. NB. In case names and numbers, appeals have be left with ICANN. Appeals there are with their Ombudsman. RFC 3066 Bis creates an interesting case. It says that the LSR moderates the list. This is consistent with the fact that the list is a IANA list. This means that the administration (RFC 3934 in the IETF) is with IANA, and that all the fuss made by Michael Everson is meaningless. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492in PPPoE' to Informational RFC
On Tue, 21 Feb 2006, Peter Arberg wrote: It will without a doubt make the solution more robust if the echo test was performed upon setup, and we could change the recommendation to not specific say this capability SHOULD be disabled, so changing it from --- This capability SHOULD be disabled by default, and SHOULD only be available for debug, test purpose. --- to something like this: --- This capability MAY be disabled by default, but SHOULD be available for debug, test purpose. --- if you think that will make it a little better. Couldn't we say even more than that, simply like: This capability SHOULD be used by default. or: This capability SHOULD be used by default to verify that the negotiated MTU/MRU actually works. That would allow anyone to disable it (or not implement it) and still be compliant with the spec. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
WG Review: Recharter of Intellectual Property Rights (ipr)
A modified charter has been submitted for the Intellectual Property Rights (ipr) working group in the General Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by March 1st. +++ Intellectual Property Rights (ipr) === Current Status: Active Working Group Chair(s): Harald Alvestrand [EMAIL PROTECTED] Steven Bellovin [EMAIL PROTECTED] General Area Director(s): Brian Carpenter [EMAIL PROTECTED] General Area Advisor: Brian Carpenter [EMAIL PROTECTED] Mailing Lists: General Discussion: ipr-wg@ietf.org To Subscribe: [EMAIL PROTECTED] Archive: http://www.ietf.org/mail-archive/web/ipr-wg/index.html Description of Working Group: The IETF and the Internet have greatly benefited from the free exchange of ideas and technology. For many years the IETF normal behavior was to standardize only unencumbered technology. While the Tao of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of the IETF IPR policy has been to make it easier for the IETF to make use of encumbered technology when it made sense to do so. This group has attempted to clarify and update that IPR policy, resulting in RFC 3978, RFC 3979 and RFC 3905. The WG has also discussed the possibility of changing the IETF's patent policy, but did not detect a consensus for doing so. At the time of this recharter (February 2006), there are two remaining items of work for the WG: - An issue with the production of derivative works has led to the realization that RFC 2026 and RFC 3978 do not specify exactly the same policy on this matter, and that neither policy, when read literally, may be optimal for the IETF's purpose, in accordance with its mission statement (RFC 3935), its policy of retaining change control of its own documents, and its desire for its documents to be openly available and useful. - The creation of the IETF Trust for managing the IETF IPR has led to the question of how the Trustees should evaluate the benefit of the IETF community as a whole and if necessary the consensus of the IETF on a given matter. Specifically the question arises whether the previous discussions of the IPR WG have led to experience that should be codified for the guidance of the Trustees. The WG will produce 3 documents: - An update to RFC 3978 (BCP) that attempts to specify a complete set of rights with respect to derivative works granted to the IETF by authors, as well as technical updates necessitated by the existence of the Trust - A document (info) giving advice to the IETF Trust on what rights in IETF contributions it should attempt to grant to the public in order to retain change control while allowing open access, resolving the discrepancy between RFC 2026 and RFC 3978 - A document (info) giving other advice to the IETF Trust on IPR handling, based on the IPR WG's experience of discussions in the area The last document may include advice to the IETF Trust on mechanisms for consulting with the community on IPR issues once the IPR WG has closed, if consensus on such advice can be found. The IPR WG may decide to drop the last document from its charter if it decides that it has nothing to say. All documents should have an IETF-wide Last Call before being approved. Goals and Milestones: Done 1st draft of RFC 3978 update Feb 2006 1st draft of granted rights advice doc Feb 2006 1st draft of IPR advice doc Mar 2006 RFC 3978 update to IESG for approval Apr 2006 Granted rights advice to IESG for approval Aug 2006 IPR advice to IESG for approval Oct 2006 Once documents are all published, close WG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: TCP Maintenance and Minor Extensions (tcpm)
The charter of the TCP Maintenance and Minor Extensions (tcpm) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ TCP Maintenance and Minor Extensions (tcpm) = Current Status: Active Working Group Chair(s): Ted Faber [EMAIL PROTECTED] Mark Allman [EMAIL PROTECTED] Transport Area Director(s): Allison Mankin [EMAIL PROTECTED] Jon Peterson [EMAIL PROTECTED] Transport Area Advisor: Jon Peterson [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/index.html Description of Working Group: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG will write a document that outlines what is TCP. This document will be a roadmap of sorts to the various TCP specifications in the RFC series. TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. Specific Goals: * A document specifying a way to share the local User TimeOut value with the peer such that TCP connections can withstand long periods of disconnection. * The WG is working on an experimental technique to add robustness to TCP against packet reordering having a negative impact on performance. * The WG is coming to grips with how to deal with spoofed segments that can tear down connections, cause data corruption or performance problems. To this end the WG is generating an overview document as well as a scheme that mitigates some of the spoofed segment issues using a challenge-response scheme to reduce the probabilities of a connection being impacted. * The WG is writing an informational document about the ways in which TCPs can handle ICMP soft errors. * The WG is updating the specification for Explicit Congestion Notification to allow for the use of ECN during part of TCP's three-way handshake to aid performance for short transfers. Milestones: Apr 06 Submit NCR Reordering Mitigation draft to the IESG for publication as an Experimental RFC. Apr 06 Submit ECN-SYN document to the IESG for publication as a Proposed Standard RFC. May 06 Submit overview of spoofing attacks against TCP to IESG for publication as an Informational RFC. May 06 Submit In-Window Attack draft to IESG for publication as a Proposed Standard RFC. May 06 Submit User TimeOut option document to the IESG for publication as a Proposed Standard RFC. May 06 Submit soft errors document to the IESG for publication as an Informational RFC. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription' to Proposed Standard
The IESG has approved the following document: - 'Suppression of Session Initiation Protocol REFER Method Implicit Subscription ' draft-ietf-sip-refer-with-norefersub-04.txt as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-norefersub-04.txt Technical Summary The SIP REFER extension as defined in RFC 3515 automatically establishes a short-lived event subscription used to notify the party sending the REFER request about the execution of that request. This notification is not needed in all cases. This specification provides a way to prevent this subscription/notification sequence, using a new SIP extension header field which may be included in a REFER request. A new sip option tag is also defined to provide for declaration and discovery of support for this extension. Working Group Summary This specification was produced by the SIP working group in response to requirements forwarded by the SIPPING working group and based in part on requirements submitted by external organizations including the Open Mobile Alliance. The draft iterated several times as an individual draft before being adopted by the working group and added to the charter. Working group discussion centered on one key issue: What sort of SIP extension mechanism, including URI, header field, body part, or request type should be used to meet the requirements? A breakout session during IETF 63 resulted in the compromise documented in this specification, and subsequent working group review revealed a very high level of consensus for the direction selected. Several minor items, primarily typographical, were corrected during an extended working group last call. Protocol Quality There no implementations of this extension known to the WG Chairs at the time of publication request. However, we expect to see the extension broadly used in mobile phones implementing the Open Mobile Alliance's specification for Push to Talk Over Cellular. Dean Willis is the WG Chair shepherd. Allison Mankin is the Responsible Area Director. Notes to RFC Editor [replace the present abstract] Abstract OLD: This specification defines a way to suppress an implicit subscription with the Session Initiation Protocol (SIP) REFER method. A new SIP option tag norefersub is defined to indicate support for this extension. A new SIP header field Refer-Sub is defined to request the usage of this extension. NEW: The SIP REFER extension as defined in RFC 3515 automatically establishes a short-lived event subscription used to notify the party sending the REFER request about the execution of that request. This notification is not needed in all cases. This specification provides a way to prevent this subscription/notification sequence, using a new SIP extension header field which may be included in a REFER request. A new sip option tag is also defined to provide for declaration and discovery of support for this extension. -- Please expand the first use of User Agent (UA) and URI (Uniform Resource Identifier) -- Section 7 IANA Considerations OLD: The following information to be added to the header field sub-registry under http://www.iana.org/assignments/sip-parameters: NEW: The following information is added to the SIP Header field sub-registry in the SIP Parameters Registry. OLD: This document also registers a new SIP option tag, norefersub. NEW: This document also registers a new SIP option tag, norefersub adding it to the SIP Option Tags sub-registry in the SIP Parameters Registry. -- Note to IANA IANA - please note that the edits above are not new instruction, but clearer information on where the registry objects go. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Interworking between SIP and QSIG' to BCP
The IESG has approved the following document: - 'Interworking between SIP and QSIG ' draft-ietf-sipping-qsig2sip-04.txt as a BCP This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-04.txt Technical Summary This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signaling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. The approach taken in this document is similar to the approach used in other SIP-PSTN interworking specifications. The parts of QSIG that have direct analogs in SIP are mapped to the appropriate SIP element, and the parts that do not are transferred as MIME body parts using conventional encapsulations. Working Group Summary The document is a product of the SIPPING working group and was developed over the course of about four years. There were some concerns as to whether the SIPPING working group had adequate expertise in QSIG, so informal external review was used to establish a general agreement as to the adequacy of the work. The work itself was not controversial within the working group, which reported a high level of consensus on the output document. Protocol Quality This document was reviewed under the PROTO process by Dean Willis, co-chair of the SIP and SIPPING working groups. The methodology used in this specification is consistent with that used in other SIP-PSTN interworking specification such as RFC 3398 and RFC 3578. The Responsible AD was Allison Mankin. IANA Note This document has no IANA Considerations section because it raises no IANA considerations. It may be appropriate to add an IANA Considerations section with this disclaimer. Notes to the RFC Editor Abstract OLD ECMA Standards NEW Ecma Standards [Rationale: Ecma now uses the word Ecma, except in the names of its Standards where it continues to use the old name ECMA (e.g., ECMA-155). Make only the changes specified in these Notes, please.] --- Section 1 Introduction, paragraph 2: OLD: ECMA Standards NEW: Ecma Standards --- Section 5, Background and architecture, paragraphs 9 and 10 (two occurrences): OLD: media information NEW: media streams --- Section 5, Background and architecture, paragraph 11: OLD: transferring media information NEW: transferring media streams OLD: packetization of media information NEW: packetization of media streams OLD: de-packetization of media information NEW: de-packetization of media streams - Section 6, Overview, paragraph 2: OLD: an initial response message completes negotiation of the bearer channel NEW: an initial response message (e.g., CALL PROCEEDING) completes negotiation of the bearer channel Section 9.1, Mapping from QSIG to SIP, paragraph 2: OLD: whether the gateway trusts the next hop SIP node NEW: whether the gateway is in the same trust domain (as defined in [14]) as the next hop SIP node Section 9.2.2, Generating the QSIG Calling party number information element, paragraph 5: OLD: and the gateway supports this header, the gateway SHALL New: and the gateway supports this header, or if the value in the From header indicates anonymous, the gateway SHALL Section 11.1, General OLD: Normal considerations apply for UA use of SIP security measures, including digest authentication, TLS and SMIME. NEW: Normal considerations apply for UA use of SIP security measures, including digest authentication, TLS and S/MIME as described in [10]. Please substitute S/MIME for SMIME throughout. Section 12, Acknowledgements, paragraph 2: OLD: members of ECMA NEW: members of Ecma OLD: this draft NEW: this document Section 14, Normative References, reference [1]: OLD: published by ECMA NEW: published by Ecma Section 14, Normative References, reference [2]: OLD: published by ECMA NEW: published by Ecma In Section 14, Normative References, reference [3] OLD: published by ECMA NEW: published by Ecma - 30 - ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
