Re: Last Call: draft-ietf-behave-ftp64-10.txt (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
On Fri, 20 May 2011, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'An FTP ALG for IPv6-to-IPv4 translation' draft-ietf-behave-ftp64-10.txt as a Proposed Standard This is an ops-dir review of draft-ietf-behave-ftp64-10. I do not find major issues in the document. This is a somewhat complex document and I would have hoped that the spec could have been more straightforward and the result is some 50 MUSTs, SHOULDs and MAYs. But I suppose FTP legacy cases and implementations etc. make it a difficult protocol to support in the real life. substantial comments The document does not mention or discuss LPRT and LPSV. Is that intentional? The IANA registry says these are now obsolete, but RFC1639 is still experimental and no document has (formally) obsoleted these. S 5: Telnet option negotiation attempts by either the client or the server, except for those allowed by [RFC1123], MUST be rejected by the FTP ALG without relaying those attempts. This avoids the situation where the client and the server negotiate Telnet options that are unimplemented by the FTP ALG. ... what does rejected mean exactly? Does the ALG send back to the negotiation attempter some error code? Does it abort the connection? ignore these options? strip them out when connecting to the other end? 8. Default port 20 translation If the client does not issue an EPSV/PASV or EPRT/PORT command prior to initiating a file transfer, it is invoking the default active FTP behavior where the server sets up a TCP session towards the client. In this situation, the source port number is the default FTP data port (port 20) and the destination port is the port the client uses as the source port for the control channel session. .. is it? I thought the source port used by the server is orthogonal to whether pasv/port is issued. AFAIK, multiple FTP server implementations never use port 20. But I have not recently tested this myself. The ALG MUST enable or disable EPSV to PASV translation as requested. If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable it and ALGS DISABLE64 SHOULD disable it along with enabling or disabling EPSV to PASV translation, respectively. If EPRT to PORT translation is not supported, ALGS ENABLE64 only enables EPSV to PASV translation. .. what does this SHOULD..along with.. mean? I read it so that it's OK that for ALGS DISABLE64 EPSV-PASV is disabled but EPRT-PORT is not disabled? A different way to read it would be that both EPSV-PASV and EPRT-PORT are SHOULDs. editorial: -- A survey done in April of 2009 of 25 randomly picked and/or well- known FTP sites reachable over IPv4 showed that only 12 of them supported EPSV over IPv4. .. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave list. the results didn't differ much (I didn't look at the numbers), but if you want to update this, now would be the chance. If such a multi-purpose ALG forbids the use of the AUTH command for policy reasons, the side effect of making the ALG stop performing the translations described here, as well as other possible interventions related to IPv6-to-IPv4 translation, MUST be retained even if the ALG responds to the AUTH command with an error and does not propagate the command to the server. .. I had a hard time following what this one sentence includign a MUST actually requires. Maybe break down to more easily digestible sentences? [Bernstein] Bernstein, D., PASV security and PORT security, 2000, http://cr.yp.to/ftp/security.html. .. this reference is not cited in the doc, add or remove? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How to pay $47 for a copy of RFC 793
On Mon, 9 May 2011, Steve Crocker wrote: A simpler and more pragmatic approach is to include a statement in the boilerplate of every RFC that says, RFCs are available free of charge online from ... The copyright rules would prohibit anyone from removing this statement. If someone pays $47 for a copy and then reads this statement, he is unlikely to pay $47 again. I suspect those who are inclined to pay $47 for an RFC are very unlikely to read any boilerplate statements on the RFC. While I could live with this, I fear adding more boilerplate just creates more boilerplate and not much else. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
On Fri, 15 Apr 2011, The IESG wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 DNS Whitelisting Implications' draft-ietf-v6ops-v6--whitelisting-implications-03.txt as an Informational RFC This is an ops-dir review of draft-ietf-v6ops-v6--whitelisting-implications-03. The document is readable and could be published as-is. I share some of the concerns already expressed in the document, but I think the doc strikes a reasonable balance between the concerns and practical points. One bigger comment: --- Section 6 on deployment scenarios seems too black and white: either it is done ad-hoc or (completely) universally. The latter is unfeasible. The document should cover a middle ground which is already discussed in [NW-Article-DNS-WL], i.e., one or more whitelisting information providers would be used by multiple content networks. This has many benefits compared to completely ad-hoc model, and is feasible compared to universal model. The universal deployment model proposition has created ripples throughout the document (one such place is S 7.3.7), and I think the document might have been clearer if that was taken out completely -- or at least, issues related to each deployment model would be more clearly separated. .. 8.3.1. Solving Current End User IPv6 Impairments ... One challenge with this option is the potential difficulty of motivating members of the Internet community to work collectively towards this goal, sharing the labor, time, and costs related to such an effort. Of course, since just such a community effort is now underway for IPv6, it is possible that this would call for only a moderate amount of additional work. ... I would observe that ad-hoc whitelisting is already requiring a lot of work from each of whitelisting providers. Would this require more than that? If the alternative is to do nothing (no whitelisting, no user impairment notification) that is clear the winner from the selfish POV. But if the choice is between whitelisting and alerting, I don't see much difference between the two. Both could benefit from joint activities, but both can also be operated in an ad-hoc fashion. editorial: -- 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis Additional implications, should this be deployed on an ad hoc basis, could include scalability problems relating to operational processes, monitoring, and ACL updates. ... this could be read to imply that S 7.3.1-6 would be applicable to universal deployment. This is not what is meant. Maybe clarify somewhat like as follows: Previous subsections described implications that apply to both ad-hoc and universal deployment models. Some additional implications are specific to ad-hoc deployment models, namely ... S 7.5 governmental, and/or cultural conflicts, given the new control point which has be established with DNS whitelisting. For example, in one s/be/been/ [IPv6 Brokenness] Anderson, T., Measuring and Combating IPv6 Brokenness, Reseaux IP Europeens (RIPE) 61st Meeting, November 2011, http://ripe61.ripe.net/presentations/162-ripe61.pdf. s/2011/2010/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mip4-gre-key-extension-04.txt (GRE Key Extension for Mobile IPv4) to Proposed Standard
On Mon, 28 Feb 2011, The IESG wrote: The IESG has received a request from the Mobility for IPv4 WG (mip4) to consider the following document: - 'GRE Key Extension for Mobile IPv4' draft-ietf-mip4-gre-key-extension-04.txt as a Proposed Standard I've done an ops-dir review of draft-ietf-mip4-gre-key-extension-04. The document defines procedures when using using GRE tunneling between the mobile node or foreign agent and the home agent. GRE Key extention is used as for disambiguation purposes to handle overlapping address space. The specification appears to be clear enough, though it is actually specifying more than the document title suggests e.g. by adding MUST requirements for all foreign agent implementations. As a general comment, I suppose this is expected to be used in controlled environments only, because UDP encapsulation is already defined and does not (AFAIK) have these issues, and GRE is not expected to traverse NATs. As such this does not seem to be a very long-term solution. As an operational comment, I know many hardware GRE tunneling implementations don't support GRE keying in hardware. Maybe this is not a concern here. substantial issues -- The document title is a bit misleading. This document not only specifies MIP GRE key extension, but seems to be specifying how Foreign Agent (FA) MUST act when either the foreign agent or mobile node wants to use GRE tunneling. This document includes MUST requirements also for Foreign Agents that don't implement GRE (S 4.1, fourth paragraph), and even if Key extension would not be used (S 4.1-4.2). As such, Updates: RFC3344 should be required. (Or, now Updates: RFC5944) In essence, this seems to actually be a more specific Encapsulation with MIP4 specification. As a result, it would be nice if the scope of the document was laid out more clearly. Nits: - - Abstract is a bit verbose and mostly copy-paste from Introduction. - in S 4.1, reference [X.S0011-D] does not seem to exist in the references section. - RFC3344 has been obsoleted by RFC5944 -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-isis-ieee-aq (IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging) to Proposed Standard
On Tue, 4 Jan 2011, The IESG wrote:
- 'IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging '
draft-ietf-isis-ieee-aq-03.txt as a Proposed Standard
...
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-isis-ieee-aq-03.txt
This is an ops-dir review of draft-ietf-isis-ieee-aq-03.
The document provides an overview of IEEE 802.1aq (shortest path Ethernet
bridging using IS-IS) and specifically defines IS-IS codepoints for use.
802.1aq is orthogonal with TRILL wg solutions but both solve somewhat
similar issues, i.e. Ethernet network scaling and load balancing
optimizations.
Secure use of 802.1aq will probably require manual configuration of IS-IS
authentication in each device or IS-IS filtering in client ports.
The draft does not discuss interoperability with traditional Ethernet, i.e.,
how will this work in an environment where all the equipment does not
support it.
I find the document close to ready to publish after minor text improvements
and e.g. definiting how a newly allocated IANA codepoint TLV subspace is to
be managed by IANA.
Some more detailed comments below.
substantial
---
17. Security Considerations
This document adds no additional security risks to IS-IS, nor does
it provide any additional security for IS-IS.
.. while true, this is probably a bit weak. Given that the document included
a quite detailed description of 802.1aq (not just IS-IS extensions), some
brief summary would have been nice.
Some notes about this:
- This protocol is apparently intended to be used in a zero-conf
environment. IS-IS authentication cannot be used without manual
configuration. Hence a warning label would likely be useful. For
example, I suppose there is nothing to prevent a UNI port from
participating in IS-IS and 802.1aq.
- The increase of state due to broadcast/multicast is a new potential
concern, but really not that much different from the current MAC address
flooding issues.
- One particular thing that comes to mind is intentional clash of SPVID
values described in S 14.1. By claiming the highest Bridge Identifier, a
bridge could deny all other bridges all service, right?
semi-editorial
--
FDBFiltering Information Base: {DA/VID}-{next hops}
...
4. 802.1aq Overview
802.1aq utilizes 802.1Q based Ethernet bridging. The filtering
database (FDB) is populated as a consequence of the forwarding
computed from the IS-IS database.
.. is this a typo? The established spell-out form of FDB is Forwarding
Database (storing MAC-port mappings). Is overloading it intentional?
4.7. Data Path SPBV Multicast
C-DA multicast addresses may be advertised from SPBV UNI ports.
These may be configured or learned through MMRP. The MMRP protocol
... there is no reference or spell-out in abbreviations for MMRP. I
suppose youre referring to Multiple MAC registration protocol defined in
IEEE 802.1ak-2007.
18. IANA Considerations
Note that the NLPID value 0xC1 [NLPID] used in the IIH PDUs has
already been assigned by IANA for the purpose of 802.1aq therefore
no further action is required for this code point.
.. true but I suppose it wouldn't hurt to add a reference to this RFC there,
given that the defining RFC-to-be does not include any other reference other
than 802.1aq.
The MT-Capability TLV is the only TLV requiring a new sub-registry.
Type value 144 is requested with a starting sub-tlv value of 1.
.. as you're creating a new registry, I suppose you should also define the
registration policy for it? Most IS-IS TLV codepoints appear to have
Expert review, so maybe that would be appropriate here as well.
editorial
-
Traditionally [references] are not appropriate in Abstract.
It is a bit strange to see an empty Introduction section :-). Most of
Introduction is provided in Overview (S 4) though.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt (DNS-Based Service Discovery) to Proposed Standard
On Wed, 22 Dec 2010, Stuart Cheshire wrote: FWIW, Apple's code on Mac OS X uses TSIG for secure updates. You enter the credentials in the Sharing preferences pane. What the user-interface people chose to label User and Password are in reality the TSIG key name and the TSIG key data. They felt that most users wouldn't know what TSIG meant, and it was better to have something familar (but wrong) rather than something unfamilar (but correct). Sorry. BIND allows pretty flexible configurations to control which keys are authorized to update what records. What I'm saying is that having to manually pre-configure the hostname in DNS goes against what appears to be one of the main DNS-SD goals, i.e., the host can invent the hostname or use it in a zero-conf fashion. I don't think it's possible to integrate DNS-SD with secure DNS without losing at least some of the properties DNS-SD was designed to address. So it would be unrealistic to require this from the protocol, especially given its background. What I would have wanted to see is more truth in advertising how in practise using security impedes the use of DNS-SD. Which usage modes of DNS-SD can be made to work and at what cost. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
On Tue, 30 Nov 2010, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Datagram Transport Layer Security version 1.2' draft-ietf-tls-rfc4347-bis-04.txt as a Proposed Standard A bit late to the IETF LC, but hopefully these are still useful. This is an ops-dir review of draft-ietf-tls-rfc4347-bis-04 (DTLS 1.2). This looks good, but the text seems a bit unclear on IP fragmentation vs packetization. ICMP notifications passing up to the app is only a 'should' and this begs the question why. IANA considerations practicalities could also be spelled out (not sure how detailed IANA wants these to be). In more detail: If I understand correctly *), initial DTLS exchanges will typically use fragmented UDP packets due certificate sizes etc. The likelyhood of getting fragmented IP packets through firewalls and other devices is significantly lower than getting UDP packets through. The spec would be more robust and the protocol likely more applicable in the face of these 'network effects' if it tried to do packetization itself in such a manner that IP fragmentation would not be necessary. *) S 3.2.3 and 4.1.1 appear to be somewhat contradictory on this. See below. The document does not have a Changes from DTLS 1.0 (RFC4347) section that is is mandated or at least strongly recommended for update-specs. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will apply, but there are likely some DTLS specifics as well. specific comments - 3.2.3. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to 1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to avoid fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error. .. is this too weak? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure. 7. IANA Considerations This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. ... this may be inadequate. I was unable to find from the registry (tls-parameters) which of these parameters this applies to. All of them? (This was triggered by S 4.1.2.5, so at least new Cipher Suites must indicate this.) If I understand what you mean, 1) you should actually be asking IANA to reformat the registry so that there is an additional column in all the tables DTLS-OK? or some such, and possibly 2) modifying TLS 1.2 spec IANA registration guidelines (i.e. what should the IANA requesters know about when they're making their request), and also possibly 3) asking IANA to ask future registrants about DTLS-OK feature if the requestor fails to do so on their own. editorial - ... For the completeness, when referring to PMTU discovery, in addition to RFC1191 one should probably also refer to RFC1981 (the IPv6 version). [WHYIPSEC] Bellovin, S., Guidelines for Mandating the Use of IPsec, Work in Progress, October 2003. ... this should probably be rfc5406? [IKEv2]C. Kaufman (ed), Internet Key Exchange (IKEv2) Protocol, RFC 4306, December 2005. Kaufman, C., Internet Key Exchange (IKEv2) Protocol, RFC 4306, December 2005. ... remove the latter 'reference' (edit glitch?) ___ Ietf mailing list Ietf@ietf.org
Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt (DNS-Based Service Discovery) to Proposed Standard
On Tue, 14 Dec 2010, Stuart Cheshire wrote: On 17 Nov 2010, at 11:32 PM, Pekka Savola wrote: The entire document is talking about how an app developer should use it. It in this context is the domain name system. DNS-SD is not a protocol in itself. It's a usage convention for DNS records. The entire document is telling server developers what DNS records we recommend they use to describe their service, and telling client developers what DNS records we recommend they query for to discover those advertised services. It describes what app developers should pick for Instance names and Service names. It describes what data app developers should put into TXT records. If we took out all the text directed at app developers there would be virtually nothing left. They are the audience for this document. In a way, I understand that it could be argued that this is just a naming convention (also see the security considerations below). Practically, however, it could be said to describe at least the solution framework. In practise, it describes the functionality that should be implemented in a DNS-SD software library the apps can link to, or even some kind of separate sofware package. While implementing everything described here would also be doable in each application (no doubt some will do so), that would be waste. The point is underlined in e.g. how DNS-updates or related DNSSEC keying material would be configured, i.e. everything where there's more to it than just a naming convention. 17. Security Considerations DNSSEC [RFC 2535] should be used where the authenticity of information is important. Since DNS-SD is just a naming and usage convention for records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates. .. this is a bit weak. There's more stuff to put in DNS updates. See the referred sec-dir review from two years ago. The text is unchanged. The sec-dir review said I find this inadequate and this document seems to need more work. Can you suggest some specific text? DNS-SD is a convention for how to name and use DNS records. Every security consideration that applies to a client using DNS queries and updates would apply to a client following the conventions in this document. From my POV, the most important thing I'd like to see in Security Considerations section is description of that app developer will be able do the DNS updates, hopefully in a secure fashion. Some examples of what I wonder: - Is the expectation that you configure the DNS server so that certain IP's have complete access to do updates? - What does that imply? Is it possible to limit the update capability to some subtree? What kind of configuration would it need if it should be application-specific? (I.e., if one application gets out of hand, can it mess up all other apps or even the whole DNS domain?) - Or do you expect deployment of DNS security (e.g. TSIG, SIG0)? If so, how do you configure these in the app and the server within the constraints of zero-conf goals? Do the same DNS subtree limitations and caveats apply? To sum it up, I suspect the zeroconf nature of the goals of this work is likely to prevent the use of TSIG/SIG(0) in DNS-updates, or at least it requires major manual operations and/or it effectively authorizes one application to update every other application's data as well. But in some contexts it could be possible to implement it in a different way. Editorial: -- - IANA considerations does not explicitly mention 'DNS-SD profile' referred to in S 6 (though you can work out what you mean). Can you suggest some specific text? The minimal fix would be to change: This document specifies the following IANA allocation policy for unique application protocol names: to: This document specifies the following IANA allocation policy for unique application protocol names (DNS-SD profiles): ... but it would still leave IANA considerations a big ambiguous. It would be much better if the required checklist on what to report and how IANA should record it in its registry was in a tabular format. While it's not in tabular format, the bullet list at http://www.dns-sd.org/ServiceTypes.html describes this rather well. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt (DNS-Based Service Discovery) to Proposed Standard
On Tue, 26 Oct 2010, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery' draft-cheshire-dnsext-dns-sd-07.txt as a Proposed Standard This is an ops-dir review of draft-cheshire-dnsext-dns-sd. Given how widely the protocol has been implemented, I think standards track is appropriate. I think you may be able to implement and operate the protocol based on this specification, but the audience would greatly benefit from putting a bit more work in the specification. Operational perspective: I have mostly heard and seen DNS-SD used in conjunction with mDNS. I do not know how much it has been used with regular DNS. Issues like DNS updates that have only received superficial attention in this document will be present there. I'd be interested in hearing how much this is used with regular DNS and how information is in practise stored there (manual insertion vs dynamic updates). The document includes requirements and recommendations to network operators using these services (e.g. S 7.2, S 10) but it's difficult to find. General observations: - 1) This document was IETF last called, going informational, in November 2008. Many comments made during that LC I agree with and have not been addressed. See e.g. the following and the follow-ups. http://www.ietf.org/mail-archive/web/ietf/current/msg53658.html http://www.ietf.org/mail-archive/web/ietf/current/msg53712.html http://www.ietf.org/mail-archive/web/secdir/current/msg00213.html 2) I'd like to see a more detailed review from DNS directorate on this one. High-level issues have already been discussed on their list. http://www.ietf.org/mail-archive/web/dns-dir/current/msg00865.html 3) The document includes protocol specification, design rationale, to some degree product documentation, advice to application developers, requirements for DNS servers implementors, etc. in such a fashion that it's very difficult to find out who should do what. This could be improved with a document structure that makes these distinct. Details below. 4) As acknowledged by dns-dir discussion, DNS-SD is essentially a new protocol (or at least a new kind of 'usage profile') that re-uses DNS formats and semantics. It's not obvious how this should be addressed, i.e. is more truth in advertising needed. For example, it uses PTR record lookups in the forward DNS zone, may store DNS labels including '.' in DNS, and uses TXT records to store binary data. Given that document suggests DNS-SD may be used with regular DNS servers, I'd much more confortable if I saw a DNS-dir technical review for conflicts or technical issues from that perspective. Some technical details -- There is quite a bit of 'design rationale' (or: don't implement it this way) stuff in here that could probably be removed or moved to an appendix in the interest of tightening the main spec. Examples: almost all of S 4.4, second paragraph of S 5, maybe all of 6.1 except 1-2 last paragraphs, Also, there is quite a bit of text that's not specific to DNS-SD protocol, but rather how e.g. an app developer should use it. It's not obvious how that should be part of the main spec. I wonder if these could be split off to a be under a single section for clarity (e.g. most of S 8, S 15). The same also applies to operational advice to network operators (e.g. those parts of S 7.2 that deal with parentdomain and dividing by floors, etc., maybe S 10) Some are requests to DNS server implementors (S 13.1). In S 4.1: In cases where the DNS server returns a negative response for the name in question, client software MAY choose to retry the query using Punycode [RFC 3492] encoding, beginning with using Punycode encoding for the top level label, and then issuing the query repeatedly, with successively more labels converted to Punycode each time, and giving up if it has converted all labels to Punycode and the query still fails. .. would this retry with punycode, expanding each label at a time result in a typical case in at least 3 additional lookups in the case of missing services? .. it appears to me that you should provide a more precise specification isntead of 'a negative response'. Every DNS-SD service MUST have a TXT record in addition to its SRV record, with the same name, even if the service has no additional data to store and the TXT record contains no more than a single zero byte. ... why? what happens if this is not the case? will the client protocol break down and fall to pieces? IMHO, there should be a strong operational and/or service publication recommendation to publish TXT records, but on _client_ side, this kind of mandate flies against the robustness principle. The Service portion of a Service Instance Name consists of a pair of DNS labels,
Re: Last Call: draft-ietf-roll-rpl-11.txt (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard
On Wed, 18 Aug 2010, The IESG wrote: The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' draft-ietf-roll-rpl-11.txt as a Proposed Standard I've done a solicited but superficial ops-dir review of draft-ietf-roll-rpl-11. Given the document length (139p) I've had to skim most of it. The IETF Last Call expired two days ago, but for information I'm still copying the IETF list, even though this review is mainly for OM ADs' and secondarily ROLL WG benefit. A couple of comments: In general, ROLL problem space seems to be very similar to MANETs, and I wonder why a separate protocol needed to be developed here, especially given the amount of scientific research and also IETF effort put into MANETs. ROLL WG charter certainly does not mention this. Copying/modifying various IPv6 ND options for this purpose may be required but I wonder if this could have been done in a simpler fashion, without having to copy the specifications here. For example, using a TLV container option that includes non-TLV options as-is. The document mentions uniquely identifying a DODAG by the use of an IPv6 address. The document does not mention what addresses are to be used for this purpose, how they are assigned, and how these are expected to be unique. (Compare to documents on MANET IPv6 address assignments.) In S 11 on Packet Forwarding: 1. This specification only covers how a successor is selected from the DODAG Version that matches the RPLInstanceID marked in the IPv6 header of the packet being forwarded. [...] ... How is RPLInstanceID marked in the IPv6 header of the packet being forwarded? Are you modifying IPv6 packet forwarding and processing algorithms here (must look into the packets)? That would be a major change. (You're really referring to the hop-by-hop header processing here.) In general the document doesn't seem to be sufficiently upfront on the basic semantics how RPL is going to be used (from non-RPL perspective). One could argue Section 3 (some 12 pages) tries to provide an overview, but from IP perspective, it provides too much detail on e.g. tree forming and maintenance. The most important things to bring up clearly should be for example: (1) are there changes to existing packet formats or usage (e.g. does every packet include some kind of header, does this affect MTU usable in the network)?, (2) is support for these required at each node in the network, (3) are there changes to the basic packet processing in associated nodes? Upon closer inspection, some answers to these high-level questions can be found in first paragraph of S 3.3.7 and the last paragraph of S 5, but I'd really have wanted to see one or two paragraphs in Introduction. ... It is a bit strange to see that S 17 on manageability does not mention security management, because one of the key problems there (as argued in the draft as well) is how do you manually configure and maintain shared keys on all these devices. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-behave-v6v4-xlate-stateful (Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) to Proposed Standard
On Tue, 1 Jun 2010, The IESG wrote: - 'Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers ' draft-ietf-behave-v6v4-xlate-stateful-11.txt as a Proposed Standard I've reviewed draft-ietf-behave-v6v4-xlate-stateful-11 for ops-dir. I believe the document is ready for publication, but there are a couple of areas where minor clarifications could improve the document. As a general comment, spec has good detail (esp S 3.5) on how to handle TCP, UDP and ICMP query traffic, but I did not find similar detail on how ICMP errors sent in response to such traffic would affect packet processing, state tables, etc. It would be great if e.g. TCPM WG reviewed Section 3.5.2, especially its state table and said it's OK. There could be a number of unthought-of cornercases. From OM perspective, the specification appears to be sufficiently operable and configurable in IPv6-IPv4 translation. IPv4-IPv6 translation requires manually configured or unspecified bindings. Operationally this is not going to be sufficiently as the management interface is unspecified and e.g. MIB module or other configuration methods do not exist and are not in Behave WG charter. But this issue should not delay the publication of this document and rather should be tackled later, if needed. The default TCP maximum session lifetime is 2 hours (from RFC5382). I personally believe this is too small for long-lived sessions. some detailed comments: --- This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. [...] .. which material is potentially covered by this? While the non-WG version was available prior to Nov 10, 2008, the authors should be able to say so. It would be better if this disclaimer could be removed. License info is also an older version (from id-nits checker). In S 3.4: If the incoming packet is an IPv6 packet that contains a protocol other than TCP, UDP or ICMPv6 in the last Next Header, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Destination Unreachable) to the source address of the received packet. NOTE: This behaviour may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64. .. I suppose this assumes the packet is unicast, as NAT64 is an unicast-only specification. Nonetheless I'd suggest that somewhere (probably earlier in the spec) you'd explicitly say about one sentence on multicast; it's currently not mentioned at all. E.g. A NAT64 device MUST ignore any translation or actions when IPv4 or IPv6 destination address is a multicast or the limited broadcast address (255.255.255.255). (maybe with more precise definition what to do instead.) The same applies but more strongly to the following IPv4 paragraph. More strongly because IPv4 spec does not allow generating ICMPv4's in response to multicast packets while in ICMPv6 this is acceptable under certain conditions. NB: I see that IPv6 destination address is covered under 2nd paragraph of S 3.5 but a more explicit mention might be worthwhile. In S 3.5.1: * The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6 destination address (i.e. Y') using the reverse algorithm as specified in Section 3.5.4. .. S 3.5.2 can hardly be said to specify any algorithm, but it certainly doesn't even mention the reverse algorithm (however trivial it might be). In S 3.5.2: V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv4 side. The NAT64 is now waiting for a matching IPv6 packet containing the TCP SYN in the opposite direction. ... A TCP segment with the SYN flag set that is received through the IPv6 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 FIN + V4 FIN, V6 RST and V4 RST. .. this is somewhat confusing because you appear to be using V4 SYN RCV to mean only SYN flag set (due to being initiated from ...) while V4 SYN later means SYN [and possibly ACK] flag set. The same applies to V6 of course. Maybe reword? Maybe being initiated from.. and this distinction is not even necessary, because you don't have it on V4 FIN RCV side either? (Though when creating sessions, the semantics differ slightly depending on the initiator.) V4 FIN RCV, V6 FIN RCV and V4 FIN + V6 FIN are listed in the state diagram without RCV keyword, and this should be corrected. I'm also a bit hesitant to include 4 min T.O., 2hrs etc. in the diagram as these seem to be certain _minimum_ values and the implementation would be free to use some other values as
Re: Last Call: draft-ietf-dkim-deployment (DomainKeys Identified Mail (DKIM) Development, Deployment and Operations) to Informational RFC
On Mon, 30 Nov 2009, The IESG wrote: - 'DomainKeys Identified Mail (DKIM) Development, Deployment and Operations ' draft-ietf-dkim-deployment-09.txt as an Informational RFC Sorry for missing the LC DL by two days. This is an assigned ops-dir review of draft-ietf-dkim-deployment-09. The document describes DKIM usage scenarios and gives recommendations. Quoting from the document: This document provides practical tips for: those who are developing DKIM software, mailing list managers, filtering strategies based on the output from DKIM verification, and DNS servers; those who are deploying DKIM software, keys, mailing list software, and migrating from DomainKeys; and those who are responsible for the on-going operations of an email infrastructure that has deployed DKIM. As such, this is very much an operations geared document. Unfortunately, I have not looked into DKIM in detail so it's difficult to say if these practical tips are are OK and answer the questions arising from ops community deploying and developing DKIM. I'd be more confident in this if it was clear this had been thoroughly tested by these people. Some comments below: editorial - In general, I found the use of UPPERCASE keywords somewhat misleading when the advice given was to the operators and deployers, not to the developers of the protocol. It would be helpful to have an Abbreviations table up front. There are many non-spelled out abbreviations in the doc, or ones that are spelled out later, not at the first instance of abbreviation. Acknowledgedments is TBD even though we're at -09 version. Remember that its authors' responsibility to properly acknowledge all Contributors, including Indirect Contributors. (BCP78) Some of the DKIM references listed as Informative seem to be required reading to fully understand this document and it would be better to put them under Normative References. In S A.1.1.1., one of the last two paragraphs appears to be incorrectly indented. These seem logically similar paragraphs. An informative reference in Appendix 1 should be inserted to point to RFC4870. substantial --- S 3.1 Private Key Management: Deployment and Ongoing Operations .. this document describes many practises wrt private key management, with uppercase keywords. I'm not sure if using them is appropriate in this context. Some of the suggestions also seem unnecessarily strict or impractical; e.g. that private key must not be network-accessible. In practise these goals may not be worth the tradeoffs. Even in the field of DNSSEC, where the compromise of the key is a much bigger problem than here, the guidelines are more flexible. See e.g. draft-ietf-dnsop-rfc4641bis-01 (S 3.6) and its predecessor document. S 3.2: Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that provides protection against record insertion attacks and zone enumeration. In the case that NSEC3 [RFC5155] records are employed to prevent insertion attack, the OPT-OUT flag MUST be set clear. .. it is not obvious why OPT-OUT is a MUST NOT. What are the tradeoffs? I'm not sure if this document is best placed to mandate DNSSEC signing and delegation behaviour that appears to be irrelevant from DKIM perspective. S 5.1 Intended Scope of Use DKIM requires that a message with a signature that is found to be invalid is to be treated as if the message had not been signed at all. ... It follows that messages with invalid signatures SHOULD be treated no better and no worse than those with no signature at all. .. if DKIM specs require the first sentence, then the last sentence is not valid; SHOULD should be a MUST. But I don't like the upper case here anyway, and I'm not sure if the last sentence is even needed, given that the first sentence of this section already specified the behaviour. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
On Tue, 10 Nov 2009, Stanislav Shalunov wrote: But nobody will come to the technical plenary Friday afternoon! -- 1. We did come to the technical plenary when it was the last thing on Thursday, and it was in the evening. 2. If people won't come to the technical plenary, they won't come to WG meetings. If it's an unsuitable meeting time, we should not put WGs there. I tend to sympathize with this argument. I suppose WG meetings are, from some POV, more important than a plenary. So what if out of 1100 participants we get only 600 at the plenary? Maybe if the attendance drops low enough we could drop the whole plenary. Even better would be putting the administrative plenary there ;-) -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-mpls-and-gmpls-security-framework (Security Framework for MPLS and GMPLS Networks) to Informational RFC
On Tue, 27 Oct 2009, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Security Framework for MPLS and GMPLS Networks ' draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt as an Informational RFC This is an assigned ops-dir review. The document is somewhat lengthy but easy-to-read description of various security threats and mitigation techniques applicable to MPLS and GMPLS networks. A lot of the material is focused on higher-layer issues, i.e., VPNs. I would argue that the document would be more focused if security framework for VPNs and for lower-layer stuff like MPLS and signaling would be separated. But I also understand and can live with keeping them combined. Specifically, I think there is a lot of duplication with RFC 4111 (Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)) here and it's acknowledged in the document. There are a couple of places where the document appears to be overly verbose and veers into tangential issues (e.g. providing description of IPsec and IKE algorithms, modes; or 4 pages of router filtering or firewalling discussion) and I'd suggest summarizing. There are a couple of minor technical errors or omissions. IMHO, the document should be revised prior to publication. Some higher-level observations -- In S 5.2, P-to-P or P-to-PE protection is touched on only very briefly, and PWE3 protection is deemed out of scope. While these are declared out of scope or left for future study, it would have been useful to have a paragraph or subsection in Security Considerations section that underlines these remainder threats. In S 5.3, there are 4 pages dedicated to explaining how packet filtering and firewalling works. I'd argue most of that is tangential to this document and should be removed. A succint description should be possible in 0.5-1 pages. If you add informative reference to (expired, dead) I-D draft-ietf-opsec-filter-caps-09, it should cover the background. S 6 appears to discuss only SNMP/syslog type monitoring and detection mechanisms but these can only detect few attacks (usually resulting from flapping protocol adjacencies, CPU overload scenarios, etc.). The rest will fly below the radar. Other techniques such as netflow-based traffic fingerprinting are needed for more detailed detection and reporting. S 7.1.1 describes control plane protection but I believe this document should mention uRPF/ACLs towards customers and ACLs at the edges. It does mention destination-address based filtering as one possibility, but this has its own set of issues. If you're able to do comprehensive source-address based filtering, you're in a much better position to block someone spoofing your own (management or routers') IP address. The key point here is that if you're able to prevent anyone from spoofing your infrastructure IP addresses at ingress, you don't need (or you get an additional layer of protection) TCP-MD5, iBGP, IGP etc. protection. FWIW, draft-savola-rtgwg-backbone-attacks-03 describes this approach, and it may be applicable especially with smaller and reasonably well-defined service provider networks. (Some of the topics described in the draft are also touched on in S 7.2; this should also be added to S 9.3.1 point 1) S 8 does not discuss the differences of MPLS domain cross-connection in various established models, see e.g. RFC4364 S 10 options a)-c) and RFC4761 (L2VPN) section 3.4 options a)-c). One of th key issues not discussed here is whether a signalling protocol is run between service providers, or whether everything is demultiplexed/multiplexed at the border. This also has an impact on some of the security properties of the network. It seems as if the document is assuming that a signaling protocol is run between the providers; this may or may not be due to MPLS-ICI specifications but I don't know. Some more detailed comments --- In S 4.3, Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing. .. I'd observe that the TTL check in BFD is not primarily an anti-replay mechanism (the same also in S 8.1.1). Also it's not clear if the MPLS-ICI specification imposes the requirements in the last sentence, or whether these are from this document. (If these are originated by this document, this may be an issue because this is targeting Informational.) The ease of forging TCP/IP packets is the main reason network management protocols lacking strong security have not been used to configure network elements (e.g., with the
Re: Last Call: draft-ietf-l3vpn-2547bis-mcast (Multicast in MPLS/BGP IP VPNs) to Proposed Standard
I'll only comment on a couple of followups below. I think I've described my POV and I probably won't do further follow-ups. On Mon, 19 Oct 2009, Eric Rosen wrote: PekkaAt the minimum, the status (intent) of the spec should be Pekkaclarified. Even better would be to improve and include the support Pekkahere. In general, the procedures specified in the document will enable an IPv4 SP backbone to support customer use of IPv6 multicast. You are correct that section 7.4.2.2 is incomplete in this respect. Do you intend to correct this? One could argue that this does not fulfill the requirements for PS as it stands. Pekka 2) RP configuration in SP network. It's not clear if SP network Pekkaneeds to know how customer sites have configured their RPs (when Pekkathe customer provides the RP). At least traditional PIM Pekkasignalling would require SP to know this. But if auto-rp or BSR Pekkais not used by the customer, how is this information learned and Pekkamaintained? Would it require manual configuration? A PE router does function as a PIM peer of a CE router, and hence needs some way to get the group-to-RP mappings of the customer. How this is done is for the SP and the customer to determine. Do you intend to spell this out more clearly? This seems like a major configuration and OM issue? Unfortunately this does not have good solutions, and I suppose those ones that do exist do not have rough consensus in the community. As it stands it seems like the spec chose to punt an issue that is required to be resolved in order to operate the protocol. From the Security Considerations section: an implementation SHOULD provide mechanisms that allow a SP to place limitations on the following: - total number of (C-*,C-G) and/or (C-S,C-G) states per VRF Since SA AD routes are generated only as a result of creating the corresponding multicast states, limiting the number of multicast states per VRF results in limiting the number of Source Active routes. I may be missing something but it's not clear why you say so. At least in regular PIM-SM, source state can be created without creating receiver state. S 10.1.2.2 seems to imply that AD routes would be generated based on the receipt of Register messages, at which point there is not yet necessarily any join state. A more specific discussion can be found in the Security Considerations section of draft-ietf-l3vpn-mcast-bgp: In conjunction with the procedures specified in Section Supporting PIM-SM without Inter-Site Shared C-trees an implementation SHOULD provide capabilities to impose an upper bound on the number of Source Active A-D routes, as well as on how frequently they may be originated. This SHOULD be provided on a per PE, per MVPN granularity. While this is on a different spec, experience with MSDP has shown that SHOULD is insufficient; these requirements are a MUST from OM perspective. Pekka 6) PIM-BIDIR usage. May the SP use PIM-BIDIR internally even if the Pekkacustomer interface would use PIM-SM? I'm not sure I understand exactly what you are asking. The technology for building the P-tunnels is completely independent of the multicast technology used by the customer. Ok, that is what I wanted to hear. Maybe it was clear enough but I wasn't 100% sure. 3.2. P-Multicast Service Interfaces (PMSIs) Multicast data packets received by a PE over a PE-CE interface must be forwarded to one or more of the other PEs in the same MVPN for delivery to one or more other CEs. Pekka .. is this strictly accurate? doesn't this depend on where the RP is Pekka configured to be? This seems to assume that the RP configuration is Pekka always provided by the customer, never by SP? Because if RP is Pekka provided by the service provider, then the same packets could be Pekka forwarded back to the CE, without being forwarded at all to other Pekka PEs. I'm not sure I see what the RP has to do with it, but it would be more accurate to say A PE must have the ability to forward multicast data packets received from a CE to one or more of the other PEs in the same MVPN for delivery to one or more other CEs. Agreed. This underlines the need for ability, not that it actually happens. I was referring to the degenerate case where all MVPN's sources and receivers would (at that point in time) happen to be behind the same PE. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-l3vpn-2547bis-mcast (Multicast in MPLS/BGP IP VPNs) to Proposed Standard
On Tue, 25 Aug 2009, The IESG wrote:
The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:
- 'Multicast in MPLS/BGP IP VPNs '
draft-ietf-l3vpn-2547bis-mcast-08.txt as a Proposed Standard
This is an assigned ops-dir review. I'm familiar with multicast, PIM and
routing, but not intimate with L3VPNs, so bear with me. I only did a
superficial review, not looking very deep into the details of the spec.
As a high-level comment I'd say that this is more of a framework
document than an actual specification. The reason is that for almost
every feature, the spec has 2-4 different mechanisms for achieving it.
Most of these are usually non-interoperable. This is less useful than
a homogenous spec, but I believe the horse has already left the barn
and now it's up to the vendors to implement everything and the
operators to decide what they need to use in order to get the results
needed.
From the operational perspective, there are a lot of options, policy
and configuration. This can be good and flexible, but it has the
drawback that configuration is complex, and the service will often be
misconfigured, with few if any means to detect misconfigurations.
Many mechanisms also require the service provider to know the traffic
patterns of their customers (i.e., which groups should use which
traffic pattern/multicast routing optimizations). This is a challenge
and a lot of work. In some places of the spec it is also not clear
whether it's the operator or implementor which must do X (e.g., ensure
that all the required BGP attributes are included in signalling in
various scenarios and cases). Some of the configurables are listed
below as an example:
- various signalling mechanisms (BGP, PIM, RSVP-TE, mLDP, ...)
- various PMSI interfaces used and provided (which groups, MVPNs use which
technologies), e.g. the policy scenarios described in S 7.
- correct configuration of various BGP attributes
- configuration of aggregation tree (sharing P-multicast trees across
MVPNs) [e.g. S 6.3.2: This will allow a SP to
deploy aggregation depending on the MVPN membership and traffic
profiles in its network.]
- RP addresses of each C-multicast trees, unless automatically learned with
BSR or auto-rp (note that BCP in this field is to use manual config)
- whether explicit tracking is enabled (on per-flow basis)
- PHP configuration for PMSI LSPs must be disabled (S 12.1.3)
Some of bigger issues noted are below:
1) IPv6 support. The spec apparently aims to support both IPv4 and IPv6
because it refers to both in a couple of places. Yet, there is at
least one explicit place in the spec (S 7.4.2.2) that's not compatible.
I suspect many of the BGP attributes used, possibly also the MCAST-VPN
BGP SAFI and others are not IPv6 compatible. At the minimum, the status
(intent) of the spec should be clarified. Even better would be to
improve and include the support here.
2) RP configuration in SP network. It's not clear if SP network needs to
know how customer sites have configured their RPs (when the customer
provides the RP). At least traditional PIM signalling would require SP
to know this. But if auto-rp or BSR is not used by the customer, how is
this information learned and maintained? Would it require manual
configuration?
3) S 3.4.1.2 and 3.4.1.3 describe Lightweight PIM Peering Across a MI-PMSI
and Unicasting of PIM C-Join/Prune Messages. These are inadequately
specified and in conflict with PIM-SM specification. Given that these
are already practically out of scope of the specification, these sections
and text that relates to this should be removed.
4) Explicit tracking in S 5.4.2. Philosophical. Using BGP such that
upon the receipt of type-specific new information X it is required to
perform some, timing-sensitive other action Y seems wrong to me.
Has this application of BGP been adequately reviewed in IDR WG?
5) Active source BGP messages. This is a duplication of a similar mechanism
in MSDP (RFC3618) which has caused much gried in Internet. Does this
meant that when a host does 'nmap -sU 224.0.0.0/4' at a VPN site, this
will result in about 268 million BGP active source updates being sent
(2^28) in the SP backbone? This problem is not described in security
considerations.
6) PIM-BIDIR usage. May the SP use PIM-BIDIR internally even if the customer
interface would use PIM-SM? The assumption when BIDIR is applicable is not
clear. Given that using BIDIR-PIM is an all-or-nothing solution, the
only operationally feasible model would appear to be that that the
{SM,BIDIR} operational modes used by the customer and SP must be
independent from each other. Is this framework compatible with that?
7) Type 0 Route Distinguisher. The spec mandates using type 0 RD which
embeds 16-bit AS-number. Another type exists for 32-bit
Re: Retention of blue sheets
On Fri, 31 Jul 2009, Brian E Carpenter wrote: I agree with Alissa that having an explicit privacy policy would be a good idea, but the fact of participation in an open standards process certainly cannot be considered a private matter. Exactly the opposite, in fact. Indeed, but why do the blue sheets ask for an email address? I'm not interested in receiving any mail (e.g. product advertisements loosely related to the IETF protocols) based on my writing my email on the blue sheets. I accept it's good for disambiguation though asking for affiliation might achieve the same. If anyone would be able to get the blue sheets, they probably shouldn't get the email addresses. Having to write a privacy policy would require ironing out these small details which might be a goog thing. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-dawkins-nomcom-dont-wait (Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers) to BCP
On Fri, 5 Jun 2009, Russ Housley wrote: ... The IETF Executive Director, who is part of the Secretariat, already has a role in NomCom. The IETF Executive Director provides the requirements for the open positions. Would you be more comfortable if the Executive Director were named as the responsible party? Yes. I'd be even more comfortable if the text could be inclusive, for example that either NomCom chair or IETF exec director could send out the announcement, but if shared responsibility seems like a bad idea, I can accept that argument. From 10K view I have another meta-comment: The change proposal seems to be based on the assumption that the delays in ISOC president choosing a new NomCom chair may be recurring. Maybe there will be difficulties in finding a chair (e.g. interviewing them etc.), because the obvious, simplest fix (no changes needed to the process) would be to just select the nomcom chair earlier. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-dawkins-nomcom-dont-wait (Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers) to BCP
On Wed, 27 May 2009, The IESG wrote: - 'Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers' draft-dawkins-nomcom-dont-wait-03.txt as a BCP I have two issues with this. 1) This places a new responsibility at the feet of IETF secretariat. That's a new actor (not even a person but a role) in the process. This is not good. Better would be that the process allowed some already responsible party (be it ISOC president, former NomCom chair, IETF chair, IAB chair, or all of the above) the _option_ to allow IETF secretariat to perform this announcement. (More about the option issue below) 2) As proposed, the IETF secretariat's role is exclusive. In the future no one else would have the authority to publish the solicitation. I don't think this is good. The role should be optional, if _responsible_ party(ies) chooses to take that path, or at most inclusive of other parties' authority. More detailed background on 2) below: Abstract says: This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. But the new bullet says: The IETF Secretariat obtains the list of positions to be reviewed and announces it along with a solicitation for names of volunteers from the IETF community willing to serve on the nominating committee. At the NomCom Chair's request, the IETF Secretariat may perform other clerical support tasks, as long as the task being performed does not require NomCom Chair judgement, in the NomCom Chair's opinion, and as long as the community is appropriately notified that this request is being made. This request may come from the Incoming NomCom Chair (if one has been selected for this NomCom cycle) or the Outgoing NomCom Chair (if the search for an Incoming NomCom Chair is still underway). Allow can be read two ways, one of them conflicts with the actual text. Is the intent that the IETF Secretariat has an authority to obtain the list of positions and announce them (but other parties also have this authority), OR that it has the ONLY authority. The narrow reading of the actual text above suggests that in the future no one else could do the announcement. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-enum-enumservices-guide (IANA Registration of Enumservices: Guide, Template and IANA Considerations) to Proposed Standard
On Tue, 26 May 2009, The IESG wrote: - 'IANA Registration of Enumservices: Guide, Template and IANA Considerations ' draft-ietf-enum-enumservices-guide-16.txt as a Proposed Standard This is an ops-dir review. I'm only superficially familiar with ENUM, so take the comments with a grain of salt. I did not see major issues with the document, but the document could be improved by a clarifying revision. Wrt. operational considerations, given that the document deals with IANA registrations, I do not see much that should be a cause for concern. Registration documents must include a section on DNS considerations, which could possibly discuss some operational aspects as well (some of this below). Personally identifiable information has already been highlighted in the document. Management-side of OM does not appear to be relevant in this case. The usability and control of enum from users' point of view is a possible issue but that goes beyond the scope of this document. Some specific comments below: substantial --- 5.7. DNS Considerations (MANDATORY) .. I note that exampe DNS considerations mostly relate to DNS protocol. I wonder about DNS operations related considerations. For example, is the usage expected to incur a significant (quantifiable?) load on the name server chain? Are there recommendations/restrictions/assumptions wrt TTL of the records (somewhat related to the previous)? Further I assume that DNS records related to the enum services are static in such a fashion that they can be protected if needed by DNSSEC signing. Is this a correct assumption? There is no clear prohibition of defining synthetic or synthethizing DNS records that would be generated on the fly. (I'm not sure if this would even be interesting to someone...) semi-editorial -- This document specifies a revision of the IANA Registry for Enumservices, which was originally described in [RFC3761]. This document obsoletes Section 3 of RFC 3761. .. yet in the header it says Obsoletes: 3761. What about the rest of 3761? I'd say it's best that the whole 3761 gets obsoleted in some manner. The IETF's ENUM Working Group has encountered an unnecessary amount of variation in the format of Enumservice Specifications. The ENUM Working Group's view of what particular information is required and/or recommended has also evolved, and capturing these best current practices is helpful in both the creation of new Enumservice Specifications, as well as the revision or refinement of existing Enumservice Specifications. .. yet the revision of existing Enumservices Specification is only touched upon in Section 8, which says doing the revision is a MAY. Is this sufficient? (After reading the whole doc, it appears that there is an effort in progress to revise these, but it is not clear if that process is exhaustive.) In Section 9, you describe extension of existing enumservices. If an enum service is extended, does the extended version need to comply with this document (Section 8 could be read to imply that but this is not 100% clear)? Types and Subtypes MUST conform to the ABNF specified in [I-D.ietf-enum-3761bis]. The ABNF specified in [I-D.ietf-enum-3761bis] allows the - (dash) character for Types and Subtypes . .. when I search for ABNF in I-D.ietf-enum-3761bis, I come up with one hit, and it seems to be in an irrelevant spot. I'm not sure if ABNF is defined clearly enough in I-D.ietf-enum-3761bis (and that document could be improved); in addition, given this is not very clear, I'd suggest a more specific reference in this document (e.g. pointing to specific sections of 3761bis one should conform to). 6.5.3. Outcome 3: Experts Reject the Registration Document The expert might reject the Registration, which means the Expert Review Process is discontinued. For appeals, see Section 7.3. .. I'm not sure in which case the result might be a rejection instead of changes needed, but should you also point to some other recourse other than the appeals process? For example, Go back to step 1 and reconsider whether a registration is needed. :-) 7.2. Review Guidelines .. one of the things that could perhaps be explicitly listed here is verifying that the type name does not conflict with any well-known other name (e.g. the example given in the document where imap was proposed for internet mapping service). 11.1.4.2. Published as generic Specification .. in S 11.1.2 you require IANA to escrow the specification, so I guess it should be stated in the required IANA steps in the last paragraph of this section as well. 13.1. Normative References [RFC2223] Postel, J. and J. Reynolds, Instructions to RFC Authors, RFC 2223, October 1997. .. this is a down-ref problem: BCP referring to an informational document. Is this critical for understanding this document? If not, it could be moved to an informative reference. editorial
Re: several messages
On Fri, 14 Nov 2008, Chris Lewis wrote: DNSBL system is organized to send NDNs rather than rejecting messages or because there are relays (including SMTP-handling firewalls) involved -- things are basically hopeless because the number of mailing list servers that are able to accept NDN messages, correlate them with particular addresses on particular mailing lists, and take action on that basis is, well, small. I don't agree. In fact, most ESPs, Yahoo, and many common list implementations (eg: mailman and I believe LISTSERV) have and use this capability now. With ESPs, for list pruning. At times, I've become quite familiar with Yahoo's your subscription bounced too often, I've unsubscribed you, here's how to resubscribe, and here is your missed messages. Annoying, but no great harm. Hasn't caused me to change how the filters that caused those bounces work. FWIW, on one mailman mailing-list, I've received the following a couple of times; I've not received it on others, which may mean that those lists don't enable it, or that the mails on those lists have not triggered rejections. I suspect the former. Your membership in the mailing list FOO has been disabled due to excessive bounces The last bounce received from you was dated 24-Jul-2008. You will not get any more messages from this list until you re-enable your membership. You will receive 3 more reminders like this before your membership in the list is deleted. ... [what follows is the URL to re-enable membership immediately] I have found this message incredibly helpful, and I'd like to see a wider application of similar behaviour. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats - limitations of 6to4
On Thu, 13 Nov 2008, Rémi Després wrote: If an implementation implements RFC3484 and the user is not using custom address selection policy, all compliant RFC3484 implementations should prefer v4 when connecting to native from 6to4 (rule 5 of destination address selection AFAIR). Actually, my above statement is incomplete. Thanks for your eagle eyes :-) In case the user has a RFC1918 IPv4 address and the destination is global v4 address, you'd use 6to4. In case IPv4 address is global and destination is global, or both are RFC1918, you would use IPv4. As such: Can we derive from this that Google's IPv6 address is necessarily 6to4 (most of its US customers using it are 6to4), and that Google has therefore a guaranteed path toward other 6to4 hosts? I believe Google is using native addresses. The 6to4 hits are probably caused by the users with private v4 addresses or users whose implementation does not support rfc3484. Besides, isn't this a strong reason in favor of native IPv6 (albeit like Free did it with 6rd on its IPv4 infrastructure) vs 6to4? Native is in many cases better than 6to4 or Teredo (but in some cases 6to4 - 6to4 is better than native). But this is something I specifically didn't comment on in my mail. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats
On Wed, 12 Nov 2008, Iljitsch van Beijnum wrote: In my opinion, this is a bug. This is the default policy table from a FreeBSD system, which is the RFC 3484 table IIRC: You should probably bring this up on 6MAN WG list then. ip6addrctl Prefix Prec Label Use : : 1/128 50 00 : :/0 40 1 646064 2002::/16 30 20 : :/96 20 30 : : :0.0.0.0/96 10 40 The last line catches IPv4. It's two steps below the 6to4 prefix. However, the fact that the label for the 6to4 prefix doesn't match the ::/0 label means that IPv4 will be used. This happens on FreeBSD and XP, and I assume also on Vista. But not on MacOS, because it doesn't implement the policy table. I don't know about Linux. (If you want to test, try to connect to 6to4test.runningipv6.net and see what happens. Both addresses are unreachable, though.) I'm not sure whether you're agreeing with me or something else; I don't see where you're saying the bug is. But if we start talking about issues in RFC3484, it should happen on 6MAN list. Your test is inconclusive due to the fact that the A record is a private address. Depending on whether the connecting host has a global or private address, the results are different (see my mail to Remi for more). -- 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://www.ietf.org/mailman/listinfo/ietf
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
On Fri, 14 Nov 2008, Mark Andrews wrote: In message [EMAIL PROTECTED], Tony F inch writes: You also need the server to provide a verifiable TLS certificate. The vast majority of them are not. This problem is perhaps even harder to fix than the lack of DNSSEC. Just use DNSSEC and CERT records to do that. ... If self signed, look in the DNS for the CERT. Accept if signed and validated by DNSSEC. How does an application do accept if signed and validated by DNSSEC? -- 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://www.ietf.org/mailman/listinfo/ietf
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
On Fri, 14 Nov 2008, Mark Andrews wrote: How does an application do accept if signed and validated by DNSSEC? You validate the CERT RRset using the techniques in RFC 4033, 4034 and 4035. If the answer is secure then it was signed and validated. You the match offered cert to the CERT RRs using the information from RFC 4398. Do you need more detail or is that enough guidance? I was interested in more detail, specifically, are there application interfaces an application could use, or every app need to implement validation using 4033-5 techniques (a lot of work, and most would probably do it wrong)? -- 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://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats
On Wed, 12 Nov 2008, Harald Alvestrand wrote: On Tue, 11 Nov 2008, Harald Alvestrand wrote: The correct number from the presentation is 0.238% - only Russia, Ukraine and France have more than 0.5% IPv6. Presentation available from http://rosie.ripe.net/presentations-detail/Thursday/Plenary%2014:00/index.html. Depends on what you're looking for, but if you are interested in the amount of users that have any kind of IPv6 connectivity, this undercounts severely because address selection rules on recent OSs typically select IPv4 if their connectivity is 6to4 or Teredo. can you identify the OSes that prefer IPv4 when on 6to4, and pointers to docs? If an implementation implements RFC3484 and the user is not using custom address selection policy, all compliant RFC3484 implementations should prefer v4 when connecting to native from 6to4 (rule 5 of destination address selection AFAIR). FWIW, in Linux this was changed as the default maybe about 2-3 years ago. I suppose may other operating systems, especially recent ones, also operate in this manner. For Linux, some info is here: http://people.redhat.com/drepper/linux-rfc3484.html This has been discussed on v6ops and ipv6 lists but unfortunately I can't find the threads despite search attempts. Maybe someone else with better memory could provide better references. This is why observing ipv6 traffic on a dual-stack hostname will mostly just in observing those that use native v6 (with Mikael, this was 0.5% of users). If you're interested in wider picture of IPv6 penetration, you'll put the content on v6-only hostname (with Mikael, this was reachable by 6% of users). If you want to also cover for Vista users with Teredo, you'd put the content on a site and refer to it using a numeric address instead of a hostname (this would result in even a higher percentage). So, if you're interested in any kind of IPv6 connectivity at all (even 6to4, teredo, ...), at least in some user communities (p2p users), I'm pretty sure IPv6 penetration is already over 10%. At least 6% is already proven by measurements :-) -- 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://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats
On Tue, 11 Nov 2008, Harald Alvestrand wrote: The correct number from the presentation is 0.238% - only Russia, Ukraine and France have more than 0.5% IPv6. Presentation available from http://rosie.ripe.net/presentations-detail/Thursday/Plenary%2014:00/index.html. Depends on what you're looking for, but if you are interested in the amount of users that have any kind of IPv6 connectivity, this undercounts severely because address selection rules on recent OSs typically select IPv4 if their connectivity is 6to4 or Teredo. Mikael Abrahamsson made a test on a p2p-related web-site, and the result was that 6% of users had IPv6 connectivity: http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01582.html As shown in later messages, the figure is actually even higher. Teredo users running Windows Vista are not included in that 6% because Vista doesn't do do lookups at all if all you have is Teredo connectivity. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard
On Mon, 20 Oct 2008, The IESG wrote: The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv6 Bulk Leasequery ' draft-ietf-dhc-dhcpv6-bulk-leasequery-04.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 2008-11-03. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-ietf-dhc-dhcpv6-bulk-leasequery-04.txt First there was DHC Leasequery (RFC4388), next DHCv6 Leasequery (RFC5007), now we have DHCv6 Bulk Leasequery. And someone seems to be proposing DHCPv4 bulk leasequery as well (draft-dtv-dhc-dhcpv4-bulk-leasequery). RFC4388 S4.2 described reasons why SNMP was deemed inappropriate. And if you look at the reasoning there, some of these are not even valid anymore for bulk leasequeries. I remain unconvinced. A far better solution would seem to be define a smaller MIB just for querying leases so implementing it would be trivial. Bulk leasequeries just underline the fact that SNMP and MIB data models are being reinvented inside DHCP. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard
I was hoping some folks more intimate with SNMP and IETF management frameworks would chime in here, but I'll respond to clarify: On Tue, 21 Oct 2008, Marcus wrote: I am not an expert on SNMP, but the only way I could imagine that working, would be by using queries for MIBs which would look like this: get MIB.querytype As the query type can be a relay id, link-address or remote id, this would look a bit strange to me. I know and use SNMP mostly for querying specific, predefined counters or tables, not variable entries in the MIB tree. If I understand what you want to achieve, what you want is supported and indeed used by lots of MIB modules out there. This is useful and indeed we use it regularly with e.g. BGP and IP forwarding MIBs: $ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46 IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.0.255.255.255.0.0.0.0.0.0 = INTEGER: netmgmt(3) IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.254.255.255.255.255.0.0.0.0.0 = INTEGER: local(2) Also all implementations I know, use UDP not TCP for SNMP queries and replies. The DHCPv6 Bulk Leasquery proposal looks like a logical next step to me. An open-source SNMP implementation (net-snmp) is at least available. SNMP over TCP is defined in RFC3430. The systems under consideration already support TCP, just the TCP SNMP server part is missing; this should be trivial to implement if there is a need -- the lack of implementation efforts seems like an indication that UDP with retransmissions is usually good enough. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Application-Layer Traffic Optimization (alto)
On Mon, 6 Oct 2008, IESG Secretary wrote: - A requirements document. This document will list requirements for the ALTO service, identifying, for example, what kind of information P2P applications will need for optimizing their choices. ... I believe this work could be useful and would provide an improvement over existing p2p usage and traffic management. I'd be more comfortable with this effort if a recharter (this is a rather lightweight process) was needed after finishing the problem statement and the requirements. It would also encourage that people actually put some serious work on those before diving into solutions :-) There are significant design issues that will come up in the protocols and I'd expect that it would be helpful if those had already been dealt with in the requirements phase. For example, the current req document has: REQ. 4: ALTO Clients MUST be able to find out where to send ALTO queries. .. and the charter lists DHCP option or SRV record as examples. Both of these have issues in certain contexts. For example, must this discovery mechanism work across unmodified NAT boxes? DHCP option doesn't; SRV record in many contexts doesn't either (or otherwise you'll end up with the same how to you discover the domain name under which you should look? problem). -- 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://www.ietf.org/mailman/listinfo/ietf
RE: Call for review of proposed IESG Statement on Examples
On Fri, 19 Sep 2008, [EMAIL PROTECTED] wrote: BTW, http://www.rfc-editor.org/rfc-editor/instructions2authors.txt does not absolutely require including an email address (if you give some other contact method, such as postal address or telephone number), and there are RFCs that don't include it (e.g RFC 3718 from 2004; perhaps others exist, too). There are also cases wheres where contacting the author would require somewhat unconventional methods, e.g. RFC 3542... What disturbs me as a reviewer is when a draft does not include email address(es) of authors or where comments should be sent. I'm having difficulty figuring out the usefulness of such a draft. FWIW, IMHO, any spam argument seems bogus. Anyone actively participating is already leaving such an email address footprint all over the net (including elsewhere in the IETF) that a) they already need protection mechanisms, and b) obfuscation methods (if used) should be reasonable. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Guidelines for authors and reviewers
On Tue, 3 Jun 2008, Ted Hardie wrote: Can you describe the difference between early reviews performed by active participants and just participation? In my mind, folks making suggestions and noting issues with a document during the working group phase are WG contributors, not reviewers. How do you see this? If the reviewer is not subscribed to the WG list, and does not intend to become subscribed to the list, yet does a review and sends comments for a WG draft, then I'd say it's in the former camp. Personally, I usually do that. And it's a PITA that most WG mailing lists where I try to send mail unsubscribed just throw the mails to a black hole or a moderation queue that's never flushed. This is why I Cc: the WG chairs on these messages. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: RFC 3484 Section 6 Rule 9
On Mon, 2 Jun 2008, Mark Andrews wrote: This rule should not exist for IPv4 or IPv6. Longest match does not make a good sorting critera for destination address selection. In fact it has the opposite effect by concentrating traffic on particular address rather than spreading load. I received a request today asking us to break up DNS RRsets as a workaround to the rule.Can we please get a errata entry for RFC 3484 stating that this rule needs to be ignored. I doubt that. Errata seems like a wrong place to revisit WG decisions. (I take no stance on the issue itself.) -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-number-0-bw-te-lsps (A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link) to Propo
On Fri, 11 Apr 2008, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link ' draft-ietf-mpls-number-0-bw-te-lsps-09.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 2008-04-25. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I've reviewed this document for OPS-DIR. My general observation is that trying TE bandwidth signalling to IGP advertisements seems somewhat dubious. For example, when a TE signalling protocol adjusts reservations on a link, IGP information gets outdated and needs to be refreshed, causing churn in the local routing system. But this concept is not introduced by this document and as a result I do not see significant operational issues with this document. With regards to the management aspects, the document says: Unconstrained TE LSPs that are configured and provisioned through a management system MAY be omitted from the count that is reported. Which is interesting because document doesn't specify what would set this information in the first place. My assumption during the reading was that the TE signalling protocol would notify the IGP of changes using implementation's internal API. But aren't TE signalling protocols usually just applying policies configured at a management system, so the message above might also also apply? How does the IGP know how TE LSP was provisioned and if it should be included in the calculation or not? FWIW, I'd expect that the value need not be configured manually or adjusted using network management such NETCONF or SNMP write. The value should be readable using SNMP but I don't know if TE signalling protocol MIB modules provide this information to network managers. procedural and editorial issues --- I'll note that the normative reference (and I believe it needs to stay normative) I-D.ietf-ospf-ospfv3-traffic is marked Dead in the I-D tracker, having been expired some time ago. This document is going to wait for the publication of I-D.ietf-ospf-ospfv3-traffic and I'd hope the latter would get done soon. This document makes a normative reference to IS-IS TE RFC 3784 which is currently informational. This causes a procedural down-ref problem. RFC 3784 is being revised on standards track and I guess the reference could be updated to point to draft-ietf-isis-te-bis which is currently in Publication Requested - External review. Reference to RFC2470 (IPv6 over token ring!) should be to RFC2740 :-) (or upcoming draft-ietf-ospf-ospfv3-update) -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
On Wed, 16 Apr 2008, The IESG wrote: o Rejected - The errata is in error, or proposes a change to the RFC that is clearly inappropriate to do with an errata. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using other channels than errata, such as a WG mailing list. o Archived - The errata is not a necessary update to the RFC. However, any future update of the document should consider this errata, and determine whether it is correct and merits including in the update. ... One of the guidelines says: 8. Changes that modify the working of a process, such as changing an IANA registration procedure, to something that might be different from the intended consensus when the document was approved should be Archived. I do not understand an errata that suggests changing the defined process should be Archived. Shouldn't this be flat out Rejected? The problem I see with this proposed errata process is that Archived tries to fill the gap for the need of an issue tracker for substantial change suggestions (today these are sent to a subset of authors, WG chairs, and/or WG mailing list if active, but are rarely tracked systematically). I don't think the errata process should be used to track substantial change proposals. That procedure needs to be separate from the errata process, and it the best place for it would probably be at @ietf.org. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-multicast-encaps (MPLS Multicast Encapsulations) to Proposed Standard
On Fri, 11 Apr 2008, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Multicast Encapsulations ' draft-ietf-mpls-multicast-encaps-07.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 2008-04-25. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I did not look into this in detail because I claim no expertise in MPLS, but... I believe this document needs a normative reference to draft-ietf-mpls-upstream-label (now in Last Call) because the whole concept of upstream labels is introduced in that document and it seems vital to understanding and implementing this RFC. IANA considerations section should describe how IANA should reword the unicast codepoint and multicast codepoint assignment fields. It seems clear that these should be renamed to better reflect the reality introduced in this document. The document does not describe the impact (of lack thereof) of redefining the usage of existing codepoints and modifying existing standards (e.g. the MPLS-in-IP and MPLS-in-GRE encapsulation rules and what may or may not happen in a non-compliant decapsulator). Section 6 gives instructions how to handle unicast and multicast destination address. It does not describe how to handle the v4 255/8 broadcast address and it's debatable which category would apply if a packet was sent to a regular broadcast address such as 192.0.2.255/24. Should this be described for completeness or explicitly declared out of scope? editorial comment - Abstract is a bit long and has a typo: s/The former multicast codepoint/The latter multicast codepoint -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
and securing the feedback return channel; how to ensure the reports are valid even if they come from an authenticated receiver). I'd like to see that draft referenced here. It's not clear to me whether it would be reasonable to ask that this document should not go forward until sec-discussion goes forward; if that is not reasonable, I believe this document's security considerations needs some additional work especially wrt the unicast feedback channel; section 6.1.1 and its subsections already discusses the multicast part in some detail (I'm not qualified to evaluate whether that's sufficient), but while the first paragraph mentions unicast, it is not obvious whether it's fully covered in the text that follows. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
On Thu, 3 Apr 2008, The IESG wrote: The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'Multicast Negative-Acknowledgment (NACK) Building Blocks ' draft-ietf-rmt-bb-norm-revised-04.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 2008-04-17. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Meta-level comments --- Looking at the document, my main question is, is this ripe for standards track?. Looking at it, my inclination would be to say probably not, at least in parts *). As Section 6 says, there have not been substantial changes since the preceding experimental RFC 3941 was published in 2004. All the cited material (research etc.) predates RFC 3941. So it seems that either 1) there has not been significant experience since the Experimental document was published, 2) the experiences have been fully aligned with the earlier document (the document was already good enough), or 3) the lessons learned have not been reflected in this document revision. The one thing I'd have been interested in seeing is an applicability statement of reliable multicast and its different bits and pieces (beyond what's in Section 3.11) but that seems out of scope of this document. For example, it is not obvious to me which (if any) RMT mechanisms would be applicable in a context where I want to distribute video or voice where it isn't acceptable to buffer the stream too long to accommodate for data resends; it seems this NACK mechanism is geared towards bulk file transfer where this is not applicable. *) the parts I'm mostly concerned with are router assistance and security (also touching the protocol/ops aspects when some receivers are misconfigured or behind slow links). Substantial --- I was expecting to see some discussion of MTU and application framing issues with multicast. Specifically, in a big multicast tree with dynamic membership, it could very well happen that when a new member joins, the lowest common denominator MTU decreases. How is this scenario expected to be handled? It may be that this issue has already been discussed somewhere else as it isn't specific to this document. I doubt router/intermediate system assistance has seen very wide deployment and I don't think it is very feasible to expect to see that. As this document is moving to Standards Track I would very much like to remove any recommendations for router assistance because I don't see those being implemented in any significant router implementation. That means removing and rewording e.g. sections 2.7, 2.4, 3.10 and some others. The sender's transmissions SHOULD make good utilization of the available capacity (which may be limited by the application and/or by congestion control). How do you figure out what is the available capacity? Are you referring to the capacity on sender's uplink or the collective capacity of the receivers or both? Do you adapt to the lowest common denominator of all receivers (e.g., document previously quoted 56Kbit/s modems..)? Does this have security impact? (Similar comment would apply to MTU/application framing aspects already mentioned above.) In absence of a group size determination mechanism a default group size value of 10,000 is RECOMMENDED for reasonable management of feedback given the scalability of expected NACK-based reliable multicast usage. What is the impact of this recommendation? Is it safer to recommend too small or big? Given that this would likely be close to a world record in production multicast group size, I'm not sure if this recommendation is reasonable; if it is deemed reasonable, it would be nice to have a citation justifying the number. This is one area where figures based on experimentation would have helped. However, if recommending too big doesn't cause a problem even when the typical default size would be 10, 50 or 100 receivers, then it would be OK. NACK-based reliable multicast is compatible with IP security (IPsec) authentication mechanisms [RFC4301] that are RECOMMENDED for protection against session intrusion and denial of service attacks. The details how one might apply IPsec to the unicast channel are absent. I'm not commenting on the multicast delivery part because that is somewhat covered though details are fuzzy. Unicast has two major issues that I did not see clearly addressed: 1) malicious, misconfigured or under-performing (beyond small capacity links etc.) receivers. Is there even a way to differentiate between these classes of receivers? When these send a lot of NACK feedback, progress of the stream is deterred. How do you
The purpose of blue sheets [Re: Blue sheet harvest]
Has the purpose and the expectations of the blue sheets been established somewhere? So far I've seen (or sen folks justifying) the following use cases: 1) gauging the number of people in the room (for room size allocations for the next meeting) 2) identifying later on whether someone sat in the audience (for IPR purposes, not clear to what benefit exactly) 3) identifying previously-unknown people who spoke up in the mike and said their name but you weren't sure if you got it right (for the minutes). (i.e. identifying who made a Contribution in IPR rules sense) 4) identifying a person like 3) who has never posted on the mailing list and contacting him/her about the comment (otherwise you wouldn't know the email address) 5) contacting participants later on about future activities in the area (e.g. BOF list creation). 6) WG chair giving extra advice that if you mark an X beside your email address, s/he will subscribe you to the mailing list. 1) does not require email addresses, and possibly not even blue sheets. This seems like the typical reason given by the WG chairs for the blue sheets (if you don't sign, we won't get a room next time..). I'll observe that 2) appears to be useless because whether or not a name exists is no proof one way or the other. The critical thing here is whether someone made a Contribution (in the IPR sense) at the meeting. So, it's likely necessary to be able to identify everyone that speaks up in the mike, but whether or not the blue sheets is the right tool to do that is debatable. 3) and 4) seem like useful goals, but yet again, this seems an issue of identifying the person speaking up in the mike, not who sat in the room. 5) only seems necessary with BOFs etc that have not been managed properly (a mailing list needs to be set up in advance in any case; if persons are not signed up on appropriate lists, mass-mailing them (isn't that spamming?) doesn't seem to be a very useful excercise). I don't know how useful 6) is in practise; anyone should be clueful enough to sign up on the mailing list herself. Some more below, On Fri, 4 Apr 2008, Scott O. Bradner wrote: and signing the sheet is strictly voluntary to date well, there are no guards with guns watching but someone who decides to not sign is not being honest about their participation I've personally used somewhat looser definition. I don't bother to sign those blue sheets that circulate in WG rooms where I just go (for the lack of better place) to read my email and get a bit of idea what's going on. I don't intend to say anything on the mike, I have no interest in participating in that WG otherwise and I don't think I should be counted when it gets decided what room size is appropriate for the WG in the next IETF. How exactly is it wrong not to sign the blue sheet in this case? Another category is after WG meeting X ends, go to the room used by WG meeting Y to see what's going on there. At that point, blue sheets have already circulated and it seems too much of a bother to sign anything anymore. In this case, you might even say something in the mike; whether your name exists on the blue sheet or not doesn't guarantee whether you were present or not, and I don't see it practical to change the procedures to be any stricter. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
On Wed, 26 Mar 2008, Jim Fenton wrote: I keep trying to understand why the SMTP use of records should be any different than its use of A records. Haven't heard a solid explanation, nevermind seen consensus forming around it. It seems there are two ways of looking at this: (1) records in the IPv6 world should do exactly same things as A records in the IPv4 world, so SMTP should look for an record in the absence of an MX record, just as A records are used in the absence of MX records. (2) Although some SMTP servers will continue to be found through A records for legacy reasons, there is no longer a good reason for any new server not to have a published MX record. SMTP clients (senders) will, of course, need to continue to look up A records, but since there is currently no significant use of records for email routing, we should not perpetuate this legacy in IPv6 as it is in IPv4. These are both reasonable positions, but I'm in camp (2). The additional use of records for email address resolution would add complexity to at least some implementations and test cases, and it something that should never be needed: v6 mail handlers will just publish MX records. There is probably a small DNS efficiency argument as well, especially if the MX, A, and requests are not made together. I agree with Jim's characterization and IMHO both positions are reasonable. I also prefer (2) because I don't think the original A fallback was meant to stay there very long and we just never got around to deprecating that feature. If you ask a random sampling of postmasters and DNS domain owners, I doubt many would even remember right off the bat that such a fallback exists. Further, given that the feature in and of itself does not provide any additional value, I don't see why the practise should be propagated to IPv6. But if the majority were to favour (1), that would be fine with me as well. Additionally I believe this is not an issue we as the IETF should get stuck at for a longer period. Reaching closure, whichever decision it is, in the timescale of a couple of months, is IMHO better than a very strong consensus on the approach. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
On Sat, 29 Mar 2008, John C Klensin wrote: I also prefer (2) because I don't think the original A fallback was meant to stay there very long and we just never got around to deprecating that feature. If you ask a random sampling of postmasters and DNS domain owners, I doubt many would even remember right off the bat that such a fallback exists. Based on some small experience with email deployment and operations, I believe that you are wrong. Indeed, if you asked a random sampling of those groups --remembering that there are a huge number of SMTP servers in the world, only a tiny fraction of which are professional operations and with an even smaller fraction being large-scale, carefully-managed production ones, you might discover that many of them had forgotten that there was such a thing as an MX record and how to set it up. Point taken, but I don't believe this really applies to IPv6 yet. ... Certainly, one could go around this loop for months, with people repeating themselves in ever-louder ways, but do you really think that would move us forward or result in a better or clearer consensus? IMO, it is time to decide and move on. Like several others, I think it is more important to decide than what the decision is. Days would be good. Maybe a week or so is tolerable. But certainly not months. I was not precise and you misunderstood. I was saying timescale of months because I didn't want timescale of years. (I've been a bit disappointed with IETF's speed of progress lately and the latter seems to be the timescale we're working with in any consensus process whatsoever.) Faster is fine with me if the document shepherd, editor and the AD manage to read the consensus and decide on the right approach in that time. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC
On Fri, 28 Mar 2008, Jari Arkko wrote: This would be very useful addition to the document. Authors? But note that the overall experience from the specific approach chosen here was that yes, its possible get it to working, but there are significant issues both for deployment and for the way the protocol bits are arranged. Remember that this was an experiment, not a design ready for standardization. MTU problems are in the list that is in Section 5.3. A lot of issues are brought up in Section 5 (and elsewhere). For issues noted, for each I'd like to ask quostions such as: - was this noticed in the testbed? how? - was the issue relevant in that context; if not, why not? - if the issue was noticed, how was it worked around? which approaches worked (in that restricted context), which did not? - if the issue was not worked around, what kind of impact not doing so had in the testbed and in testing? I suspect some of the issues listed were addressed in some way (not necessarily in a globally applicable way). For example, wrt MTU issues, a statement like MTU increase was not an issue because the transit network provided 9000B MTU or Participating hosts were manually configured to use 1280B MTU would have been useful. So, when reading the report, I find it has basically the following kinds of content: 1) some general overview of the problem space 2) description of new mechanisms developed 3) description of the testbed where mechanisms were tested 4) description of issues to be considered in future work However, 4) seems to be mainly about 1) and 2); it would have been possible to write fundamentally the same draft without any significant testbed deployment. In other words, the experiences from the testbed and deployment itself are not extensively captured in the report, and as a result it is not obvious how useful the testbed was when considering follow-up activities in this space. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comments: What Makes For a Successful Protocol?
On Wed, 26 Mar 2008, IAB Chair wrote: The document can be found at: http://www.ietf.org/internet-drafts/draft-iab-protocol-success-03.txt The document seems to be in good shape and is useful. Two comments: Case study A4 discusses inter-domain multicast vs application overlays. It seems as if the text is focused on inter-domain _ASM_ multicast; some of the facts stated do not apply to SSM. I'm not sure what would be the best course here: rephrase the case study to be about ASM multicast or generalize slightly. Case study A7 discusses radius vs tacacs+. As a historical point, tacacs+ 2.1 from 1995 [1] had a very non-explicit boilerplate [2] and it's not obvious if there were any real restrictions to using it. I don't remember anymore if there was something more to it but I certainly used :-). In later versions, (4.0.4 from 1998) [3], the license was more explicit and pretty much like the old BSD license. From that perspective, unless I'm missing something, it seems as if tacacs+ had open code and was more or less restriction-free. [1] http://www.mirrorservice.org/sites/ftp.wiretapped.net/pub/security/authentication/tacacs/tac_plus.2.1.tar.gz [2] * Copyright (c) 1995 by Cisco systems, Inc. * All rights reserved. * Please NOTE: None of the TACACS code available here comes with any * warranty or support. [3] ftp://ftp-eng.cisco.com/pub/tacacs/obsolete/ -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
On Wed, 26 Mar 2008, Markku Savela wrote: You seem to be of the opinion that fallback behavior should be extended to , and you seem to be the first one to express that opinion. (I myself have no opinion on how to resolve this other than believing it has to be resolved - the present ambigiuty is unacceptable.) As a private person using the A record only way of receiving mail, I find it useful. It might be helpful in this context if you could elaborate a bit why you find it useful? The only reason I can think of is if (web?) UI of DNS hosting company would make it burdensome to update both MX and the A record. As John Klensin wrote on Tue, 25 Mar 2008 23:40:12 -0400 ([EMAIL PROTECTED]), MX can refer to a name so for typical usage scenarios I can think of, just updating your A record would automatically update MX settings as well. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC
at the attachment point of an access network to its provider network, also called the ingress point. To: We use the term intra-AS source address validation to mean the IP source address validation at the attachment point of an access network to its provider network, also called the ingress point. The first intra-AS validation point is where the LAN attaches to its first router. 2) sibling etc AS-relations are not defined and the usage is not clear In Section 2.4, there is text wrt Provider, Customer, Peer and Sibling, but not definition of each. Especially Sibling may not be intuitively obvious if you're not familiar with current non-IETF routing table analysis research. The text should also spell out that VRGE needs to know the business relationships of all ASes; in the real world this is an unacceptable solution. Does anyone else than VRGE need to use that AS-relation table mapping? 3) inter-AS automatic rekeying mechanism is not described The signature needs to be changed frequently, Although the overhead of maintaining and exchanging signatures between AS pairs is not O(N^2), but O(N), the traffic and processing overhead increase as the number of ASes increases. Therefore an automatic signature changing method is utilized in this solution. This automatic rekeying method is one of the most interesting pieces of this solution; is there a reason why it is not described in this testbed report? 4) Text about CERNET2 misrepresents the testbed network The prototypes of our solutions for SAVA are implemented and tested on CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation Internet (CNGI) backbones. In the interest of truth in advertising, the document should also mention CERNET. CERNET2 is a testbed backbone that is not very widely utilized; I've been told that CERNET2 is not expected supersede the original CERNET production network. Maybe: rephrase add to the end of the last sentence: that provide testbed facilities to augment existing production backbones (e.g. CERNET). The CNGI-CERNET2 backbones are IPv6-only networks, not a mixed IPv4/IPv6 infrastructure. The CNGI-CERNET2 backbones, CNGI-CERNET2 CPNs, and CNGI-6IX all have globally unique AS numbers. Thus a multi-AS testbed environment is provided. CERNET2 was described at IETF64 in Softwire WG meeting http://www.ietf.org/proceedings/05nov/slides/softwire-3/sld1.htm. It is not an IPv6-only network; in fact, all customer-facing PE-routers are dual-stack. The first sentence above is therefore incorrect and should be removed. Alternatively, one could remove entire Section 3.1; it does not appear to be critical to the readability of the draft. 5) the conclusion appears to be overly generous wrt the results of the draft First, the experiment is a proof that a working system can be built on the basis of the loosely-coupled domains and multiple-fence design for source address validation. Given that none of the new mechanisms tested could be deployed as-is due to the limitations listed in Section 5, it appears a little bit too generous to call this a working system. Maybe instead: First, the experiment is a proof that a prototype can be built that is deployable on loosely-coupled domains of test networks in a very limited scale and multiple-fence design for source address validation. This also seems too genereous: The experiment also provided a proof of concept for the switch-based local subnet validation, network authentication based validation, filter-based Inter-AS validation, and signature-based Inter-AS validation mechanisms. Specifically, all the clients had to be modified (SARC); the switched needed to be modified (SAVP), and a server needed to be deployed (SAMS). While one could say this is a proof of concept, I don't think this is a PoC for a solution that could be considered deployable. Maybe add to the end: However, this solution required changes to clients and switched and addition of a server, and as a result, the concept may not be more widely applicable. 6) future work listing should be beffed up I suggest adding to the Future work list in Section 6 also at least: o Deployability considerations, e.g. modifiability of switches, hosts, etc. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Network Requirements ION Published
On Wed, 5 Mar 2008, IETF Administrative Director wrote: The IAOC has published the IETF Meeting Network Requirements ION at http://www.ietf.org/IESG/content/ions/ The purpose of the document is to assist IETF meeting Hosts and technical teams with the network requirements in support of the week-long IETF meetings. Editors were Karen O'Donoghue, Jim Martin, Chris Elliott, and Joel Jaeggli whose hard won experience with designing and deploying these networks will serve others well. Not sure how relevant this is given the earlier ION statement, but a few things I'd like to clarify in this: - S3 has All locations for network gear, with the exception of wireless APs, MUST be secure. What does secure mean in this context? My observation is that this may the case if secure means physically attached so that no one should, without big hassle, be able to steal the device. If secure means something else, for example, impossible to fiddle with cabling, e.g. add your own laptop as a bridge to the uplink port, capturing all traffic this does not follow existing practice (I observed at IETF71 that there were a number of switches which were stealing-secure but not tampering-secure). - S4 has The network MUST NOT prohibit end-to-end external connectivity for asy traffic (no limiting firewalls or NATs). Does this also disallow (rather typical) filtering of Windows ports (at least 137-139, 445)? -- 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://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Timing over IP Connection and Transfer of Clock (tictoc)
On Wed, 27 Feb 2008, The IESG wrote: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: How much is much? Please define your target or required value for highly accurate time and frequency. Are you talking about pico, nano, micro, or milliseconds? (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. ... My reading of the proposed charter is that this protocol is expected to be usable in network which do not provide on-path support (specialized hardware). As a result, the technology should be good enough without link-specific aids. If it isn't, we shouldn't build the illusion that it is. There is a deliverable on link-layer mappings and many techniques are expected to be link-type specific. Instead of going down the path of media-specific technologies and adaptations -- which the IETF often tries to avoid -- I'd suggest (because the work item list is already very long) that at least in the first phase, the link-specific technologies are defined out of scope. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. I suggest taking link-type specific items out of scope in the initial phase here as well. TICTOC will transfer time and frequency over both IP and IP enabled MPLS PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per packet forwarding behavior. If TICTOC is expected to be usable on pure IP PSNs, in the interest of avoiding premature optimizations and minimizing extra work in the first phase, I strongly advise dropping MPLS-specific considerations at this point and leaving it for later study. On the other hand, if TICTOC doesn't work sufficiently well in pure IP networks, who are we kidding by making it kind-of work in an MPLS network? -- 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://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard
On Wed, 27 Feb 2008, The IESG wrote: The file can be obtained via http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-08.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html I don't see the implementation report there. -- 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://www.ietf.org/mailman/listinfo/ietf
Re: IETF 71 - no room at the inn at all on Thursday
On Thu, 13 Feb 2008, John L wrote: I was wondering why the Doubletree doesn't have the block of rooms available that they promised to the IETF. The reservation agent said she saw the room block, but it didn't have rooms Thursday like it did for the rest of the week. Unless there's a vast number of IETFers only staying Thursday night, which seems rather unlikely, Hilton didn't provide the room block they said they would. I would have thought their long term agreement with the IETF would prevent just this kind of problem. They did have (AFAIR), at least around 5th Feb or thereabouts when I was checking hotel options. In the end I decided to go to Hampton Inn Philadelphia Convention Center which is closer (about 4 blocks or so), a bit cheaper, and AFAIR, seemed to offer better facilities for the price. -- 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 http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin == golf!
On Thu, 31 Jan 2008, Dean Willis wrote: And no, I don't play golf, which appears to be the entire focus of this sort of location. This could be an opportunity to do something different. (Though I agree that having the IETF on a location 15km from downtown could have some challenges.) Ok, hands up (off-list) everyone who's interested in an IETF golf competition or just casual golf :-) ? -- 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 http://www.ietf.org/mailman/listinfo/ietf
Re: IT Transition - IPv6 issues
Hi, I'll create a ticket on this, but nobody will be looking at it at this hour in any case.. On Thu, 31 Jan 2008, IETF Administrative Director wrote: The good news is that all services, except jabber, are now available on both IPv4 and IPv6. This includes the web, ftp, email, and rsync for those who mirror internet-drafts. IPv6 doesn't seem to work from anywhere I can see -- telnet to port 80 doesn't give any response. Sixxs distributed traceroute [1] shows the last working hop being 2001:1890:61:9017::2 (in ATT network). If I'd have to guess, I'd say something close to to the ATT - AMS connection is broken. [1] http://www.sixxs.net/tools/traceroute/ -- 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 http://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Sat, 15 Dec 2007, Mark Andrews wrote: To facilitate this experiment, a URL with instructions on how to get IPv6 running on Windows, Mac OS X, Linux, and so on. Some information will also be available for a 4-to-6 tunnel. ... Step one fix the root. That's going to be a terriby useful exercise when about 99.9% or so other authoritative nameservers out there won't support v6. A better exercise might be setting up a dual-stack DNS resolver which you can use from v6-only network or setting up a v4-in-v6 tunnel to your laptop from a similar dual-stack network. -- 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
Re: IETF Hosting Opportunity - March 2009
On Wed, 28 Nov 2007, Lars Eggert wrote: I might not be fully up-to-date on our sponsoring process, but as I understand it, a meeting sponsor pays for a fraction of the direct costs for a given meeting. Other organizations charge a sponsor a flat amount that is based on costs that are averaged over multiple meetings. Yes, that means that sponsors of meetings in cheaper locations subsidize meetings in more expensive ones, but it also makes it financially irrelevant to the sponsor which exact meeting they support. By the way, is there another mailing list for us to move this discussion to? Does the IAOC have an open list? You can follow IAOC activity from the minutes at http://iaoc.ietf.org/minutes/iaoc_minutes.html Ooops, the latest minutes posted are from March 1st. -- 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
Re: terminology proposal: NAT+PT (or NAT64 ?)
On Thu, 15 Nov 2007, Rémi Després wrote:
Keith Moore a écrit :
IPv4 mapped addresses (those of the form :::{ipv4 address}) should
never appear on the wire. Embedding an IPv4 address within an IPv6
address might make sense in certain cases, but it doesn't work in general.
If using them on the wire is useful, without any identified problem, why not ?
But if you already know of such problem, I am of course interested.
Incompatibility with source address spoofing prevention mechanisms.
P.S: please consider turning off HTML.
--
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
Re: Comments on draft-aboba-sg-experiment-02
On Thu, 11 Oct 2007, Lakshminath Dondeti wrote: Just for the record, if the norm ends up being Idea -- BoF-1 -- BoF-2 -- SG -- WG, I would be very disappointed and would chalk that up under the law of unintended consequences :). I am hoping that Idea -- SG -- WG or Idea -- BoF1 -- SG -- WG in that order become the norm (where SG is involved of course), especially when proponents of new work are people who may not be regulars at the IETF. One of the reasons for having a BoF is that the BoF proponents need to convince the rest of the IETF that the idea is workable and there's sufficient interest to work on the topic. If there is expectation that no BoF is held between the SG and WG phase, how can we guarantee that the IETF as a whole thinks the charter and the other deliverables the SG worked on are convincing and worth doing? As for the timeslot scheduling, I'd say SGs should have a precedence over IRTF research groups, given that we're talking about IETF meetings, not IRTF meetings. -- 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
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Tue, 2 Oct 2007, ken carlberg wrote: On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. could you expand on this observation? I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. -- 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
Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Mon, 1 Oct 2007, The IESG wrote: The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Aggregation of DiffServ Service Classes ' draft-ietf-tsvwg-diffserv-class-aggr-04.txt as an Informational RFC DiffServ Pool 1 codepoints require Standards Action [1]. While this document doesn't define new ones (because there aren't any), it defines how one should configure the treatment for each and every Pool 1 codepoint in the network. Therefore in spirit it specifies DSCP codepoint behaviour and how those should be used. As such I believe this document is inappropriate as an Informational RFC. It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. If this work were to proceed, I suggest that first RFC 4594, which this document builds on, would attain IETF consensus by following the standards process for publication as a BCP. [1] http://www.iana.org/assignments/dscp-registry -- 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
what's up with the management
Just an observation: It's nice to note that the management appears to be busy with real work. The last IAB minutes are from April 10, IAOC from March 1. http://www.iab.org/documents/iabmins/index.html http://iaoc.ietf.org/minutes/iaoc_minutes.html#2007 OK, back to the regularly scheduled rants about DHCP, NAT, and IPv4 address consumption. -- 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
Re: Last Call: draft-ietf-hip-applications (Using the Host Identity Protocol with Legacy Applications) to Experimental RFC
On Mon, 14 May 2007, The IESG wrote: The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Using the Host Identity Protocol with Legacy Applications ' draft-ietf-hip-applications-01.txt as an Experimental RFC 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-05-28. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Some slightly late comments below. My main (meta-) issue with the draft is that it's not clear from how the draft is written what is the goal of the draft. It seems it's providing an informative overview of different approaches for HIP experiments; it does not aim to provide any normative specification for HIP implementations or applications, even to make the experiments using different approaches to use more uniform methods. Is this correct? If yes, maybe this could be made more explicit, e.g., by adding 'Overview on' at the start of the title and similar other modifications. On the other hand, if this spec is intended to be used somehow by HIP or application implementations, I believe text would likely need significant rework; there is very little explicit guidance or explicit specification as it is and very little text that would help in creating interoperable implementations. substantial --- While the text below concentrates on the use of the sockets connect system call, the same argument is also valid for other system calls using socket addresses. == I'm not sure if I will accept this assumption at its face value without a reference. Are you sure all the socket-operating system calls are basically equivalent? Has this been studied somewhere (Miika/Mika's Master's thesis as one example?) more extensively? For example, what does listen(LSI) or bind(LSI) mean? Section 3.4 seems to discuss this a bit implying that all the socket system calls aren't necessarily similar. Using DNS to map IP addresses to HIs: If the responder has host identifiers registered in the forward DNS zone and has a PTR record in the reverse zone, the initiating system could perform a reverse+forward lookup to learn the HIT associated with the address. [...] == does this cause a recursion problem with DNS resolver IP addresses? I.e., you try to look up HIP records by reverse+forward of node X by doing queries to DNS servers A and B, but end up querying DNS reverse+forward records of A and B through DNS first. I think this should work under normal circumstances but I can see some potential reliability issues; at least if the DNS server addresses are provisioned with HIP records but they don't support HIP, you might end up hosing all your DNS lookups if the fallback from trying HIP to no-HIP isn't reliable. Is there already sufficient experience of these kind of potential bootstrap problems? Is a warning that such a bootstrap mechanism may want to avoid looking up DNS server addresses warranted? DNS with security extensions (DNSSEC) [6], if trusted, may be able to provide some additional initial authentication, but at a cost of initial resolution latency. == maybe remove 'additional' as it appears opportunistic HIP has no initial authentication at all as described in the previous sentence. It might also be useful to quantify 'some' as I belive it's not clearly discussed anywhere though more generic and longer text can probably be found in DNSSEC documents; security considerations only mentions that 'if DNSSEC zones are considered trustworthy enough'. Basically as you describe using DNSSEC with reverse DNS, the delegation chain from the reverse IP root should be trusted (typical trust anchor issues) but this is not typically an issue; and that the DNS zone administrators in charge of the netblock should be trusted to put in the right information. editorial - upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is == spell out 'API' (done in Introduction but not here apparently) Fully deployed, the HIP architecture will permit applications to explicitly request the == feeling optimistic? :-) Maybe 'would' would be slightly more neutral (Section 1.1.6 of [2]) in that the ESP association formed by HIP is == spell out ESP. [3] Nikander, P., An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID), draft-laganier-ipv6-khi-07 (work in progress), February 2007. == RFC now. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
On Tue, 29 May 2007, Mark Allman wrote: Or do you mean that the proposers should do everything guidelines (2), (5), (6) and (7) say, but shortcomings in the results of these guidelines (e.g., proposal being only slightly more troublesome than TCP) should not block the approval for widespread deployment in the global Internet. Yes. And, in re-reading the text I think it is clear. I really can't untangle your comments in this area. If you have specific suggestions for the text, please send them along. -03 has: For other guidelines, i.e., (2), (5), (6), and (7), evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. if the above is what you mean (and a proposer must really go through everything you list, e.g., all the difficult environments as well), it should be explicit, e.g.: For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. My problem with existing text is that the referred guidelines use wording should do Is it a must do or may do or something in between? It should be more explicit. Text proposal above interprets the shoulds as musts. 4) The first evaluation criteria also includes We also note that this guideline does not constrain the fairness offered for non-best-effort traffic. I don't understand your point here. All we are saying is that if---by some means---we know that some flow is not best effort then it can be subjected to some other criteria then it need not be constrained by the guideline. What I try to say is that I can't figure out how operationally and practically this could be achieved. Do you have examples in mind how how this could apply in some specific scenario? If not -- and it isn't a practical concern right now -- maybe we should not overengineer the BCP to address best-effort vs non-best-effort at all. We didn't overengineer anything. We just said that the guideline doesn't apply to non-BE cases. I can't understand your point here at all. It is a simple statement of document scope. Let's say I propose an informational RFC on congestion control and say that it only applies to non-BE traffic. I don't have to make any of the evaluations or analysis required by this draft. What's the procedure for non-BE congestion control agorithms? I note that Lars's ION does not mention that case. In case there is no process to define non-BE congestion control mechanisms at all (and the response would be sorry, we don't support that), I have no problem. In case there is some process with a lower bar, I'd have a problem, because it would be possible to avoid the loops you have jump through defined in this document by saying the CC algorithm applies to non-BE traffic only, but in practice it would be end up deployed for BE traffic as well. -- 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
Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
On Tue, 29 May 2007, Pekka Nikander wrote: I don't have answers to all of your questions/remarks, but I'd take forward a few: 1) what if HIP RRs are not queried first? In the following we assume that the initiator first queries for HIP resource records at the responder FQDN. == what if it does not? Remember that this is an experimental spec. So, taking it the reverse, why should id specify what to do if someone has a reason to do it in another way? I don't see any specific reason to make any MUSTs or even SHOULDs here: I don't see here any danger for the Internet nor interoperability. But maybe I just don't understand the dangers you have in your mind. I have personally no big problems if the spec were to say that HIP-after-A-or- were to be left out of scope of this document. However, what I'm a bit uncomfortable with is that this assumption is apparently made in Section 3, Usage Scenarios, which seems to be a section with no normative content. As such I believe such a statement/assumption (if made) should be made in a more prominent place in the spec. 3) a premature optimization of HIT lookup tags Upon return of a HIP RR, a host MUST always calculate the HI- derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP base specification [I-D.ietf-hip-base], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g. table lookup). .. and in section 8.2: [...] This is why a HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but SHOULD rather use HI- based authentication. == this seems like a premature optimization. Note that these RRs may need to be indexed also by other boxes but the end-nodes. For them, using the HIT as an index and doing a simple memory comparison instead of calculating a hash may be a win. Further note that both the sections you quote above discuss only host/end-note behaviour. This is makes me even more afraid. If most end-nodes use mechanism A but others are expected to maybe use another mechanism B, I foresee problems with both mechanisms especially in middleboxes. It certainly won't improve the reliability of the protocol.. If you go forward as it is, I think the spec needs to be more explicit on 1) what happens when HIT received from the DNS does not match the hash but the hash is checked; I agree. FWIW, either ignore the HIT or drop the record. I think the latter would be the right option, but I may be wrong. 2) what are the threats if HIT is used as-is without hash-checking (as allowed by the spec at the moment) when a) the DNS-HIT points to something used by another HI, and b) the DNS-HIT doesn't exist. I don't understand what you are saying here. Maybe I was trying to be too terse or I'm missing an assumption about how HIT vs HI is validated in other parts of HIP infrastructure. Let's say I publish a HIPRR with HIT=hash(Y) and HI=X. Someone else has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create an intentional conflict. Given that the spec does not mandate that the implementations check that HIT will correspond to the HI, what's going to happen in this case? Will a middlebox overwrite the index at hash(Y) with HI=X? If yes, what is the result? Will it be a DoS on the host that used HI=Y? That was the scenario 2.a) above and 2.b) is when HITs don't conflict (a more trivial case) -- 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
Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
the Rendezvous Servers field. == I may me misunderstanding this, but doesn't that imply that the authoritative DNS servers must implement Base16 and Base64 decoding support so that they can convert from BaseXX to the on-the-wire format? Is this a new requirement on DNS nameserver implementations, or are DNS servers already required to do it? Is this a typical way to represent and distribute binary data on DNS? Does this require the authoratative DNS server to know how to parse the zone representation format, i.e., support for HIP RRs? My question here would be, how would DNS authoritative servers support HIP RRs under RFC3597 (Handling of Unknown DNS Resource Record (RR) Types)? editorial - o A set of IP address(es) through A [RFC1035] and [RFC3596] RR sets (RRSets [RFC2181]). == you'll probably want to rephrase this as: o A set of IP address(es) through A [RFC1035] and [RFC3596] resource record sets (RRSets [RFC2181]). .. or remove (RRsets ..) and just keep the 2181 reference. The RDATA for a HIP RR consists of a public key algorithm type, the HIT length, a HIT, a public key, and optionally one or more rendezvous server(s). == s/algorithm type/algorithm type and length/ The complete representation of the HPIHI record is: == s/HPIHI/HIPHI/ (?) -- the same elsewhere The HIP RR contains public keying material in the form of the named peer's public key (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. == s/Both of these are not/Neither of these are/ ? Hannu Flinck, Olafur Gu[eth]mundsson, Tom Henderson, Peter Koch, Olaf == Olafur's surname might need ascii-fication.. Julien Laganier is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. == is such a long boilerplate really necessary? I'd hate to start seeing these on each I-D, for each author for different sponsors, etc. A shorter, 3 lines maximum, acknowledgement should be sufficient. -- 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
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
be evaluated when competing with standard IETF congestion control [RFC2581,RFC2960,RFC4340]. OK. 4) The first evaluation criteria also includes We also note that this guideline does not constrain the fairness offered for non-best-effort traffic. I don't understand your point here. All we are saying is that if---by some means---we know that some flow is not best effort then it can be subjected to some other criteria then it need not be constrained by the guideline. What I try to say is that I can't figure out how operationally and practically this could be achieved. Do you have examples in mind how how this could apply in some specific scenario? If not -- and it isn't a practical concern right now -- maybe we should not overengineer the BCP to address best-effort vs non-best-effort at all. If yes, there are some approaches to this, I'd be interested in hearing how they'd work, but more even more than that, I'd require the proposers of such a mechanism to provide an evaluation how reliable that knowledge of best vs non-best-effort is. What I'm afraid of is that the specification would say that it's applied for traffic with certain DSCP values but typically that alone is not IMHO a very reliable indicator of BE vs non-BE because DSCPs can be rewritten and used for other purposes than those envisaged by the proposer of the mechanism. 5) Normative references is empty, yet this is a BCP document which, among other things, referred to standard congestion control without providing a reference (as raised above). Please move some informational references over here and/or add applicable references. I have now put the references to RFCs 2581, 2914, 2960 and 4340 under normative references. (And, splitting the references was the dumbest thing we ever did---it causes no end to the haggling.) (Well.. Some will argue that the current IESG's policy requires such a split. Some have interpreted that in certain classes of Informational documents, a split may not be necessary, but I believe Standards Track and BCPs do need it.) 2. Status == this title seems too short, and a somewhat longer and a more descriptive one would be useful. Actually the section seems to be a mix and match of different topics and a better organization might help the document considerably. E.g., if there was a numbered list or subsection of different publication paths and descriptions of each the scope of the document and the intent of this section would likely be much clearer. I changed the title to Document Status, but I am not inclined to re-arrange it further because lots of people have read this now and nobody has complained. The major caveat here is that *I* hacked out the changes described above. Sally may want to wordsmith or just plain disagree. OK. I'd have liked to change it more but I realize it's a bit late in the process and the other clarifications made above should help already. -- 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
Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
referred to? RFC 793 plus RFC 1122? These are the only two IETF _Standard_ specifications I can think of. Or does this include proposed standards as well? What constitutes IETF congestion control or standard congestion control (in another place) that a CC algorithm should be evaluated against? Please do not cite the TCP roadmap RFC on this. It's Informational and not an IETF consensus statement, and as such has no authority to define what constitutes standard congestion control. 4) The first evaluation criteria also includes We also note that this guideline does not constrain the fairness offered for non-best-effort traffic. How does a TCP congestion control algorithm know whether a particular TCP session is best-effort or non-best-effort? You likely have an assumption here that may need to be spelled out. However, it is not clear why this distinction is even relevant. The users may not be able to control whether their traffic is labeled best-effort or not (to a higher or lower class), and as a result if the user wants to test a congestion control mechanism, its classification may change without the TCP implementation knowing it, and as such causing havoc in the network. Further, in many implementations, I believe it is not possible to choose which TCP sessions should use a specific congestion control mechanism (I think on recent Linux there is a setsockopt option for this though). As such even if in theory or in RFC a CC algorithm is only meant to be used for non-BE traffic, in practise it may end up being used for all traffic on a host due to implementation limitations. 5) Normative references is empty, yet this is a BCP document which, among other things, referred to standard congestion control without providing a reference (as raised above). Please move some informational references over here and/or add applicable references. editorial - networks). Recent research has yielded many alternate congestion control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP], [XCP], and many more). Using these new congestion control == please remove the references from the abstract per ID-nits. 2. Status == this title seems too short, and a somewhat longer and a more descriptive one would be useful. Actually the section seems to be a mix and match of different topics and a better organization might help the document considerably. E.g., if there was a numbered list or subsection of different publication paths and descriptions of each the scope of the document and the intent of this section would likely be much clearer. -- 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
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, 11 Apr 2007, Theodore Tso wrote: ... Unlike some OSS advocates, I don't feel a particular need to to require a patent license which is valid for any field of endeavor; just the essential claims necessary to implement an IETF standard is IMHO sufficient (realistically I doubt many IPR holders would be willing grant more than that). [...] FWIW, many declarations (taking the one shown by Joel as an example), permission is granted to technically necessary to implement the IETF standard spesification.. and similar has been seen in other declarations (possibly in the form, '.. to interoperate with XXX standard specification'). Does that allow you to implement everything in the specification if 'everything' is not 'technically necessary to implement' [for interoperability or otherwise]? MAYs? SHOULDs? -- 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 [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [rbridge] Last Call: draft-ietf-trill-routing-reqs (TRILL RoutingRequirements in Support of RBridges) to Informational RFC
On Wed, 21 Mar 2007, Harald Tveit Alvestrand wrote: --On 20. mars 2007 09:35 -0700 Silvano Gai [EMAIL PROTECTED] wrote: 5) Introduction - Bridging limitation. The first paragraph refers to Ethernet networks used without Spanning Tree. This is irrelevant, since Spanning Tree is always deployed in conjunction with Ethernet. The correct contrast must be between Ethernet with Spanning Tree and Ethernet with TRILL. The claim of a single broadcast/flooding domain is incorrect since VLANs have solved this issue many years ago. always is too strong, since most unmanaged bridges (intended for consumers' home networks, but often dangled off the edge of corporate networks as port expanders, without asking for permission) don't seem to be supporting Spanning Tree. However, these are not going to support TRILL either, so for the environments considered here, always is probably true. FWIW, not sure if it matters, but our offices have a relatively small Ethernet network (50+ switches) and we have specifically disabled STP. You can't run STP on host ports, and it's too much of a hassle to enable it on inter-switch ports, so it's easier to disable it everywhere. -- 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
Re: Seeking a new IAB Executive Director
On Mon, 19 Mar 2007, JORDI PALET MARTINEZ wrote: I've a small comment regarding the profile. I'm not thinking in any specific candidate, but I think this is very relevant for a fair selection. The first point, keeping and editing the minutes, almost excludes the non-native English speakers, at least, they will have a much more difficult job if a non-native candidate is appointed for this. ... Jordi, what you may be missing that IETF is (for a lack of a better word) a meritocracy, not a democracy. That includes finding the most suitable person for the job, so citing issues of unfairness (to those that may not fulfill requirements) misses the point. If taking care of the minutes requires some degree of English skills, that's what should be required. -- 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
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC (fwd)
Posted for Dean.
-- Forwarded message --
Date: Sat, 17 Mar 2007 23:50:33 -0400 (EDT)
From: Dean Anderson [EMAIL PROTECTED]
To: Pekka Savola [EMAIL PROTECTED], John C Klensin [EMAIL PROTECTED],
Simon Josefsson [EMAIL PROTECTED],
Brian E Carpenter [EMAIL PROTECTED],
Stephane Bortzmeyer [EMAIL PROTECTED],
Hallam-Baker, Phillip [EMAIL PROTECTED],
Ted Hardie [EMAIL PROTECTED], Tom Yu [EMAIL PROTECTED],
Andy Bierman [EMAIL PROTECTED], Ned Freed [EMAIL PROTECTED],
David Kessens [EMAIL PROTECTED]
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to
Experimental RFC
I would appreciate it is someone would repost this to the IETF list.
First, I want to say that I support an ASN.1 compiler in C++ and am
considering a rewrite of that compiler's translated runtime to ADA to
leverage some of ADA's advantages. While some people think ASN.1 is
obsolete, it is still a very efficient way to describe protocols and
generate their codecs. ASN.1 has attractive security properties, once
the security flaws are removed from the ASN.1 translator, of course.
However, that effort, once performed in the translator, subsequently
benefits and protects all users with no code changes. ASN.1 is
complicated, but robust and usually worth the effort.
XML, by contrast, is quick and dirty and inefficient; the protocol/codec
equivalent of a scripting language. The world needs both scripting
languages and compiled languages, and likewise I see a need for both XML
and ASN.1.
So, I have some mixed feelings about this document. The motivation for
this work is entirely unclear to me. Why is the X.693 XML Encoding Rules
(XER) Specification insufficient for encoding ASN.1 in XML? If XER is
truly deficient, perhaps it should be amended, and so this issue belongs
with the ITU, not the IETF. But I am unable to divine the deficiency in
XER from reading this document.
But also, if X.693 is insufficient, the next question is why is X.692
Encoding Control Notation insufficient? (well, I suppose its too new)
I suggest that one investigate XER and also X.692 Encoding Control
Notation, rather than specify a new and incompatible alternative.
In reading the document, I think a little too much is made of the issue
of ambiguity in ASN.1 specifications; they are only ambiguous if you
want to translate in a single pass with a LALR(1) parser generator.
But, I looked at Section 6 of the draft for some insight, and found this
claim:
Note that the notation of ASN.1 is ambiguous where a Type is both
prefixed [X.680-1] (e.g., tagged) and constrained. For example, the
notation [0] INTEGER (0..10) could be interpreted as either a
tagged ConstrainedType or a constrained TaggedType. For the purposes
of the translation into ASN.X, the constraint is assumed to have
higher precedence than the prefix, so the above notation would be
taken to be a tagged ConstrainedType.
Looking at my copies of X.680 and X.680 Amendment 1, I find no reason to
see that there is any ambiguity in the quoted example. Also, X.680
Amendment 1 seems to have no relevance to the paragraph, so I'm
wondering if the reference is a mistake.
In fact, X.680 Amendment 2, Section F.6 gives numerous examples of
tagged constrained types of similar form as the example above.
A closer look reveals no ambiguity:
The productions in question are defined in X.680 Section 16.2 and 30.1,
I have abbreviated them:
Type ::= BuiltinType | ReferencedType | ContrainedType
BuiltinType ::= ... |
TaggedType
TaggedType ::= Tag Type
Tag ::= [ Class ClassNumber ]
where Class can be empty, as it is in the quoted example.
Definition 3.8.64 gives a definition for the meaning of tagged types:
A type defined by referencing a single existing type and a tag; the new
type is isomorphic to the existing type but distinct from it.
However, there is no ambiguity since tag and constraint are attributes
of a type, and it doesn't matter which comes first. ASN.1 compilers
which I am familiar with perform this as follows (Bison/c++)
TaggedType
: Tag Type
{
$2-SetTag($1.tagClass, $1.tagNumber,
Module-GetDefaultTagMode());
$$ = $2;
}
ConstrainedType
: Type Constraint
{
$1-AddConstraint($2);
}
| TypeWithConstraint
;
Bison translates this without conflicts. A longest string of terminals
always results in a ConstrainedType being reduced before a TaggedType is
reduced to Type. Bison and yacc resolve shift/reduce conflicts as
shift unless otherwise directed by operator precedence rules.
Suppose the parser stack contains:
Tag ([0])
Type (INTEGER)
The next symbol is (
A shift (the default) implies that ConstrainedType will always be
reduced before TaggedType.
However, reducing at this point produces exactly the same result, so I
fail to see how this construct is ambiguous. There must be different
meanings in order to be ambiguous
Already Last-Called downrefs (was: ...)
On Wed, 14 Mar 2007, Brian E Carpenter wrote: Just to confirm: 2818 has already been downrefed so it can be used in this way without further formality. http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry There appear to have been two kinds of Last Calls: 1) Last Call for document X which also last calls that document's downrefs, and 2) Separate Last Call about downrefs to document Y (rare, see 31 Jan 2007 example below) Which one(s) are you referring to? If 1), there seems to be an assumption that if document X downrefs document Y, and that downref is last-called, there is no need to Last Call any downref to document Y. There is no text in the Last Call message to suggests the downref should be considered in a 'global' sense (more like 2) above), instead of in the context of the referencing document. I certainly wouldn't go as far as to say that if it's OK for draft-dusseault-caldav to use RFC2818 in a normative sense, it would automatically make it OK in every other protocol as well. RFC 3967 says: = Once a specific down reference to a particular document has been accepted by the community (e.g., has been mentioned in several Last Calls), an Area Director may waive subsequent notices in the Last Call of down references to it. This should only occur when the same document (and version) are being referenced and when the AD believes that the document's use is an accepted part of the community's understanding of the relevant technical area. For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well known among cryptographers. = And I'm not sure if those requirements have been fulfilled yet. Am I missing something? FWIW, there appear to be errors in the DownrefRegistry above. For example, draft-ietf-lemonade-compress has not been Last Called this year, and when -06 version was in Dec 2006, it had no mention of downref. There is a 'global'-like Last Call on 31 Jan 2007 but it seems to be about RFC 1951, not 1531.) -- 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
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
On Mon, 12 Mar 2007, The IESG wrote: A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt ... Working Group Summary This document set was not produced by an IETF working group, but by an individual. IETF Last Call produced no comments, and solicited reviewers were basically positive. This writeup was not updated or comments were not duly processed. I see 14 Last Call comments (retaining the subject line) on [EMAIL PROTECTED], as well as 12 comments under the 'Protest: Complexity running rampant' thread. -- 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
Re: [Fwd: Fwd: Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview, Assumptions, Problem Statement and Goals) to Informational RFC]
Hi, On Tue, 6 Mar 2007, Geoff Mulligan wrote: You question about switches does point to an overloaded term. In that particular paragraph the switches we are talking about are electrical switches, as in light switches, not network switches. We'll fix the wording. I guessed as much, which is what triggered me to wonder about the use of the term 'personal' as I don't think an electrical switch is typically carried in your PAN :-) The reason we use the term personal area network is that it is the industry term used for 802.15.4 networks. I agree that these devices are not personal, but it is a nomenclature that we are stuck with by the IEEE. If you don't want to drop 'Personal' from the used terminology, I would suggest considering adding a sentence or two in Introduction of all relevant documents to make it clearer that the IETF has designed a generic solution which also applies outside of PANs. The IETF specifications as far as I can see are not restricted to 'P' in 'PAN'. (If you consider assumptions and possible security tradeoffs this may have good and bad consequences.) We did not address the security of underlying mesh network because we have not yet defined that layer yet. We are working with MANET to define that and the security for the mesh would be addressed in that document. It was not germane to the format/adaptation header. To you question about network management - again this document is about the format and header encoding only. Network management and security will need to be addressed by a future 6lowpan management or 6lowpan ops document. I'm not sure whether I agree. We're talking about a problem statement draft. I'd agree that network management is probably outside the scope of draft-ietf-6lowpan-format. It seemed that the network management goals could not be fulfilled without compromising other goals (easy or zero configuration), raising a doubt about the feasibility of the goals. Even if NM doesn't need to be addressed in 6lowpan-format, I think (operational) security should be. The key questions (IMHO) here are, 'Are the security mechanisms specified by IEEE and IETF good enough that using them is feasible in real life? Will they get used?' So far, the document doesn't give me an assurance that the answer to either is 'yes', and hence it leaves me little to use when trying to figure out whether the security model of 6lowpan design is adequate, and consequently, whether the IP specification is complete or not. -- 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
Re: Last Call: draft-ietf-isis-caps (IS-IS Extensions for Advertising Router Information) to Proposed Standard
On Mon, 26 Feb 2007, The IESG wrote: The IESG has received a request from the IS-IS for IP Internets WG (isis) to consider the following document: - 'IS-IS Extensions for Advertising Router Information ' draft-ietf-isis-caps-07.txt as a Proposed Standard This document has a normative reference to two informational RFCs, 3567 and 3784. These are part of a group of informational RFCs that were published as informational instead of standards-track for historical reasons, and there is current work in progress to advance them to standards track. ... This comment applies to all the three IS-IS documents currently in Last Call. As far as I can see, there is no significant work in progress (as visible to an outsider) to move the underlying Informational RFCs forward at all: no drafts. I can see that there was some discussion on the list in January but that's it. Given the usual pace IS-IS WG takes in moving documents from draft to RFC (5 years +/- 3 years) this move would take years. AFAICS, there is no harm in the 3 drafts being drafts until their dependencies are sorted out. On the other hand, not publishing them as RFCs may motivate the WG to actually work on the standarzation of IS-IS base specifications at a reasonable pace. There is also a possibility that a specification would need to be changed when standardized so that it might affect one of these 3 specifications. As such I do not support approving these documents at this time. -- 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
Re: Last Call: draft-ietf-6lowpan-problem (6LoWPAN: Overview, Assumptions, Problem Statement and Goals) to Informational RFC
On Thu, 15 Feb 2007, The IESG wrote: The IESG has received a request from the IPv6 over Low power WPAN WG (6lowpan) to consider the following document: - '6LoWPAN: Overview, Assumptions, Problem Statement and Goals ' draft-ietf-6lowpan-problem-07.txt as an Informational RFC 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-01. 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-ietf-6lowpan-problem-07.txt Sorry for slightly missing the LC deadline. 6. Low cost. These devices are typically associated with sensors, switches, etc. This drives some of the other characteristics such as low processing, low memory, etc. Numerical values for low elided on purpose since costs tend to change over time. == what kind of 'switch' do you have in mind? How does that participate in a _personal_ area network? As a side note, there appears to be nothing in the requirements that relates directly to the 'personal' of personal area network. For example, there are no assumptions about the maximum diameter of the network. Are you really specifying Low-power Wireless Area Networks rather than LoWPANs? Are there any goals, problems or assumptions relating to 'personal' that one should be aware of? Or should you just remove 'personal' from the text(s)? 4.2. Topologies == I was a bit disappointed as I saw no mention of securiry wrt routing in the mesh topology. It isn't mentioned in the later part of the text as well. E.g., how do you prevent malicious nodes from joining the network and doing e.g., MiTM attacks by posing as routers? Are you assuming that the link-layer security will keep unauthorized nodes away from the LoWPAN network? If that is the assumption, more emphasis might be needed on how to actually configure the link-layer keying. Based on current text it's not clear if configuring keying in all the nodes is operationally feasible or even possible. 4.3. Limited Packet Size Applications within LoWPANs are expected to originate small packets. Adding all layers for IP connectivity should still allow transmission in one frame without incurring excessive fragmentation and reassembly. Furthermore, protocols must be designed or chosen so that the individual control/protocol packets fit within a single 802.15.4 frame. Along these lines, IPv6's requirement of sub-IP reassembly (see Section 5) may pose challenges for low-end LoWPAN devices that do not have enough RAM or storage for a 1280-octet packet. == I wonder what the last sentence implies. Given that the -format specification still requires the 1280 byte IP MTU, the RAM requirement was probably not blocking here. Rewording this slightly due to how -format ended up being might be useful. 4.4. Limited configuration and management As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work out of the box, be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. Network management should have little overhead yet be powerful enough to control dense deployment of devices. == no or very little configuration, yet network management should be powerful enough to control a huge number of devices? How do you manage the authorization of network management then, i.e., who is allowed to control the devices? I'm somewhat surprised that you do not mention overcoming (initial) configuration tasks (including but not limited to network management) as an item under Section 5. For network layer security, two models are applicable: end-to-end security, e.g. using IPsec transport mode, or security that is limited to the wireless portion of the network, e.g. using a security gateway and IPsec tunnel mode. == it might be useful to mention how header compression relates to IPsec. Are there problems if both are applied? If non-NULL IPsec transform is used, can header compression be used at all? -- 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
Re: Last Call: draft-ietf-6lowpan-format (Transmission of IPv6 Packets over IEEE 802.15.4 Networks) to Proposed Standard
follows | +--+---+ == off-by-two at the bottom of the table.. datagram_size: This 11 bit field encodes the size of the entire IP payload datagram. == .. 'in octets' ? You don't specify the unit.. Next Header (bits 5 and 6): 00: not compressed, full 8 bits are sent 01: UDP 10: ICMP 11: TCP == s/ICMP/ICMPv6/ -- you probably refer to protocol=58 instead of protocol=1 ? (the same later in the section) 15.2. Informative References [I-D.ietf-ipngwg-icmp-v3] [I-D.ietf-ipv6-node-requirements] == these have been published in RFCs (but neither is actually used in the body of the text, so could be fixed and added or removed completely). -- 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
RE: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn)
On Mon, 19 Feb 2007, [EMAIL PROTECTED] wrote: [logical components being:] encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. I'd like to see it explicitly stated that transporting congestion information in the (metered) IP packets themselves is out of scope. Forward transport of the basic congestion information has to be in scope as Fred has pointed out. Backwards transport needs to be scoped by application scenario - for example, backwards transport via SIP is clearly out of scope for the initial PCN work. OTOH, not specifying how to actually move any of this information around would turn PCN into the moral equivalent an IRTF Research Group, which (IMHO) would be bad - at the end of the day, PCN needs to produce something that actually works (need running code in addition to rough consensus). It seems that are assuming the transport needs to happen in the packet itself. While this is a possible approach, I don't see that it needs to be the only one. For example, a mechanism where the mutually trusting network components would have another channel to convey this information (e.g., using SNMP, IPFIX, or the like) might also apply. However, to be clear, I have no objection to using the ECN field(s) if that does not hinder the current use (or lack thereof) of ECN. What I specifically don't want is to define new fields for PCN, especially extension headers or IP options. I should have been clearer with my objection. -- 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
Re: WG Review: Media Server Control (mediactrl)
On Tue, 13 Feb 2007, IESG Secretary wrote: Given the wide acceptance of the media server, we need a standard way to control them. This, and taking a look at draft-boulton-sip-control-framework-05.txt which seems to be relevant here, seems to imply this group is about to build a management framework for SIP services. I'm not sure if such a framework has been chartered yet in other WGs, and if not, this would be the first time, bearing closer scrutiny how to do it correctly. How much the manamgement part of OM has been consulted? What is the model of co-operation with the IETF management expertise? MILESTONES APR 2007 Requirements Document JUN 2007 Framework Document NOV 2007 Conference Control Protocol MAR 2008 IVR Control Protocol JUN 2008 Broker Protocol or BCP These are horribly vague. Are the dates for WG adoption? WGLC? Shipping off to the IESG? -- 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
Re: WG Review: Congestion and Pre-Congestion Notification (pcn)
On Tue, 13 Feb 2007, IESG Secretary wrote: [logical components being:] encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. I'd like to see it explicitly stated that transporting congestion information in the (metered) IP packets themselves is out of scope. This should exclude designs such as adding IP options en-route, defining new extension headers, or modifying the packets in any, currently undefined way. (I say this explicitly because based on a very quick look at the mailing list archives I saw discussion relating to IP header encoding and it unnerved me.) Reaction mechanisms at the boundary consist of flow admission and flow termination. In order to do flow admission, you'll first need to recognize a flow. How do you recognize at the borders (or in the core) which kind of flows should be considered to be treated as PCN? The mechanisms for accomplishing this in an operationally feasible way don't seem to be discussed in the charter. This may be easy if all the traffic you're interested of is using a few predetermined (and configured) protocols and port numbers, but I suspect that is not the case, and layer 7 packet inspection is not an option either.. -- 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
Re: Does our passport need to be valid for 6 months to go to Prague?
On Sun, 18 Feb 2007, Michael StJohns wrote: At 06:29 PM 2/18/2007, Janet P Gunn wrote: My guidebook says 6 months. Feel free to argue with the US State Dept.. :-) I don't think it's the US State Dept you will need to argue with but rather the officials in Prague Airport.. -- 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
Re: draft-ietf-syslog-protocol: Reliable delivery considered harmful.
On Thu, 1 Feb 2007, David W. Hankins wrote: If you insist on keeping all 50,000 lines of output, there is no solution to that problem. If you block, that's a big problem as it ultimatley totally disables the service attempting to log information. If you write to a growing backing store, well you'll run out of space eventually (even disk is not infinite). Compression can only get you so far. As an operator, I would find a reliable syslog useful. However, I do not see this as a problem. 95% of the problem (from our perspective) is solved if no messages are lost _on the wire_ between the sender and the recipient of syslog messages. It's acceptable for the syslog sender to replace overflowing lines of syslog (if some messages need to be dropped due to lack of resources) with a message about rate-limiting, messages being dropped, or whatever -- just the same way as messages might get dropped when syslogging to a local media. As long as a) there is a message about syslogs getting dropped, and b) this is infrequent in a well operated system (i.e. the system log levels are set so that typically the amount of logging is OK), this should be no problem. May be adequate to the point of suggesting that reliable delivery might not be desirable. But on the whole the draft doesn't read that way, and it doesn't state the truth: reliable delivery of syslog output is always harmful. The point of bothering with reliable syslog delivery, if there is one, is for those very rare cases where losing the data is more harmful than harming system services. IMHO, reliable delivery of syslog output is always harmful is very much an over-statement. It seems your concern is limited to the corner case where the syslog sender would already have a full syslog buffer, and the sender would get even more syslog to send. While this is a serious problem when it occurs, it should be easily solvable: just drop the messages (with a suitable note in syslog or in the local log) that exceed the buffer size or prune messages from the buffer using some more advanced strategy. As a particular example, we'd be very interested in getting reliable syslog from our routers to cover for messages lost due to network outages (fixed usually quickly with rerouting). We are talking of 1-200 messages being lost within a 10 minute period -- a very reasonable packet rate in average. A 1,000 or 10,000 line buffer in the router should be very reasonable in recent control processors. I'd rather the control processor reserve 0.1% of its memory (or CPU) to store and transmit these messages rather than try to use the last 0.1% when it's already chugging at 99.9%; the last 0.1% would not make a meaningful difference anyway for whatever it's using almost all of its resources. -- 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
addressing Last Call comments [Re: Discuss criteria]
Jeff, you wrote a good note. I'll use this as an opportunity to expand on one topic a bit: On Thu, 11 Jan 2007, Jeffrey Hutzelman wrote: On Wednesday, January 03, 2007 10:49:33 PM + Dave Crocker [EMAIL PROTECTED] wrote: C. PROCEDURAL BREAKAGE --- * IETF process related to document advancement was not carried out; e.g., there are unresolved and substantive Last Call comments which the document does not address... IMHO, this particular situation is more than just procedural breakage. If a document reaches this point with outstanding last call comments, then there is a more basic failure. Such a document should not have reached the point where a DISCUSS is required to keep it from progressing long enough for the comment to be addressed. Well, it seems rather common that IETF LC comments (especially if not copied to ietf@ietf.org list) are not responded. To reduce delay, it also seems common that IESG telechat is scheduled as soon as possible after IETF LC closes, and document is usually not taken out of the agenda if comments are received during the LC. Also sometimes the document gets approved without there being any record (e.g., on IESG ballots) that some comments had been made but there was no response. Therefore it is not clear to me whether such comment was addressed (I'd call this 'processed') but without public record [e.g., editor or chair] in essence rejecting the comment (possibly in good faith) or not received at all (maybe also in good faith, e.g. if WG mailing list discards non-subscriber posts or the moderator is asleep). Maybe we should be clearer on what the expectation for processing IETF LC comments is. Unless we do, it is not obvious how we could evaluate whether the procedure has been carried out properly or not. -- 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
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
On Fri, 1 Dec 2006, Brian E Carpenter wrote: 2. There's clearly a need, if the work is to be expanded into new applications areas, for the experts in those applications to be deeply involved. That is in fact the main argument why the work should be done in the IETF if it's done at all. I understand that this would need a major injection of new blood into the WG. That won't happen by means of a simple re-charter. It needs an impetus that would be noticed throughout the IETF. An alternative to trying to get all the application specialists in a RAI WG would be to try to get folks from RAI to other areas. That would be similar to what v6ops WG did 3-4 years ago. -- 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
Re: Last Call: 'DomainKeys Identified Mail (DKIM) Signatures' to Proposed Standard (draft-ietf-dkim-base)
On Mon, 13 Nov 2006, Eric Allman wrote: Thanks for your good comments, which I will try to answer as best as I can. Advice from our AD and WG Chairs was that in Last Call the point is not to continue Working Group deliberations, but to (a) find minor wording issues, and (b) find show stoppers. In several cases you have made some good suggestions, but since they fall in the grey area between trivial and critical we are going to have to side-step them for now. We apologize for this, and wish we had gotten them before we went into Last Call, but we are also trying to get the document out sooner rather than later, and no project ever gets to the point where all parties consider it perfect. I do not believe this is an appropriate way to handle IETF LC comments. This approach could be understandable for issues which have already been discussed at the WG (and no significant new perspective is brought up in the IETF LC). A pointer to an issue tracker (if any) might help if the issues have already been discussed.. RFC 2119 does not require that conditions indicated by MUST, SHOULD, etc. be detectable or enforceable by the receiver. Unfortunately, it doesn't, but the specifications are still required to be of sufficient clarity, see e.g., draft-iesg-discuss-criteria section 3.1. A MUST or SHOULD statement which is not implementable may fail that test. At least right now, I don't see the point in responding to the rest of the response. -- 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
Something better than DNS?
On Tue, 21 Nov 2006, Keith Moore wrote: p.s. rather than adding more and more burdens to DNS, what we really need to be doing is figuring out how to replace it with something more robust and more flexible. (Yes, you'd have to arrange that DNS queries and queries to the new database would return consistent results; you'd also have to make sure that DNSSEC didn't break, but those are both doable.) DNS is getting very long in the tooth, and is entirely too inflexible and too fragile. The very fact that we're having a discussion about whether it makes more sense to add a new RR type or use TXT records with DKIM is a clear indicator that something seriously is wrong with DNS. Adding a new RR type should not require a single line of DNS server or client library code to be recompiled, nor any changes to the configuration of any server not advertising such records. Keith, I've seen you say this for many years now, but I'll bite now. Do you have ideas what a more flexible, less fragile, and in general a better mechanism would: 1) be or look like, or 2) what requirements we should have for building and deploying it? (if such a thing or a close likeness doesn't exist) I wonder if there are practical alternatives. A bit more dialogue on what else instead of DNS is a bad idea might help in figuring out whether there is anything the IETF could do about it. -- 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
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
On Wed, 15 Nov 2006, Fred Baker wrote: We also specifically addressed their requirements (in tsvwg) operationally: http://www.ietf.org/rfc/rfc4594.txt 4594 Configuration Guidelines for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes) (Status: INFORMATIONAL) http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-class-aggr Aggregation of DiffServ Service Classes, Kwok Ho Chan, 22-Oct-06 and http://tools.ietf.org/html/draft-baker-tsvwg-admitted-voice-dscp An EF DSCP for Capacity-Admitted Traffic, Fred Baker, 6-Oct-06 The last two are in last call and in discussion in tsvwg respectively. All of these documents are, or are aimed at Informational. I do not see how those could define DSCP codepoints or behaviour -- doing so requires Standards Action and certain codepoint pools are reserved for local/private use (which specifying them is not). I wonder how wide IETF or operator consensus is behind this work. -- 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
Re: Last Call: 'DomainKeys Identified Mail (DKIM) Signatures' to Proposed Standard (draft-ietf-dkim-base)
tokens are imported from other RFCs as noted. Those RFCs should be considered definitive. However, all tokens having names beginning with obs- should be excluded from this import, as they have been obsoleted and are expected to go away in future editions of those RFCs. .. The following tokens are imported from [RFC2821]: The following definitions are imported from [RFC2822]: The following tokens are imported from [RFC2045]: == but you don't specify below any obs- tokens -- so why mention it here at all ? == 2 of the lists use 'tokens', one 'definitions'. Is this intentional? (probably a stupid question... :-) 1. White space in the input text, including CR and LF, must be encoded. RFC 2045 does not require such encoding, and does not permit encoded of CR or LF characters that are part of a CRLF line break. INFORMATIVE NOTE: The x= tag is not intended as an anti- replay defense. == this note would be more valuable if it also mentioned what the x= tag was intended for, not just what it isn't. == s/encoded/encoding/ or something similar? 4. If the query for the public key returns multiple key records, the verifier may choose one of the key records or may cycle through the key records performing the remainder of these steps on each record at the discretion of the implementer. The order of the key records is unspecified. If the verifier chooses to cycle through the key records, then the return with ... wording in the remainder of this section means try the next key record, if any; if none, return to try another signature in the usual way. == s/return with/return/ ? -- AFAICS, 'return with' isn't used but 'return' is. [ID-DKIM-THREATS] Fenton, J., Analysis of Threats Motivating DomainKeys Identified Mail (DKIM), draft-fenton-dkim-threats-02 (work in progress), April 2006. == this has been published as an RFC. The DomainKeys specification was a primary source from which this specification has been derived. Further information about DomainKeys is at http://domainkeys.sourceforge.net/license/patentlicense1-1.html. == this domain no longer even exists, and even if it did, referring to a file named 'patentlicence1-1.html' should raise some eyebrows considering the IPR rules that no claims should be referred to in the document itself. Is this information available somewhere else? Should it be referred to using an Informative Reference? -- 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
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
On Sat, 4 Nov 2006, Fred Baker wrote: I have to say that my discussions with US DoD and DHS/NCS, and with their counterparts in other countries, doesn't suggest that the set of technical mechanisms is all specified. If we're looking only at voice, it is maybe so, but they're not looking only at voice. Questions abound around the mechanisms for sending an email and ensuring that it is delivered in a stated time interval on the order of minutes or that an indication of failure is returned to the sender, and other things. Which seems to be an indication that even if this is pursued in the IETF, RAI area seems like a wrong place. The better one would probably be OpsMgmt if there is general requirements gathering / framework work to be done. However, it's not obvious whether this is necessarily the right thing to do in the IETF or in this manner. It looks ieprep was chartered around IETF 53, and the deliverables were to be complete in 2002. Some of that work was completed relatively quick, some has taken a lot longer -- being still under evalution. Initial charter also included 'recommendations' but it's not clear to me what happened with that. It's not clear whether going on this way will achieve useful results in a useful amount of time. -- 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
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
On Wed, 1 Nov 2006, Sam Hartman wrote: I don't believe the new charter of ieprep working group belongs in the IETF. I understand why we chartered it here, and I believe that by doing as much work as we have done so far in the IETF, we have done something useful. We've described the broad problem and have helped to explain how it fits in the Internet context. That was an important thing for us to do. I think I'll agree with Sam. Having looked at the output of the WG, it already seems to include a couple of useful framework documents and about 4 requirements documents. This should already provide sufficient information how to continue the work. What isn't clear to me is what's the deployment level of these frameworks and various mechanisms. We seem to have spent at least ~4 years on this. Overprovisioning and intra-domain TE seems to have been a popular approach, but apart from that, where has this been deployed and how? Maybe we should let ITU, vendors, and/or deploying organizations to apply the existing techniques and frameworks, let this rest for 5 years and then come back to look if there is something more to be said on the subject. -- 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
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
On Thu, 2 Nov 2006, James M. Polk wrote: Having looked at the output of the WG, it already seems to include a couple of useful framework documents and about 4 requirements documents. the framework RFCs are for within a single public domain. The other RFCs are requirements based. There is no architecture guidelines docs or peering guidelines or the like. I guess by 'architecture guidelines' you refer to inter-domain guidelines as the framework RFCs already seem to deal at least to some extent with a single domain. If you don't, you may mean something that operators would use. It's not clear if one-size-fits-all guidelines could be made, or if this would be right place to try to seek it. Is there already sufficient experience of getting multi-domain work? AFAICS, this hasn't generally been considered an easily solvable problem at an operational level. Peering guidelines likely don't belong to the IETF, or has there been successful precendent for that kind of work in the past? (I could say some examples, but I don't think those were very succesful, and those were from OPS area) Even if this work was in the scope of IETF, at least these two seem more like subjects to be pursued in the OpsMgmt area. This should already provide sufficient information how to continue the work. continue the work where? by who? by another SDO? Why? Other SDOs if they're willing. Organizations that actually want to deploy this stuff (if those exist in sufficient degree). Vendors who want to push for this stuff. That is to say -- is there enough deployment (and understanding what works and is deployable and what isn't) to justify more IETF work on the subject _right now_ ? Overprovisioning and intra-domain TE seems to have been a popular approach, in which IEPREP doc was Overprovisioning and intra-domain TE discussed? draft-ietf-ieprep-domain-frame-07.txt, RFC4190, RFC43745 to name a few. but apart from that, where has this been deployed and how? Maybe we should let ITU, vendors, and/or deploying organizations to apply the existing techniques What techniques have been defined? The framework documents talk a lot about certain kinds of DSCP PHBs, mappings between PSTN and VoIP, a particular end-to-end priority field, MPLS-like traffic engineering, access-controls to prevent DoSing priority treatment, active queue management techniques, drop priority techniques, etc. -- this already seems to be a significant toolbox. It is not clear to me to what extent these have been used and do the job set out for IEPREP. And if not, is the lack of use due to people solving the problem in other ways (or not at all) rather than the lack of mechanisms? -- 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
Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)
On Sat, 30 Sep 2006, Iljitsch van Beijnum wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Key Change Strategies for TCP-MD5 ' draft-bellovin-keyroll2385-03.txt as an Informational RFC ... The problems start when BOTH sides implement the new mechanism. In that case, new keys will remain unused for some time, and then become active at some hard-to-determine time in the future. (Neither side knows for sure when the other side will switch to the new key.) This means that there will be a problem in the case where the new key isn't present on both sides, for instance because one side wasn't configured with the new key in a timely fashion, despite out-of-band agreement to do so, the keys configured on both sides don't match. Having read the draft, I do have similar concerns with double-ended operations. The draft mentions that the new key should only be used when it's at a point where it is reasonably certain that the other side would have it installed, too. This is not very exact language, and I wonder how implementations would handle this. Some other parts of the document also include suggestions which may make it harder to test the interoperability of various different mixes of implementations. One possibility could be that an implementation once it's configured with a new key MUST always immediately send a TCP probe to figure out whether the other end supports the configuration key. This ensures that at least one operator is still on-line when a key change occurs. If not, go to dormant mode, waiting for the other end to probe. A TCP probe should be something that will be acknowledged without extra code if received with a working key, but which does not need to be retransmitted with a different key if it fails. An example of this would be an additional KEEPALIVE BGP message (which would be application-specific), a TCP SYN to the application port (where you terminate the probed connection after it was established) or something similar. I'm also not sure if the time interval to change the key would be needed. The only benefit is failure to change the session to a new key within that period would trigger some kind of alert. But if the implementation already reports which keys are used and when, the operators could just monitor whether a change took place or not. In any case, a working BGP session with the old key is always better than a failed BGP session with a new key. FWIW, we haven't seen the need to ever change TCP-MD5 keys either. This feature has likely been requested by networks which fail to fulfill the assumptions of [1], i.e., they do not have filtering [or GTSM] capabilities at edges and hence the attack vector to send TCP-RST to the network's BGP sessions is basically the whole world. [1] draft-savola-rtgwg-backbone-attacks-02.txt -- 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
Re: Adjusting the Nomcom process
On Thu, 7 Sep 2006, Stewart Bryant wrote: The nomcom pool is in my view very much at the low water mark So an extension to Ralph's idea would be for the Secretatiat to send a direct mail to all those who are eligable to say that they are eligable for this important task and invite them to volunteer by clicking a hyperlink in the mail. The mail should probably include a note from the Nomcom chair etc. I said this in the past, but IMHO the job description of a NOMCOM member would need to change if we wanted more people to be involved. I think most folks would rather do something else than commit to a 5+ hour/wk schedule for a number of months. -- 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
Re: IESG response and questions to the normative reference experiment (draft-klensin-norm-ref-01.txt)
On Tue, 5 Sep 2006, Sam Hartman wrote: Pekka == Pekka Savola [EMAIL PROTECTED] writes: Pekka On Fri, 1 Sep 2006, Sam Hartman wrote: Pekka == Pekka Savola [EMAIL PROTECTED] writes: Pekka I do not agree with the assessment that there is community Pekka consensus to turn this to BCP right out. Would you be sufficiently interested in the experiment to write text if necessary? Pekka I assume you refer to guidance on how to indicate the Pekka status of a reference when down-ref'ed. Sure, I could Pekka craft some text if that's the way to go and that would No. John made it fairly clear that he wasn't really all that interested in only part one of the experiment. If he steps down as editor, would you step up? If folks agree that this the way to go, I can pick up the pen if necessary. -- 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
Re: IESG response and questions to the normative reference experiment (draft-klensin-norm-ref-01.txt)
On Fri, 1 Sep 2006, Sam Hartman wrote: Pekka == Pekka Savola [EMAIL PROTECTED] writes: Pekka I do not agree with the assessment that there is community Pekka consensus to turn this to BCP right out. Would you be sufficiently interested in the experiment to write text if necessary? I assume you refer to guidance on how to indicate the status of a reference when down-ref'ed. Sure, I could craft some text if that's the way to go and that would help. -- 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
Re: IESG response and questions to the normative reference experiment (draft-klensin-norm-ref-01.txt)
On Fri, 1 Sep 2006, Brian Carpenter wrote: The experiment is composed of two parts. The first part allows approved Internet Drafts to reference RFCs at a lower level of maturity, provided that a note explaining the reference is added. One way of looking at this is that it relaxes the requirements for normative downreferences in RFC 3967. The IESG believes that there is sufficient support for this part of the experiment that simply writing a BCP is a better approach than running an experiment. ... So, in conclusion, the IESG seeks comments on whether there is community interest in turning the first part of this experiment into a BCP. I do not agree with the assessment that there is community consensus to turn this to BCP right out. While some community members expressed their opinion that downref rules should be abolished completely, that was not the subject of draft-klensin-norm-ref Last Call. I would personally be opposed to creating such a BCP (instead of building experience through experiment first). -- 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
L2VPNs must not be IP(v4)-only
On Wed, 16 Aug 2006, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : ARP Mediation for IP Interworking of Layer 2 VPN Author(s) : H. Shah, et al. Filename: draft-ietf-l2vpn-arp-mediation-07.txt Pages : 21 Date: 2006-8-16 ... The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as ARP Mediation. ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. The document says, 10. IPV6 Considerations The support for IPV6 is not addressed in this draft and is for future study. This needs to be addressed throughout the document. The whole point of L2VPNs (IMHO) is that it's agnostic of what protocols users run above L2. Users depend on a transparent L2 service model and this model breaks that assumption. -- 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
Re: Comments on draft-carpenter-newtrk-questions-00.txt
On Thu, 13 Jul 2006, Eliot Lear wrote: By RFC, not by STD (obviously): Status 1999200020012002200320042005 - PS 102 119 71 105 103 131 169 DRAFT 6 6 2 4 7 7 3 ... I believe there are two reasons for the huge gap between PS and DRAFT: - it's difficult to get there (interop requirements, picking out uncommonly used features, etc) A part of that might also be caused by normative references problems. I don't think we have much data on that as we haven't run an experiment (yet). - nobody wants or needs to do the work (what GM in her right mind would want her experts working on something that neither generates new features nor fixes product bugs) Some of this would in fact usually be documenting the product bugs that were caused by ambiguous or incorrect specification. You're right that once you've figured out a way to fix a spec problem in YOUR implementation, there may be marginal interest in fixing it in the spec. However, I believe doing so will reduce the load on customer support (and ultimately also engineering which will need to answer the escalated support issues), because many of the support issues are actually caused by interoperability between different products or vendors. -- 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
Re: My notes on draft-carpenter-newtrk-questions-00.txt
On Wed, 12 Jul 2006, Spencer Dawkins wrote: 2. Focus on document relationships Today, users of IETF standards have no way to unambiguously identify the complete current set of specifications for a given standard. In particular, there is no effective structured document identification scheme and no systematic approach to documenting the relationship between various parts and versions of a standard. This issue is best illustrated by example. Actually, the IPv4 example in the document is quite good, but looking at dependency graphs like http://rtg.ietf.org/~fenner/ietf/deps/viz/ipv6.pdf (for IPv6, but that's also interesting) is an even better illustration. Or http://rtg.ietf.org/~fenner/ietf/deps/viz/sip.pdf, for SIP. Is there an expectation that the IETF should define which specifications should be implemented to constitute implements IPv6, implements SIP, or whatever? I guess folks have since abandoned the concept of IETF deciding on behalf of users and vendors which features are necessary in a given scenario or trying to determine what needs to be implemented to interoperate with already deployed implementations. Don't get me wrong, I love documents like draft-ietf-tcpm-tcp-roadmap-06.txt. They just take a long time and significant energy to produce. However, the main purpose (AFAICS) of those documents is not to specify which specifications must be implemented to interoperate, so many of the arguments of newtrk-questions section 2 do no apply. -- 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
Re: netwrk stuff
On Wed, 12 Jul 2006, Iljitsch van Beijnum wrote: I can't believe that I just raised my hand after who is willing to work on this tomorrow... But here is the abstract, let me know if I should write the rest: ... I'm not sure if Brian was serious about writing, as there are numerous proposals already [1], every one of them simplifying the current situation. Having half a dozen _more_ choices probably would not help in figuring how to go forward. [1] hit 'newtrk' in I-D tracker [2]. My personal favourite is draft-atkinson-newtrk-twostep-00.txt, which seems to strike a good balance between stripping out useless process but keeping at least some features (revision based on implementation experience, etc.) which at least I have found useful. [2] there are even more expired ones.. -- 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
Bad IPv6 connectivity to commercial networks
On Tue, 11 Jul 2006, Iljitsch van Beijnum wrote: traceroute6 to www.isc.org (2001:4f8:0:2::d) from 2001:510:102:100:20a:95ff:fecd:987a, 30 hops max, 12 byte packets 1 2001:510:102:100:206:d6ff:fe0f:b806 2.201 ms 7.626 ms 1.444 ms 2 2001:410:101:13::1 1.846 ms 1.736 ms 3.85 ms 3 2001:410:101:5::1 24.331 ms 24.983 ms 102.792 ms 4 2001:410:101:30::2 239.214 ms 96.351 ms 96.318 ms 5 2001:320:1b00:1::1 210.57 ms 210.528 ms 210.714 ms 6 2001:320:1a05::10 211.26 ms 220.1 ms 210.472 ms 7 2001:320:1a05::20 211.47 ms 254.317 ms 211.431 ms 8 2001:320:1a09::1 214.655 ms 214.478 ms 214.43 ms 9 2001:320:1a07::2 216.013 ms 216.143 ms 215.784 ms FWIW, I complained about this issue (lack of commercial peering/transit, e.g., NTT or GBLX or their customers) to RISQ and Canarie (v6 upstreams) on Saturday, but have seen no response or improvement. Routing to Europe or the US through various networks in Japan leaves room to improvement.. (Connectivity to academic networks is excellent, though..) -- 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
Re: IETF IPv6 platform configuration
On Mon, 12 Jun 2006, Kevin Loch wrote: Sam Hartman wrote: secIETF == IETF Secretariat [EMAIL PROTECTED] writes: secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 secIETF Native firewall (pings, traceroutes etc. are dropped) Please make sure that ICMP messages needed for path MTU discovery are not filtered. Is there a compelling reason to filter ICMP at all? IMHO, this is a valid question. There also happens to be a document, draft-ietf-v6ops-icmpv6-filtering-recs-00.txt that discusses this very issue. It might be interesting to have folks read that and provide feedback to v6ops list (v6ops@ops.ietf.org) if they think there's something amiss with it. The document just passed WG LC. -- 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
Re: Last Call: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
On Mon, 12 Jun 2006, John C Klensin wrote: FWIW, I still think the approach in the draft is a good idea given that... (1) We have not been able to get consensus eliminating a multistep standard process. For reasons explained elsewhere, I personally consider that eliminating that process would be a bad idea, but that is another discussion. The present reality is that we don't have that consensus and that blocking incremental improvements within it is a strange form of see if we can make things worse so as to build momentum for a more basic change. I don't believe in that style of doing things. (2) We have had repeated claims that the downref issue is a major cause of perceived IETF slowness in getting documents out and, especially, of getting documents to advanced maturity level. I think that validating (or invalidating) those claims would be helpful as a goal in itself. If it results in a significant number of documents being advanced, that would be a good thing. If it results in few or no documents being advanced, then we know that particular argument is not a significant part of the picture, and that would, itself, be useful. FWIW, I also agree with these and that running the experiment is a good idea. I don't think I'd want to eliminate downref rule completely, but this would seem to allow explicit acknowledgement and/or justification of each downref, which would seem like a good enough for an experiment and not that much work. -- 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
