RE: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
parsers need to canonicalize maps to any depth in order to detect duplicates. This is complex by any definition of the word. It isn't complex in terms of computational efficiency ... you can canonicalize in O(N log N) and do it while reading. And the consequence of not using structure-equality in duplicate detection is complex. I think CBOR should be clear about how it handles sharing and equality. agree. Larry -- http://larry.masinter.net (obscure footnote: Serializing structures with duplicate pointers is fun, you need some notation to signify back pointers and to drop anchors. Using hash tables and canonical values was part of the circlprint/hprint http://pdp-10.trailing-edge.com/decuslib20-01/01/decus/20-0004/21lisp.tty.html implementation.)
RE: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
BCP 70 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols attempted to outline some of the design considerations for data representation using XML. In 2003, it represented the consensus and also the disagreements about what was best current practice at the time. Section 3 of BCP 70, Alternatives, lists some of the alternatives and provides a comparison. I think what might be missing is an update to BCP 70 or a companion which more explicitly compares XML, JSON, CBOR and other alternatives in use in IETF protocols. If you're interested in this work, perhaps you might review BCP 70 and suggest updates. Larry -- http://larry.masinter.net
FW: [mpls] FW: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Dear all, So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry. Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard. Best regards, Han Li -Original Message- From: HUANG Feng F Sent: 2011年10月5日 7:56 To: 'ietf@ietf.org' Subject: RE: [mpls] FW: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC Importance: High Hi, 1. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. MPLS-TP is subset of MPLS, MPLS is old mpls developed before MPLS-TP in 2008 or include MPLS-TP developed this years and in the future? MPLS-TP is for transport network, SDH/OTN/Etherent is transport network, it should be shown capability to transport network. 1.1 The standardization process within the IETF allows for the continued analysis of whether the OAM solutions under development meet the documented requirements, and facilitates the addition of new requirements if any are discovered. It is not the purpose of this document to analyze the correctness of the selection of specific OAM solutions. This document is intended to explain why it would be unwise to standardize multiple solutions for MPLS-TP OAM, and to show how the existence of multiple solutions would complicate MPLS-TP development and deployment making networks more expensive to build, less stable, and more costly to operate. According to JWT report, MPLS-TP is joint standardized by IETF and ITU-T, it is not right for someone decide solution for IETF and ITU-T. An analysis of the technical options for OAM solutions was carried out by a design team (the MEAD team) consisting of experts from both the ITU-T and the IETF. The team reached an agreement on the principles of the design and the direction for the development of an MPLS-TP OAM toolset. A report was subsequently submitted to the IETF MPLS Working Group at the Stockholm IETF meeting in July 2009. The guidelines drawn up by the design team have played an important role in the creation of a coherent MPLS-TP OAM solution. MEAD team's decision has never been send to ITU-T for comments, ITU-T have got nothing information about it. 1.2. The Development of a Parallel MPLS-TP OAM Solution The first of these was discussed within the IETF's MPLS working group where precedence was given to adherence to the JWT's recommendation to select a solution that reused as far as possible pre-existing MPLS tools. Additionally, it was considered that consistency with encodings and mechanisms used in MPLS was of greater importance. Many operators ask MPLS-TP OAM shown capacity to Ethernet, you can see draft-bhh-mpls-tp-oam-y1731. at least 9 provdiders support it. JWT report don't said anything about one solution, it is a start point to develop solution, IETF and ITU-T don't explore to public, one solution should be taken. 3.6 It should be noted that, in the long-run, it is the end-users who pay the price for the additional development costs and any network instability that arises. authors are come from vendors, they are not end users, which some venders want to push their own solutions. we should hear opinons from providers? let providers show their consideration on OAM, there is a IETF providers' draft about OAM consideration, you can refer to draft-fang-mpls-tp-oam-considerations, it is a pure providers' draft, some considerations are listed there! 5.1 for SDH/SONET as example, it work well in the network, phone call between Europe to US work very well, I am wondering author should known some history about SDH and SONET. 6. Potential Models For Coexistence In transport network, overlay model is usually used, it work very well. B.R. Feng -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: 2011年9月27日 5:58 To: m...@ietf.org Subject: [mpls] FW: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the
回复： [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Dear all, So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry. Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. In China Mobile, more than 330,000 PTN box are/will based on G.8113.1. TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard. Best regards, Han Li --- 11年10月5日，周三, D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 写道： 发件人: D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 主题: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC 收件人: adr...@olddog.co.uk adr...@olddog.co.uk, m...@ietf.org m...@ietf.org, ietf@ietf.org ietf@ietf.org 日期: 2011年10月5日,周三,下午5:38 Dear all, I do not support. Basically I think it is superfluous dedicate an RFC to state it is better having one standard instead of two ones or many... for sure the lower are the variants the better is for the industry (one is the ideal). When two or more standards or de-facto standards exist it is because the problem they solve is not exactly the same, the way they solve the problem is optimized for different environments/boundary conditions (more efficient, more effective, etc). Therefore a single solution does not necessarily meet the different market requirements. It is fundamental to enter into the problem's details before making consideration about the best way to proceed (one solution, two solutions, multiple solutions) whilst the document clearly declares it does not want to make any technical evaluations. After more than three years of debates within the IETF and major unresolved technical concerns risen from some transport operators, the existence of this draft is by itself the sure sign that MPLS-TP OAM is a case where a single solution has not be found to meet all the different market requirements. Otherwise, why are we still discussing about it? Therefore we must be realistic and the lessons learned from the past should guide our decisions: if a solution cannot be found for satisfying all the requirements it is better to have two standards and let the market decide how to exploit them. Are we really sure the cost(many) / benefit (none) analysis done in section 7.5 is realistic? Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] Per conto di Adrian Farrel Inviato: lunedì 26 settembre 2011 23:58 A: m...@ietf.org Oggetto: [mpls] FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 26 September 2011 20:43 To: IETF-Announce Subject: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational
Re: Last Call: draft-haberman-rpsl-reachable-test (An RPSL Interface Id for Operational Testing) to Proposed Standard
Vesna Manojlovic wrote: Dear Brian, list, On 3/6/10 12:28 AM, The IESG wrote: The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-04-02. I support the introduction of the new attribute. At the RIPE NCC, we already see opportunities for its usage for reachability testing and analysis. The file can be obtained via http://www.ietf.org/internet-drafts/draft-haberman-rpsl-reachable-test-03.txt One suggestion: please add that the pingable address MUST be within the range specified in route(6) object. It is implicit, and obvious, but for people implementing the IRR code (RIPE Database server, IRRd) it should be specified explicitly (IMHO), so that they can program the checks... I am looking forward to the acceptance of this addition to the RPSL specs, and I am willing to assist in the implementation adoption of the new attribute. I'm still not entirely convinced that this belongs in RPSL as opposed to the address registry allocation information. There are often suballocations of addresses where there is no change in origin AS and thus only a single route object exits. It would be useful to be able to indicate pingable addresses in these suballocations. While one could have multiple pingable attributes in the route object, I believe it is cleaner and clearer to put the pingable address in the suballocation information. I have concerns about these pingable addresses becoming stale.I'd like to see some caution in the draft about this issue and the possibility of mis-interpreting a stale address as a routing issue. One might suggest using the date in the changed: attribute as a possible indicator of staleness.You could also add an explicit date field to the pingable attribute itself. Another possible option would be to make this date an expiration date set at some point in the future. This would require periodically re-verifying the address and updating the expiration date. Pingable addresses with expired dates could be given less credence than those that have not expired. -Larry Blunk Merit ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TLS-authz standard
Dear IETF: I urge you to strongly oppose any standard that has been, is, or will be encumbered with patent claims. Regardless of any perception of beneficence of any patent holders, the legal system around patents has shown in recent times a remarkable tendency to generate unintended consequences. Therefore, the only safe way to proceed is to avoid any and all legal encumbrances to IETF sponsored standards. The proposed TLS-authz standard is only one instance of such a risky legal proposition. Sincerely, -- Larry Gadallah, VE6VQ/W7 lgadallah AT gmail DOT com PGP Sig: 917E DDB7 C911 9EC1 0CD9 C06B 06C4 835F 0BB8 7336 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-krb-wg-naming-04.txt
Hi Stephen, thanks for the review comments. -05 has fixed the typoes and it provides an example using the anonymous well-known names as requested. Here is the relevant text in -05. It is possible to have name collision with well-known names because Kerberos as defined in [RFC4120] does not reserve names that have special meanings, consequently care MUST be taken to avoid accidental reuse of names. If a well-known name is not supported, authentication MUST fail as specified in Section 3. Otherwise, access can be granted unintentionally, resulting in a security weakness. Consider for example, a KDC that supports this specification but not the anonymous authentication described in [ANON]. Assume further that the KDC allows a principal to be created named identically to the anonymous principal. If that principal were created and given access to resources, then anonymous users might inadvertently gain access to those resources if the KDC supports anonymous authentication at some future time. Similar issues may occur with other well-known names. By requiring KDCs reject authentication with unknown well-known names, we minimize these concerns. Let me know if you have further comments. --larry From: Stephen Hanna [EMAIL PROTECTED] Sent: Thursday, March 06, 2008 11:41 PM To: Larry Zhu; Jeffrey Hutzelman Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: secdir review of draft-ietf-krb-wg-naming-04.txt I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors should treat these comments just like any other comments. This document defines conventions for well-known Kerberos principal names and well-known Kerberos realm names. While the document seems to be pretty thorough, the Security Considerations section is too brief. This is especially true for a document whose main purpose is to modify a criticial security protocol such as Kerberos. The Security Considerations section could provide an example of how unintended access could be granted if an authentication with an unsupported well-known name is allowed to succeed. More important, it should explain why it is permissible for the TGS to allow an authentication to succeed even if the client and/or server principal name is an unsupported well-known name. The reasoning for allowing this is not clear to me but perhaps it is that the TGS can assume that the AS must have supported the client name or it would have failed the authentication. I'm not sure how this helps to address the case where the server name is an unsupported well-known name. I would like to see that explained, preferably in the document. I also noticed a few typos: At the end of section 1, remedy these should be remedy these issues or something similar. Otherwise, it's not clear what is to be remedied. In the last paragraph of section 3.1, the first word is in the phrase is a well-known principal name is used should be if. Similarly, in the second paragraph of section 3.2, the first word is should be if in the phrase is a well-known realm name is used. Other than these issues, the document seems to be OK. Thanks, Steve ___ ietf-krb-wg mailing list [EMAIL PROTECTED] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04.txt
The proposed text looks good. --larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Thursday, March 20, 2008 7:57 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: [Ietf-krb-wg] Late Last Call Comment: draft-ietf-krb-wg-naming-04.txt I think there is a minor ambiguity in the naming draft: Consequently, unless otherwise specified, a well-known Kerberos realm name MUST NOT be present in transited encoding Who enforces this requirement? That's an important question because it controls who needs to support the specific well known realm in order for it to be used. In general using passive voice for such requirements is a really bad idea. I'd recommend something like: Unless otherwise specified, parties checking the transited realm path MUST reject a transited realm path that includes a well known realm. In the case of KDCs checking the transited realm path, this means that the transited policy checked flag MUST NOT be set in the resulting ticket. In particular, that means that a KDC that is not checking transited realm paths is not encouraged to reject a request simply because the realm in an unknown well known realm. --Sam ___ ietf-krb-wg mailing list [EMAIL PROTECTED] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous
Sam and I got together today and discussed this issue. we believe by adding the following text then we have the right trade-off. If anonymous PKINIT is used, the returned realm name MUST be the anonymous realm. All the issues in this thread are assumed to have been addressed with this proposed change. This is pending workgr --larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Tuesday, July 08, 2008 7:21 AM To: Larry Zhu Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous Larry == Larry Zhu [EMAIL PROTECTED] writes: First, if I call gss_display_name on an anonymous principal in an acceptor, what do I expect to get back? Larry Would section 2.1.1 of RFC1964 be sufficient for this Larry purpose? not really. As Ken pointed out, there is a significant mess surrounding GSS-API and anonymous names.See section 4.5 in RFC 2743. In particular, two anonymous names need to compare as false; a special name type is used; etc. The GSS-API semantics do not seem to match well onto some of the Kerberos semantics you propose. Martin Rex said that the anonymous support was relatively immature in GSS-API and that perhaps it needed to be revisited. I tend to agree. The other concern I have is the multiple ways to specify anonymous names for the AS case. I don't understand why we need multiple ways to do that. --Sam ___ ietf-krb-wg mailing list [EMAIL PROTECTED] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous
The last sentence in the previous email was not completed before the send button was hit inadvertently. It should read This is pending krb-wg working group validation.. --larry -Original Message- From: Larry Zhu Sent: Sunday, July 27, 2008 8:00 AM To: 'Sam Hartman' Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous Sam and I got together today and discussed this issue. we believe by adding the following text then we have the right trade-off. If anonymous PKINIT is used, the returned realm name MUST be the anonymous realm. All the issues in this thread are assumed to have been addressed with this proposed change. This is pending workgr --larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Tuesday, July 08, 2008 7:21 AM To: Larry Zhu Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous Larry == Larry Zhu [EMAIL PROTECTED] writes: First, if I call gss_display_name on an anonymous principal in an acceptor, what do I expect to get back? Larry Would section 2.1.1 of RFC1964 be sufficient for this Larry purpose? not really. As Ken pointed out, there is a significant mess surrounding GSS-API and anonymous names.See section 4.5 in RFC 2743. In particular, two anonymous names need to compare as false; a special name type is used; etc. The GSS-API semantics do not seem to match well onto some of the Kerberos semantics you propose. Martin Rex said that the anonymous support was relatively immature in GSS-API and that perhaps it needed to be revisited. I tend to agree. The other concern I have is the multiple ways to specify anonymous names for the AS case. I don't understand why we need multiple ways to do that. --Sam ___ ietf-krb-wg mailing list [EMAIL PROTECTED] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous
Sam wrote: As it turns out, a client cannot check ticket flags: it doesn't actually know the key needed to decrypt the ticket. Perhaps you mean that the client should check the KDC flags. The KDC duplicates the tickets flag in the EncKDCRepPart and the client can check that. I would propose the following changes to clarify this point. 356,359c365,368 by checking the presence of the anonymous ticket flag. This is because KDCs ignore unknown KDC options. A KDC that does not understand the anonymous KDC option will not return an error, but will instead return a normal ticket. --- by checking the presence of the anonymous ticket flag in the flags field of the EncKDCRepPart. This is because KDCs ignore unknown KDC options. A KDC that does not understand the anonymous KDC option will not return an error, but will instead return a normal ticket. First, if I call gss_display_name on an anonymous principal in an acceptor, what do I expect to get back? Would section 2.1.1 of RFC1964 be sufficient for this purpose? Second, if I provide the anonymous name to a KDC in an AS-REP with the anonymous option set, but don't provide padata, should I expect a preauth_required error from the KDC listing pkinit? Yes, I would like to propose the following new sentence into section 4 to make this clear. 262a266,269 The KDC conforming to this specification MUST indicate the support of anonymous PKINIT as described above in this section according to Section 3.4 of [RFC4556]. Let me know if you do not believe these changes are editorial and if any of all your concerns is not sufficiently addressed. Thanks, --larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Thursday, March 20, 2008 10:20 AM To: ietf@ietf.org; [EMAIL PROTECTED] Subject: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous With one minor concern, I do believe this draft is ready for publication as a proposed standard. However I think this draft is fairly rough as proposed standards go; I expect that we will end up needing a new revision of this spec at some future point that refines some of the details based on implementation experience. That's what our process is all about, so I am not bothered. The following requirement is impossible to implement: If a client requires anonymous communication then the client MUST check to make sure that the ticket in the reply is actually anonymous by checking the presence of the anonymous ticket flag. This is As it turns out, a client cannot check ticket flags: it doesn't actually know the key needed to decrypt the ticket. Perhaps you mean that the client should check the KDC flags. Additionally, there are a few areas in which the spec is unclear. These could be fixed now or fixed in a future revision of the spec. First, if I call gss_display_name on an anonymous principal in an acceptor, what do I expect to get back? Second, if I provide the anonymous name to a KDC in an AS-REP with the anonymous option set, but don't provide padata, should I expect a preauth_required error from the KDC listing pkinit? ___ ietf-krb-wg mailing list [EMAIL PROTECTED] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[secdir] SECDIR review of draft-ietf-sip-multiple-refer-03.txt
Hi, 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. The document seems to have limited scope. It defines an extension via which a user can ask another user to send a request to a third party. The opening statement in the document does not convince me this is a generically useful extension comparing with leaving such facility application specific. The text does not tell me what motivates the second user to comply with the multiple-refer extension, or why the first user does not want to send the command directly given it knows the list of recipients. My guess is that the second user either has more information or have more resources (that the first user would believe) but the document does not explain that. I am rather uncomfortable with the security aspects of this extension. The security considerations section in the current document looks like boilerplate and I suspect there are plenty of security issues to consider. For example, it would be helpful if it can go though all possible SIP commands that could be used in the multiple-refer method and illustrate what kinds of authorization should be checked, and discuss the implications for the second user if the later chooses to comply. Thanks, --larry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[secdir] Review of draft-levin-mmusic-xml-media-control-12
Hello, 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. Overall as an informational ID I believe the document is well written and it should be published as soon as possible. I have the following non-blocking COMMENTS: 1. Section 2, inconsistent use of RFC2119 language, shipping products and new products SHALL use ..., the preceding sentence seems to suggest it is a SHOULD not a SHALL. 2. Section 4, the inconsistently spelling of in time vs in-time. Not being an expert in this field, it is not clear to me what the parenthesis actually adds. 3. Section 4, (what I consider) incorrect use of RFC2119 language, ... MUST be validated by ..., I do not know what does the use of MUST imply here. Suggestion: it should be sufficient to drop the MUST keyword here, try is validated 4. Section 5, the UAC that sent..., please expand UAC on first use. 5. section 7, unclear statement, Note that this primitive is supported by all known implementations, it is not clear to me which primitive it refers to. Suggestion: quote a reference for the primitive in question. 6. section 10, overall this section could benefit from more details or references. For example, it is not clear how TLS can be applied to secure the signalling path. Also the last sentence seems to contradict with the rest of this section. The section in RFC2976 only explicitly mentions confidentiality. Suggestion: it might be sufficient to say the security considerations in RFC2976 apply here. Best regards, --larry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[secdir] Review of draft-ietf-enum-calendar-service-03
Hello, 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. I have the following COMMENTS: 1. Overall, the document does not discuss I18N. Is it required that the mailto contains US ASCII only when it is encoded in DNS? This is unclear to me. 2. Section 4, what is the security implication if the same number is used to identify different URIs. In other words, what prevents the choice of numbers from collisions and what happens when there is a collision. Number squatting does not seem to be mitigated by DNS SEC as mentioned in the document. This is just not clear to me but I am not an expert here. 3. I agree with the comments that adding some description of potential use cases would help when the PROTO write-up mentions there is no implementation interest. For one thing, security considerations typically would make more sense in the context of use cases. Best regards, --larry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Not at all. There is a huge difference between ask participants in a discussion what they think and a consensus call. I've frequently seen postings that talk about the consensus of a Bar BoF, and never seen any objection to that terminology. Consensus is always qualified by the scope of the participants, and we all know how to tell the difference between consensus of the IETF, consensus of the room, consensus of the working group, and consensus of the participants in the mailing list X. I think the process discussion is a distraction from working on the actual issues, and wish it would stop. Larry -- http://larry.masinter.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
RFC 3986 contains a (brief) description of security considerations for agents that produce or receive and interpret URIs. I would expect this document to at the very least reference those security considerations more explicitly, and at best to analyze how they apply in particular to URIs used within SNMP. It's not clear whether it makes sense for SNMP URIs to contain, for example, 'data:' URIs or 'urn:' or any of a number of schemes, and I would expect some discussion about the applicability of URIs within a SNMP context. URIs are defined as a sequence of characters, not a sequence of octets. The mapping should be explicit (e.g., 'use US-ASCII') and not implicit. In practice, many systems allow and produce IRIs (RFC 3987) and not URIs, to allow for accents and non-roman scripts. I wonder if it would be more appropriate to define the MIB value as an IRI encoded in UTF-8, for example. Larry -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 3:02 PM To: IETF-Announce Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Uniform Resource Identifier (URI) MIB ' draft-mcwalter-uri-mib-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-mcwalter-uri-mib-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=15468rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An important day for the IETF
On Monday 16 January 2006 10:00, Harald Tveit Alvestrand wrote: --On mandag, januar 16, 2006 09:39:36 -0500 Noel Chiappa [EMAIL PROTECTED] wrote: From: Harald Tveit Alvestrand [EMAIL PROTECTED] Wonder how many of the original 21 are still around You rang? :-) That's one :-) The first IETF chair seems to have made a foray into politics -- http://www.gcn.com/vol19_no14/community/2133-1.html Since I could find no record of a Congressman Mike Corrigan, I assume he lost the race :) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
From http://www.itu.int/ITU-T/edh/faqs-docsub.html When submitting a document which contains figures, it is highly recommended that the figures be created using a graphic software and inserted into the document rather than creating the figure using the default Picture Editor in Word. Drawings made using Picture Editor do not convert properly in different versions Word for Windows and in some cases, the figures do not appear at all. In cases where the author has used the Picture Editor, the author must ensure that all the elements or objects in the figure are grouped (defined as one figure) to avoid objects being re-aligned when the margins or paper size are modified. Not exactly confidence inspiring. Good thing they highly recommend not using the default Picture Editor in Word. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF 63, visa information
I am not sure if this is the proper forum for how to get visa in order to go to IETF63. Is there any assistance provided by IETF? I also assume it is especially difficult to get the visa for folks who are not US citizens. Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 63, visa information
Is it possible to get a waiver for the visa requirements? I think for IETF61 the visa was waived for all IETF goers. -Original Message- From: Vijay Devarapalli [mailto:[EMAIL PROTECTED] Sent: Friday, June 24, 2005 11:43 AM To: Liqiang(Larry) Zhu Cc: ietf@ietf.org Subject: Re: IETF 63, visa information IETF provides you with a letter of invitation that you could use to get a visa. http://www.ietf.org/meetings/invite_letter.html to get a visa, you have to go to the nearest French Consulate. France has started issuing biometric visas, which requires you to apply in person. you cant mail the application in. more information at http://www.consulfrance-sanfrancisco.org/english/visa/en_vs_index.html Vijay Liqiang(Larry) Zhu wrote: I am not sure if this is the proper forum for how to get visa in order to go to IETF63. Is there any assistance provided by IETF? I also assume it is especially difficult to get the visa for folks who are not US citizens. Thanks. ___ 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: IETF 63, visa information
Gene, this is great. Can you please ask the French Embassy to extend the same offer to citizens of PRC and India please? I think we have a lot of those from these two countries who want to attend IETF63. Thanks, -- larry -Original Message- From: Gene Gaines [mailto:[EMAIL PROTECTED] Sent: Friday, June 24, 2005 2:36 PM To: Liqiang(Larry) Zhu Cc: Vijay Devarapalli; ietf@ietf.org Subject: Re: IETF 63, visa information Liqiang(Larry) Zhu wrote: Is it possible to get a waiver for the visa requirements? I think for IETF61 the visa was waived for all IETF goers. For IETF61 in Korea, we did not get a waiver. I obtained a letter from the Korean Embassy (in English and Korean) explaining IETF61 was a scientific meeting and a visa is not required for those meeting the below conditions. A visa was NOT required for U.S. citizens traveling to Korea providing: 1) they were a U.S. citizen and carried a valid U.S. passport, 2) were traveling to Korea for the purpose of attending a recognized scientific meeting (IETF meetings qualify) and/or tourism, 3) would be doing no business or attending business meetings in Korea, 4) would not be acting as an official of the U.S. Government, and 5) would be in the country for less than 90 days. The French Embassy in Washington DC confirmed to me this afternoon that the same conditions apply for IETF63 in Paris. That is, U.S. citizens with a valid U.S. passport DO NOT NEED A VISA to attend IETF63 in Paris (a scientific meeting) providing they do not also conduct business and stay for less than 90 days. As with IETF61, it would be good to get a blanket letter from the French Embassy confirming that IETF63 qualifies for this status. A copy can be carried by each traveler. Visa requirement for citizens of other countries are all different. Gene Gaines -Original Message- From: Vijay Devarapalli [mailto:[EMAIL PROTECTED] Sent: Friday, June 24, 2005 11:43 AM To: Liqiang(Larry) Zhu Cc: ietf@ietf.org Subject: Re: IETF 63, visa information IETF provides you with a letter of invitation that you could use to get a visa. http://www.ietf.org/meetings/invite_letter.html to get a visa, you have to go to the nearest French Consulate. France has started issuing biometric visas, which requires you to apply in person. you cant mail the application in. more information at http://www.consulfrance-sanfrancisco.org/english/visa/en_vs_index.html Vijay Liqiang(Larry) Zhu wrote: I am not sure if this is the proper forum for how to get visa in order to go to IETF63. Is there any assistance provided by IETF? I also assume it is especially difficult to get the visa for folks who are not US citizens. Thanks. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Since you top posted, I will, against nature, respond in kind. The one item you missed from your analogy is that postal mail is paid for up front, by the person posting (anon or not) - eg the post-office gets paid _before_ your letter gets delivered. The problem with spam is that the receipient is paying the cost (cod with no chance to refuse delivery)... -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED] On Thursday 16 June 2005 21:50, [EMAIL PROTECTED] wrote: I'm sure many will think this a stupid comment, but in the hopes that some don't I'll point out that the largest and arguably most efficient messaging system in the world is built upon open relay. Anyone can anonymously drop a letter in any mailbox in the US and while there's junk mail it's proportions are certainly nothing like spam. Why the difference? Well first I split spam into 2 categories: 1. legitimate advertisements for legitimate products (whether solicited or unsolicited). 2. Fraudulent mail, scams, cons, etc. I think the email abusers almost entirely fall into the second category and that nobody would be complaining if spam primarily consisted of Bloomingdale's catalogues and coupon val-paks. So I think we are attacking things the wrong way. The methods we are using - whether blacklists or 'authorized email' is going to either prove fruitless or end up ruining the big picture, which for me is electronic communication for everyone, to everyone. Using electronic means, I don't see how we can ever prevent spam and still have open global communication among disparate systems. It would be a different story if one organization ran all email servers worldwide but that horrible thought aside there will always be holes and breaks in an authentication/authorization scheme unless people limit who they can communicate with, and even then there will be spam. There's also the returns we see on our efforts to consider. Think of the millions of man/woman hours spent trying to stop spam - so many hours it probably would have taken less to inspect every email by hand. And then when you think (if you believe as I do) that everything can be gotten around and that security holes are as infinite as the imagination, well then you know there will always be some kid with a script (which also includes any real spammer) who will be able to get around your defenses within a week of them being implemented. My last unconstructive comment is that simple systems scale lossless and complex systems grow in a complexity proportionate to their size. Funny enough, I think the postal inspector's department came about because of the amount of scams being sent via mail shortly after the civil war (such a glut that it was bringing the postal service to their knees). Yet the postal service remained open-relay - why? Maybe because they realized that they didn't need to 'trace' scam-mail because scams are trace-inclusive as the scammer must include a point of contact. Sure there's the occasional anonymous letter bomb but since their resources aren't spent blocking coupon mailers they are much more likely to catch the big stuff. I know there are 8 trillion problems with this idea but I think in general, email fraud needs to become like mail fraud and there needs to be a team of inspectors who follow up on such reports and arrest violators (I know the Internet is bigger than the US, so of course it's up to each country how to handle it). I'm sorry for the non-technical post but I think blacklists are disgusting (I don't care if they help or not) and I just think so much brilliance could be directed elsewhere. Thanks and best regards, Nick Staff [EMAIL PROTECTED] -- Original message -- it's possible to have open relays that don't contribute to spam. but those relays need to employ some other means, e.g. rate limiting, to Rate limiting is a relatively recent technique. Though very useful it has... ummm, limited applicability. mostly because of blacklists. it was working fine for its intended purpose. One needs to be careful not to dismiss established techniques in favor of the latest fashionable one that is not as well fully understood. I don't know what you mean by relatively recent, but I was doing it at least as early as April 1999 - that's the last mod date on my source files. RFC 2554 only dates from March 1999. For example, rate limiting is used to control a single source. It's quite useful when used at the destination. At a sufficiently well-run source network, it also can be pretty useful. It's also pretty useful for preventing a relay from being exploited by spammers. The problem is with zombies. They make mush of old-time models of spam, since they demonstrate that a very small data stream from a single source can be leveraged into a very, very large data stream, given enough sources. Rate limiting of this type (based
Re: Last Call: 'The telnet URI Scheme' to Proposed Standard
I think it would be much more useful if we could update the document sufficiently to consider the telnet URI scheme for Draft Standard or Full Standard. The protocol itself meets the qualifications for a full Standard document; it is widely deployed with multiple independent implementations and has been quite stable for a long time. I think the document itself needs a better discussion of the limited use, security risks, and implementation methods for the user/password fields in a telnet URI, however. Larry -- http://larry.masinter.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'The wais URI Scheme' to Historic
I previously sent my comments to the IESG, but I was asked to re-raise the issue on the IETF mailing list because ... The IESG at this point seems to want public guidance on a document by document basis... on the topic of how to move old documents or protocols to Historic status. In this case, it is the raft of URI schemes currently only documented in RFC 1738. So, to recap: I think it is good to update the URI scheme documents that are in widespread, current and growing use: ftp, file, telnet to move these beyond their Proposed Standard status, update the descriptions, and bring the results along on standards track, by insuring that the documents are consistent with widespread interest. I think it is a bad idea to issue new documents for URI schemes merely to move those schemes to Historic status, wais, prospero, and even gopher. I include gopher even though there may be active or even new gopher client implementations, because I don't believe the gopher protocol or the gopher URI scheme will ever move to full standard. Does anyone see any real need to issue a new document on the gopher URI scheme merely to declare it Historic? Larry -- http://larry.masinter.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Fwd: [Asrg] Verisign: All Your ...
On Monday 22 September 2003 15:41, Dean Anderson wrote: On Sun, 21 Sep 2003, Larry Smith wrote: Both of these are perfectly valid responses. You get them at the same time, or you get the second one sooner. Not quite totally true. In the second case - it _will_ connect and initiate the transfer (helo, mail from, rcpt to) phase of _sending_ the message. It will fail, but it will make the attempt. Whereas with the first case it will never try. The second is much, much slower from the perspective of a mail server. Some may never try. Sendmail won't try in that case. But it is perfectly valid to wait and try again. In such a case, the wait time is typical 3 to 5 days. In the second case, it takes usually about 300ms to setup a tcp connection, and fail. This 300ms isn't too long to wait. I doubt that most people would notice. Quite a lot of fuss over 300ms, I think. And I am just thrilled to see IE not go to MSN when I type in a wrong name. I've been showing this to everyone. Most people like the demonstration, and trust Verisign more than Microsoft. --Dean Hmmm, maybe 300ms is not a long time for a person - but when one has say several thousand messages in queue on a server, it starts to add up quickly and this was the original context of the thread I believe - them impact on mail servers trying to deliver mail. -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your ...
On Monday 22 September 2003 19:04, Dean Anderson wrote: As was pointed out, some servers will give up right away. In either case, the user should get a bounce, and can follow the instructions as to whether the delivery will be retried or not. No. On once case your get a no such host error and never send the email in the first place and the other case gets a bounce. Not the same thing. You don't seem to understand how mail works. In both cases you get a bounce. In neither case is a message sent. Hmmm, again not totally true. In the first case (pre-Versign) the mail client (user end of the equation - at least on all my servers) would get an invalid address type error (whatever Microsoft dreams up) and hence the message would never leave their machine. In the second case (post-Verisign) the message is accepted by my server (since it cannot tell at that stage) and it (my server) will then try to deliver. Depending upon the error code, the server might bounce immediately, or it might try for x amount of time before it bounces. Significant difference between the email never leaving the client/customer machine and going to a host server and then being bounced -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your ...
On Monday 22 September 2003 20:35, Dean Anderson wrote: On Mon, 22 Sep 2003, Larry Smith wrote: You don't seem to understand how mail works. In both cases you get a bounce. In neither case is a message sent. Hmmm, again not totally true. In the first case (pre-Versign) the mail client (user end of the equation - at least on all my servers) would get an invalid address type error (whatever Microsoft dreams up) and hence the message would never leave their machine. In the second case (post-Verisign) the message is accepted by my server (since it cannot tell at that stage) and it (my server) will then try to deliver. Depending upon the error code, the server might bounce immediately, or it might try for x amount of time before it bounces. You missed the start of this discussion, I think. This is what Doug Boyer said. However, the MUA should always hand the message to the MTA portion, and the MTA should always return a bounce. We just went through why the MUA shouldn't be performing these checks. You might want to go back through the recent archives and look at this discussion. --Dean Have followed the thread and am aware of what has been said. Point still remains, your comment is that in neither case will the message get delivered - and my comment was not totally true. I am not referring to the MUA doing the check, I am referring to it being done at the MTA upon hand-off from the MUA. Pre-Verisign many mail servers (mine included) would reject a bogus or non-existant address _before_ receipt of the message from the MUA therefore leaving the message on the client/customer machine (at the MUA). Post-Verisign there is no such thing as a non-existant com or net domain from the MTA point of view (eg: it will get an answer to any and all queries for MX - the A record for verisign) hence the message is accepted by the MTA [ this constitues first delivery], then it (the MTA) attempts to deliver - and _then_ fails and is presumably returned to the originator. If I am technically incorrect please let me know, but your comment was - and I quote In both cases you get a bounce. In neither case is a message sent. which is at least partly incorrect. The acceptance of a message by an MTA for delivery constitutes a send condition to the MUA. Check any mail software you wish. If you/your mail software hand a message off to the next machine/system/server in your particular mail chain - then to your mail software the message _has_ been sent. Any Outlook user can prove this by simply checking their sent message folder. The fact that it is immediately or subsequently returned does not mean it was not sent. This is what verisign has changed... -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your ...
On Sunday 21 September 2003 15:00, Dean Anderson wrote: It never sends the email in either case. In the first case, it will say no such host, and return an error to the user. In the second case, it will attempt to connect to 64.94.110.11 and will get an error, which will be returned to the MUA. In both cases, it is permissible for the MTA to try again later in the first case. Both of these are perfectly valid responses. You get them at the same time, or you get the second one sooner. Not quite totally true. In the second case - it _will_ connect and initiate the transfer (helo, mail from, rcpt to) phase of _sending_ the message. It will fail, but it will make the attempt. Whereas with the first case it will never try. The second is much, much slower from the perspective of a mail server. -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your ...
On Saturday 20 September 2003 18:13, Dean Anderson wrote: On Sat, 20 Sep 2003, Masataka Ohta wrote: Dean; The set is the set of *registered* names. The proper and only way to query this set is through whois. The only reason to have domain names registered is to use it through DNS. The only reason we have DNS is to associate information such as IP addresses with names. Registration is far more important than the protocol. Actually registration tells who (as in what servers) to query _for_ DNS. Whois may be a useful tool for registration convenience but is of secondary importance. This is the tail wagging the dog. If you disagree, let me control DNS reply of your domain av8.com, while keeping whois response to av8.com as is. I also say that power is of secondary importance to computing. What we are interested in is the result of computing. We do not care about power, unless I give you control over the power switch. DNS has nothing to do with registration If you are arguing that verisign registration has nothing to do with DNS, I have no reason to disagree. I think you missed this: Registration - DNS DNS !- Registration The symbol '-' is read to mean implies something about. You are correct that Registration has a lot to do with DNS. But DNS has nothing to do with Registration, as I said. You cannot check a registration via DNS. This is what abusers of reverse DNS are doing, or rather, were attempting to do. Then, for DNS use, we need another registration which has much to do with DNS. Verisign can still continue to operate their current registry for com and net for their whois query, though it has nothing to do with com and net TLDs in DNS reply. Masataka Ohta My psyc professor always said - The norm _is_ - meaning that what people do, regardless of how logical, correct, or whatever, at some point becomes the normal accepted behavior. As in the statement When in Rome Such is the situation here, in that the norm has become to accept that no dns (eg nxdomain) has meant no registration or a suspended registration. Regardless of the semantics and word dicing - the norm has been changed by Versign's actions. -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Guidelines for the Use of XML in IETF Protocols
Abstract: The eXtensible Markup Language (XML) is a framework for structuring data. While it evolved from SGML -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely- used mechanism for representing structured data. There are a wide variety of Internet protocols; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. Intended Publication Status It is the goal of the authors that this draft (when completed and then approved by the IESG) be published as a Best Current Practice (BCP). Submitted to the Internet Drafts, but available now at http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.txt or http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html with a mailing list [EMAIL PROTECTED] , archive at http://www.imc.org/ietf-xml-use/index.html To subscribe to the mailing list, send a message to [EMAIL PROTECTED] with the single word subscribe in the body of the message. To unsubscribe from the list, use that same address with the single word unsubscribe in the body of the message. Larry -- http://larry.masinter.net
RE: Last Call: IETF and ITU-T Collaboration Guidelines to Informational
Shouldn't this be considered as BCP rather than Informational? Formal liaison rules don't substitute well for responsibility and judgment. I would suggest that a set of guidelines for collaboration between IETF and other organizations in general should include an analysis of common failure modes, and encourage the participants to exercise good judgment and oversight so that these don't occur. Think of it like a set of security considerations: analyze the threats and describe how the threats can be mitigated by the form of the liaison relationship. Some examples of common failure modes: *** Someone will misrepresent what's happening in the other group and present their own or their company's point of view as if it were the other group's. This was the example given earlier. The threat is that someone might be given more deference because they are from the ITU. (Note that this isn't so different from the case where a 'representative' from a Major Software vendor stands up and makes statements like 'my company will never implement X'.) *** Someone will game the system, for example, to move forward a technical proposal by telling each group that the other group wants this. So, for example, everyone in the IETF working group tries to help out the ITU by endorsing a proposal because they think the ITU needs it, while everyone in the ITU goes along with it because they think the IETF has already approved it. Meanwhile, nobody really cares or wants this feature. *** People will standards shop: They'll choose one organization or another in response to different requirements on intellectual property claims or assertions, or different requirements for security considerations, or independent interoperable implementations. One group or the other winds up considering technologies or specifications that don't meet their criteria. *** Second-guessing: When turned down by one organization because the proposal is disruptive, inconsistent with that organization's architectural or operational principals, individuals who were frustrated will take the standards proposal to another organization which doesn't have the same design principals or requirements. *** Mutual deadlock: each group is waiting for the other to finish a specification, and there is no way to easily more forward with interlinking specifications. *** Misunderstanding of other group's processes: working groups in one organization avoid doing the coordination with the other organization because of misunderstanding, fear, or deliberate sabotage.
RE: Last Call: IETF and ITU-T Collaboration Guidelines to Informational
*** Someone will game the system, for example, to move forward a technical proposal by telling each group that the other group wants this. One solution to this one might be to close the loop: if a WG is going to act on a claim that the ITU wants such-and-so, then the WG chair checks with the ITU (somehow...). And vice versa, of course. But, as we've established, it's hard to check with the ITU when the liaisons are the ones playing the game; and folks with an agenda are the ones most likely to volunteer for such roles. Just as with protocol security, you can design all of the feedback you want, but there may need to be some kind of intrusion detection to decide if you're being hacked.
RE: RFC2119 Keywords
You'd think that should be the case, and given 2119 it is all that
makes
sense, but there are way too many cases where the subject turns out to
be (explicitly or implicitly) authors of future RFCs.
In RFC 2542 (Terminology and Goals for Internet Fax) I wound up
using a notation {1} {2} {3} to replace MUST/SHOULD/MAY when talking
about what future RFCs should do
{1} there is general agreement that this is a critical
characteristic of any definition of
{2} most believe that this is an important characteristic
of .
{3} there is general belief that this is a useful feature
of ., but that other factors might override;
a definition that does not provide this element is
acceptable.
RE: An alternative to TCP (part 1)
Richard Carlson wrote: You're right, the TCP peak was 1.48Gbps from the show floor in Dallas to a storage cluster at Berkeley Laboratory. Single applications using multiple stream. Bottleneck link was 1.5Gbps provisioned circuit on Qwest link from convention center to DARPA's HSCC pop node. This beat last years (SC'99) 1.2 Gbps rate Microsoft achieved running TTCP on a single PC with 2 Gbit Ethernet cards (Redmond to Portland). Rich Peak rate alone is a meaningless measure of performance. The TCP session may have reached peak for a small fraction of the session duration and the rest of the time, the link may have been severely under-utilized. A meaningful performance measure here is average or percentile link utilization over the tcp session duration. I believe the inital question was answered, though. Peak rate alone tells me that it is _possible_ in the "near" future to exhaust the sequence number limitation of TCP. Even still, is it wise to allow for such conditions? Or would it be wiser to influence the community use larger frames over these large, fat links? ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/
RE: An alternative to TCP (part 1)
1. There are two annoying incompetence of TCP. One is that TCP does not distinguish packet loss caused by network transmission error from that caused by network congestion. The congestion control and avoidance mechanism makes TCP drop its transmit window upon detecting a packet loss, thus lowers the transmit rate even if the loss is caused by physical link transmit error. This results in an unnecessary reduction in link bandwidth utilization, especially in the environment of wireless physical links. Agreed. This discontinuity allows room for NAT-like "fixes" that don't benefit the entire well being of the Internet as an entity. This has been seen with some of the limitations of PEPs (split connections more specifically). I have explored such options for wireless systems. The trade matrix looks a lot like one for a NATed network -- good in the short term, questionable in the long term. The other is that the unit of TCP sequence number is byte (octet) while the the sequence number is only 32 bit wide. It is not a big problem for a no-more-than-100Mbps network. But in a modern gigabit network, it takes only about 36 seconds to consume the whole sequence number space when transmitting at the maximum bit rate. Is this really a problem? How often would a single TCP session have allocated to itself an entire gigabit link? I'm not aware of any end systems or apps that generate data at this rate (especially for any extended length of time), much less accept it. Maybe I'm looking at this wrong. Respectfully, -Larry This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above.
RE: An alternative to TCP (part 1)
Jun'an Gao wrote: it is probably better to do traffic shaping at the service provider network edge, for some reason of accouting, congestion control, or required by service-level-agreement Or possibly at the carrier or access network edge. Carrier networks are not necessarily owned by the service providers, which introduces another level of resource consideration. regards, -Larry This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above.
RE: solution to NAT and multihoming
Mr. Wood, Philosophically, I agree with your points in the previous email. Reality dictates another perspective. A good philosophy does not necessarily translate to realizable solutions. If this was a discussion on whether or not NAT should be used in the IPv4 Internet, your points would be well taken. As we all know, this is far from the actuality. Your arguments are somewhat like discussing how many smoke detectors to put in a building that is currently burning down. Respectfully, -Larry -Original Message- From: Lloyd Wood [mailto:[EMAIL PROTECTED]] Sent: Friday, January 26, 2001 2:26 PM To: Kevin Farley Cc: [EMAIL PROTECTED] Subject: Re: solution to NAT and multihoming On Fri, 26 Jan 2001, Kevin Farley wrote: - no, not everyone wants to run every conceivable application/protocol to their client machines, they are happy with the subset they chose. you have an interesting spin on 'choice'. How can you choose something before you've tried it? Before it's been written? - no, not everyone wants to participate in the great global address space of the Internet, they just want to access Internet-connected devices. That is tantamount to saying 'We don't need clean air! We don't even want to know what clean air is! We just need to be able to breathe!'. I'm tempted to equate the walled-garden restrictions imposed by NAT with the walled-garden restrictions imposed for copy-protection: http://cryptome.org/jg-wwwcp.htm either way, consumers are disadvantaged. Given the argument that NAT restricts the available applications and/or protocols, a potential buyer of the device must then choose the one that meets his or her requirements. or the requirements of his users. Note the disconnect of needs and interests there. L. [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above.
Original reference for 'those who do not understand TCP are doomed to reinvent it
I am authoring something in which I wish to make absolutely sure I am citing the correct and original source. Larry
Request to Join
Good morning, I would like to request to join/sign up for information regarding upcoming audio/videocasts and any other events' announcements you provide. Thank you in advance for your help. Reply with inquiry if there is more information I need to provide. Betty Lorenz mailto:[EMAIL PROTECTED]
