Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On 6-sep-2005, at 1:48, JFC (Jefsey) Morfin wrote: > So for those people that aren't capable of running their own DNS, I agree with everything you say. But with this one. I think the problem is there is no free Linux/Windows nameserver with a smart enough control panel for everyone being able to run their own DNS. May be a project to dig into rather than to endanger the DNS? It would be an interesting experiment to make an easy-to-use DNS implementation for local use that runs on a residential gateway. But to be part of the global DNS requires delegation pointers from elsewhere, and most residential/SOHO users don't have addresses that are stable enough to make this usable. This may change with IPv6, though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
Iljitsch van Beijnum wrote: > It would be an interesting experiment to make an easy-to-use DNS > implementation for local use that runs on a residential gateway. But to > be part of the global DNS requires delegation pointers from elsewhere, > and most residential/SOHO users don't have addresses that are stable > enough to make this usable. This may change with IPv6, though. Quite frankly the mechanisms between registry, domain owner, and service provider suck rocks. Think about what has to happen on just the following three cases: - new customer, new domain Customer has to register domain, provide that name to the ISP, and have the ISP either list all hosts or delegate back to the customer name servers for reverse lookup. - new customer, old domain Customer has to change name servers by contacting registry and repeat reverse lookup steps - same customer, same domain, ISP renumbers ISP has to delegate addresses down to customer (a'la prefix delegation) and customer must then contact registry. I've simplified the renumbering steps as many will note, but still this shouldn't be hopeless. I just don't see any interest in actually fixing the problem. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On Sep 6, 2005, at 10:51 AM, Eliot Lear wrote: Iljitsch van Beijnum wrote: It would be an interesting experiment to make an easy-to-use DNS implementation for local use that runs on a residential gateway. But to be part of the global DNS requires delegation pointers from elsewhere, and most residential/SOHO users don't have addresses that are stable enough to make this usable. This may change with IPv6, though. sure , i heard that there is a mobile implementation arround adrian did a great job http://www.ag-projects.com/docs/Present/ETSI-20041130.pdf regards -- "When it's not necessary to do something, it's becomes necessary NOT to do it." Les Enfants Terribles www.let.de smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
At 10:12 06/09/2005, Iljitsch van Beijnum wrote: On 6-sep-2005, at 1:48, JFC (Jefsey) Morfin wrote: > So for those people that aren't capable of running their own DNS, I agree with everything you say. But with this one. I think the problem is there is no free Linux/Windows nameserver with a smart enough control panel for everyone being able to run their own DNS. May be a project to dig into rather than to endanger the DNS? It would be an interesting experiment to make an easy-to-use DNS implementation for local use that runs on a residential gateway. But to be part of the global DNS requires delegation pointers from elsewhere, and most residential/SOHO users don't have addresses that are stable enough to make this usable. This may change with IPv6, though. I am afraid not. The real digital divide is between those who can be called and those who cannot by lack of money for an IP address (the cost of an IPv6 address is also the software change, education, missing user tools). This results from an old and costly model (RIRs) rather than using a network model (like telephone). This was needed in a deployment period, this is a blocking factor for a mature global network continuity. It is a real shame that the entire world has E.164 numbers, with billions of people paying them every month, using every days, possibly keeping them all their life long, using them for the telephone, as customer ID, when they want to be differentiate from homonyms in databases, etc. and they cannot use on the ... modern ... Internet. By the ITU or by the RIRs, what is the problem to have an IPv6 plan made of a leading byte+telephone number? What is the problem of entering a telephone number in a browser and to access the corresponding byte+telnr IPv6 address? In the meanwhile is there an impossibility to think of small softwares acting as a local name server and as an external resolver. Is there a major problem in having the IP addresses managed dynamically (mobile systems would need them anyway)? Is there a big problem to get a hook before or after Hosts.txt so anyone can organise the responses he wants, for his applications? I think the real problem is to gather a DNS reference book. So the specs, the functions, the tricks of the protocol, the samples of existing code are documented authoritatively, a test bed is organised and new people with fresh ideas can come, learn and realistically develop new projects without being shout at "RFC !" or start an IETF war. mDNS and LLMNR are just that: working ideas. In 22 years should we not have had a lot more? They represent a danger for the DNS? May be, only if the DNS is not fool proof or at least resilient enough or embedded in a more global system the user has an immediate interest to protect because it would affect much more, like in the DRS (distributed registry system I alluded to and which seems an interesting area of research). IMHO it is in that directions the IETF should work. Anyway do not worry too much about a DNS network overload, without a DRS the langtags support may do better and faster. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last call comments on LTRU registry and initialization documents
Comments on draft-ietf-ltru-registry and draft-ietf-ltru-initial and, secondarily, on draft-ietf-ltru-matching... Summary: These documents represent good work, and the community should be grateful to have them. However, I believe they, and the still-incomplete "matching" one, have conclusively demonstrated that the expectations of the WG Charter were unreasonable and inappropriate. When the documents are examined as an IETF product, rather than on the assumption that the charter represents perfect foresight, it is clear that the documents should not be handled as BCPs but as Proposed Standards, with an applicability statement and/or profile to follow. The reasoning behind this conclusion is explained below. --- These specifications are a nice piece of work and the model specified is quite elegant. It appears to me to meet the goals of permitting a high degree of specificity when needed while providing a plausible mechanism for preserving stability across changes in underlying documents. Having tried, mostly unsuccessfully, to track the WG's work, I believe that the IETF community owes those who have actively participated and contributed great thanks. However, the documents that they have produced should not be approved as one or more BCPs, nor, in their present form, as replacements for RFC 3066 / BCP 47. An alternate suggestion that does not require significant work beyond that specified in the charter is outlined below. (1) BCPs or Proposed Standards The WG Charter calls for the production of BCPs. Like all provisions of WG Charters, the requirements that the community specifies and agrees to must be treated as tentative: if the best work the WG can produce, consistent with the general goals of the charter, are not acceptable as the charter specifies, the community must have the ability to change categories or, in the worst cases, refer the WG products back to the WG for further work under a new set of charter specifications. Fortunately, I do not believe that worst case applies here: the documents that were last-called appear to be quite appropriate; it is only how they are classified and applied that appears to be at issue. RFC 3066 (and 1766) were arguably just a mechanism for tying a few existing (and tested) specs together, using a review and registration procedure. As such, they were at least marginally inside the category and usage for which BCPs are appropriate. LTRU-registration, by contrast, is designed to operate without registration of full tags: the role of the reviewer, and of IANA, is to register subtag entitites from which tags can be constructed. It also provides for a highly distributed registry, with different maintainers for different subtags or groups of subtags. Neither the IETF community, nor the IANA, has any experience with doing things that way. Given the importance of this registry, and the dependencies upon the preceeding 3066 registry, that combination of conditions -- a more complex architecture, registration of components rather than full tags, and lack of community experience with the approach -- adds up to an extremely strong argument for treating these documents as Proposed Standards, and then letting them advance along the standards track as experience accumulates, rather than approving them as a single-stage BCP. (2) Matching rules and the replacement of RFC3066/ BCP47 RFC 3066 essentially specifies its own set of matching rules: for matching purposes, tags are treated as atomic and two tags match or they do not. Both the "registry" document and some of the discussion leading up to it pointed out the flaws in that approach, particularly tags that are equivalent but do not match because extra information is supplied. However, the material in Sections 4.1 and 4.2 of the LTRU specification does not provide an adequate replaceent for Section 2.3 of RFC 3066. The latter is considerably more normative and specific (even if naive in retrospect). By contrast, the material in the LTRU registry document gives much more general guidance, but not the level of specific instructions needed to promote interoperability. Hence, a _replacement_ for RFC 3066 as BCP 47 requires not only the registry specification but a set of matching rules (perhaps those to be specified in draft-ietf-ltru-matching, but see below). (3) Interoperability issues Until and unless a protocol or specification is tested in practice, interoperability is no better than an hypothesis. That is one reason, perhaps the major reason, why we have a multiple-stage standards process. It is also much of the reason why the IETF has traditionally tried to avoid complex protocols with many options. As Marshall Rose elegantly wrote in RFC 1425, Experience with many protocols has shown that: protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity. Viewed as a protocol the LTRU model is option-laden. Much as I d
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
On Mon, Sep 05, 2005 at 01:45:03AM -0700, Christian Huitema wrote: > LLMNR does not create additional DNS queries. Applications do not issue > LLMNR requests, they issue name resolution requests. When a name > resolution request is issued, the current behavior is to submit the > request to the DNS, possibly applying a "search list". LLMNR does not > change that. LLMNR adds an additional transaction at the end of the > search list, falling back to local multicast resolution if the > infrastructure could not resolve the query authoritatively. The _protocol_ does not change that. The _adoption_ of the protocol changes the world in such a way that the effect appears. Today, very few people accidentally resolve things to TLDs like .myhome or .local or .whydoicare or whatever. But if LLMNR is widely adopted, then end users will have reasons to attempt to make such resolutions as a matter of course (maybe accidentally -- the names might be configured for them by programs, so that they don't even know they're doing this). If those end users' boxes are also hooked up to the DNS infrastructure -- an assumtion that hardly requires stretching one's imagination -- then every such attempted resolution will send at least one query to the DNS infrastructure. Just because a protocol doesn't require a technical change in behaviour does not mean that its adoption will not change the techno-social environment. For a somewhat recent example, consider the phishing attacks that IDNA opened up. They're really not much different from other, previously-known phishing attacks, but because the phish-space was so much bigger, what was once a managable annoyance became a problem that needed to be addressed by those developing IDNA-aware applications. At least in the IDNA case, the social problems could be worked around with techno-social solutions. Not so in the case of LLMNR: if we start to have this problem, everyone will have to live with it, because the protocol is designed that way. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x4110 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ISMS working group and charter problems
Dear Communities, I need your help to correct for an impending mistake by the ISMS working group in the IETF. Short Version The ISMS working group is chartered to find a way for SNMP to make use of existing authentication mechanisms. The current proposed approaches will make use of TCP. I seek a change to the proposed ISMS charter that requests the working group pay attention to firewall and NAT concerns. The current envisioned approach will not work through firewalls and NATs. I specifically request that the working group be directed to consider "Call Home" functionality as a non-exclusive alternative, where the managed device contacts the manager much the same way as your PC contacts Microsoft, Apple, etc for updates. The addition of call home functionality won't represent a major architectural change to SNMP. The major architectural change (if there is one) will be the use of SSH at all and the use of TCP. If you agree with me, I ask that you respond to this note including the ietf@ietf.org and iesg@ietf.org so indicating. Reasoning Long gone are the days when the IETF can simply ignore firewalls, as this working group is currently planning. An approach that demonstrates robustness in the face of firewalls is required. Long Version SNMP version 3 has a unique authentication mechanism that does not easily integrate with other AAA systems such as radius or kerberos. After many years of complaints and lack of deployment of SNMPv3, a working group called ISMS was chartered last year to address this problem. At IETF 63 the working group decided to move forward with an approach based on SSH. As you all know, SSH is TCP-based. This represents a substantial change for SNMP. It also represents a substantial opportunity to extend manageability through firewalls. Currently, if you want to manage devices with SNMP through firewalls you must either have the firewall run an application layer gateway or you must poke a hole in the firewall based on UDP ports. If you do not control the network element, the network manager, AND the firewall, you assuredly have no hope of getting SNMP through. Even if you DO control the firewall, configuration of authorized address mappings may make it prohibitively difficult to allow management protocols through, especially in the face of dynamic address assignment mechanisms such as DHCP and PPP. Because we now are considering a TCP-based approach we have the opportunity to fix this huge problem. Why is this important? Firewalls exist today throughout our infrastructure. There's a good chance you have a simple one at home. Indeed firewalls exist between departments within enterprises. As companies add services and functions onto the Internet their ability to manage these services with SNMP deteriorates, requiring the need for expensive custom solutions and out of band management. Furthermore, many telcos today offer managed services, where they manage enterprise and consumer devices (routers, switches, etc). The whole concept of an enterprise network has, if you will, become virtualized. Today SNMP does not offer any joy to those who want to build a unified management system. More and more voice over ip (VoIP) has gained acceptance in the market place. However, the ability to debug end points real time is limited. Wouldn't it be nice for a manager to query a phone to determine how many data packets it thinks it has sent to a far end and then follow that stream to determine who is dropping? In order to accomplish this task, the manager has to have access to a phone which, if remote, may well be sitting behind a firewall such as the one you have at home. Furthermore, if the phone wants to send a notification to a manager, it too is likely to reside behind a firewall. Networks are certainly not the only functions to be managed. One could easily imagine power management services making use of standard MIBs as well as enterprise MIBs to handle capacity planning as well as dispatch in the face of live problems. What is currently envisioned by ISMS? What is currently being discussed is the traditional model, where if you want to request information you open up an SSH connection and make an SNMP query on top of it once you've authenticated. If the managed device resides behind a firewall, you lose. Worse, the currently envisioned solution calls for a separate connection to be opened to send notifications (traps). This time, if the network management station resides behind you lose again. What this means is that if there exists a firewall anywhere between the firewall and the management station, the currently proposed solution will fail. The astute will note that this approach looks a lot like old fashion FTP and will break just in just the same way. What is needed? I propose a flexible standard mechanism where either the device or the manager can be configured to initiate a connection, and that notifications occur either across the same TCP stream, w
Re: ISMS working group and charter problems
Eliot, I need your help to correct for an impending mistake by the ISMS working group in the IETF. Your note is clear and logical, and seems quite compelling. Is there any chance of getting a proponent of the working group's decision to post a defense? (By the way, I am awestruck at the potential impact of changing SNMP from UDP-based to TCP-based, given the extensive debates that took place about this when SNMP was originally developed. Has THIS decision been subject to adequate external review, preferably including a pass by the IAB?) -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
At 02:00 PM 9/6/2005, Dave Crocker wrote: Eliot, I need your help to correct for an impending mistake by the ISMS working group in the IETF. Your note is clear and logical, and seems quite compelling. Is there any chance of getting a proponent of the working group's decision to post a defense? (By the way, I am awestruck at the potential impact of changing SNMP from UDP-based to TCP-based, given the extensive debates that took place about this when SNMP was originally developed. Has THIS decision been subject to adequate external review, preferably including a pass by the IAB?) I agree the argument is well laid out, and would be interested in hearing the thinking of ISMS in response. I'm more than a bit concerned, however, when folks start talking about solutions that will permit things to pass through firewalls without configuration. Those in charge of firewalls are often purposely setting policy. If there is a perceived need for a policy that prevents SNMP traffic, then it should remain possible for the administrator of that network element to make that call. I must say I have some concern with overlaying SNMP on SSH, since that precludes the firewall knowing whether the traffic is general SSH keyboard traffic or network management. Let's hear more about the thinking involved. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
On 6-sep-2005, at 19:37, Eliot Lear wrote: I seek a change to the proposed ISMS charter that requests the working group pay attention to firewall and NAT concerns. The current envisioned approach will not work through firewalls I consider the fact that random people across the internet can't manage my equipment a feature rather than a bug. and NATs. The IETF has been doing extensive work on NAT traversal, have a look and see if you can reuse some existing mechanism. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
> "Dave" == Dave Crocker <[EMAIL PROTECTED]> writes: Dave> (By the way, I am awestruck at the potential impact of Dave> changing SNMP from UDP-based to TCP-based, given the Dave> extensive debates that took place about this when SNMP was Dave> originally developed. Has THIS decision been subject to Dave> adequate external review, preferably including a pass by the Dave> IAB?) Certainly one of the reasons I requested IETF-wide review for the ISMS recharter is so that decisions like this can be reviewed by the community. The IAB gets to see charters at about the same time as the IESG does; they have sent no negative comments to this charter. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Daniel, All solutions will use a different SSH port as part of the standard just so that firewall administrators have the ability to block. Eliot Daniel Senie wrote: > At 02:00 PM 9/6/2005, Dave Crocker wrote: > > >> Eliot, >> >>> I need your help to correct for an impending mistake by the ISMS >>> working group in the IETF. >> >> >> >> Your note is clear and logical, and seems quite compelling. >> >> Is there any chance of getting a proponent of the working group's >> decision to post a defense? >> >> (By the way, I am awestruck at the potential impact of changing SNMP >> from UDP-based to TCP-based, given the extensive debates that took >> place about this when SNMP was originally developed. Has THIS >> decision been subject to adequate external review, preferably >> including a pass by the IAB?) > > > I agree the argument is well laid out, and would be interested in > hearing the thinking of ISMS in response. > > I'm more than a bit concerned, however, when folks start talking about > solutions that will permit things to pass through firewalls without > configuration. Those in charge of firewalls are often purposely setting > policy. If there is a perceived need for a policy that prevents SNMP > traffic, then it should remain possible for the administrator of that > network element to make that call. I must say I have some concern with > overlaying SNMP on SSH, since that precludes the firewall knowing > whether the traffic is general SSH keyboard traffic or network management. > > Let's hear more about the thinking involved. > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Hi Iljitsch, > On 6-sep-2005, at 19:37, Eliot Lear wrote: > >> I seek a change to the proposed ISMS charter that requests the working >> group pay attention to firewall and NAT concerns. The current >> envisioned approach will not work through firewalls > > > I consider the fact that random people across the internet can't manage > my equipment a feature rather than a bug. Use of a well known port that you can block will actually make it EASIER for you to make use of that "feature". Today if you leave your PC up with various forms of commercial software, you have no idea who is connecting to what. > The IETF has been doing extensive work on NAT traversal, have a look > and see if you can reuse some existing mechanism. All mechanisms used with the possible exception of an additional SNMP table will be re-used from existing IETF work (mostly SSH with help from the fact that it's based on TCP). Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes: Eliot> Daniel, All solutions will use a different SSH port as part Eliot> of the standard just so that firewall administrators have Eliot> the ability to block. I don't actually think this has been decided yet. I believe arguments were presented on both sides of the different port question and I don't recall a clear consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
In message <[EMAIL PROTECTED]>, Dave Crocker writes: > > >(By the way, I am awestruck at the potential impact of changing SNMP from >UDP-based to TCP-based, given the extensive debates that took place about this >when SNMP was originally developed. Has THIS decision been subject to >adequate >external review, preferably including a pass by the IAB?) When I was the sponsoring AD for the group, I pushed back hard on this point. The WG opted for the present path. I'm not saying they're right -- in fact, I disagreed -- but the decision wasn't made by default. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
On Tue, 6 Sep 2005, Eliot Lear wrote: All solutions will use a different SSH port as part of the standard just so that firewall administrators have the ability to block. FWIW, I'm a bit concerned as well. I don't see clearly which scenarios you have in mind when you say you want better firewall/NAT traversal capabilities. In the scenarios I see, it's a Good Thing that as a network admin I can block all [incoming] SNMP traffic (whether ISMS or not), and moreover, that it's blocked by default if I create a typical policy; I want to do that in the future too. Using a different port is obviously the first step here. But if a different port is being used, I don't see what more is absolutely required. Are you saying some of the following: 1) ISMS specs should specify that the monitored hosts can/should certainly keep open a TCP session so the network management (in both ways) can happen over that session. (This seems pretty trivial..) 2) We should specify how network management hosts could reside behind a firewalls which block the management ports (I don't think this is needed or should be done). 3) ISMS specs should specify network management hosts' capability to poll hosts behind a firewall, which blocks incoming ISMS port by default -- by using a mechanism where outgoing "I want to be monitored using ISMS!" messages would open pinholes in the firewalls. (Is there sufficient benefit in this compared to 1) as you still can't monitor the hosts when you want to unless they are constantly polling you?) Something else? Please be a bit more specific about what you think the "NAT/FW problem" is in this context, and what you'd like to see done about it. (Personally, I'm not sure if I buy the whole ISMS thing at the moment, because the operators AFAICT are sufficiently happy with the SNMPv1/2 security model -- so whatever you build, it has to be at least that simple otherwise it won't be used.) -- 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: ISMS working group and charter problems
Hi Pekka, Pekka Savola wrote: > Are you saying some of the following: > > 1) ISMS specs should specify that the monitored hosts can/should > certainly keep open a TCP session so the network management (in both > ways) can happen over that session. (This seems pretty trivial..) > > 2) We should specify how network management hosts could reside behind a > firewalls which block the management ports (I don't think this is needed > or should be done). Depending on what you mean by "network management hosts" it could be (1) or (2) ;-) I'm saying if there is a device that wishes to to be managed through a firewall, allow it to open a connection on a specified port (just so that firewalls can block it). Remember, your laptop does this today with HTTP on port 80 or HTTPS on port 443 (worse because you can't even inspect). Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
...Has THIS decision been subject to adequate external review, preferably including a pass by the IAB?) When I was the sponsoring AD for the group, I pushed back hard on this point. The WG opted for the present path. I'm not saying they're right -- in fact, I disagreed -- but the decision wasn't made by default. Well, I was not at all trying to raise questions about IETF process, but now that you mention it... It strikes me that this is a remarkably constructive example of why ADs should less often "make decisions" or debate solely within the IESG, and more often should "recruit rough consensus from the larger IETF community." That is, the major benefit in the broad and deep expertise of an AD like Steve is to detect major issues and to raise a warning to the larger community. Then they can seek broader review and consensus for questionable working group choices that might have much larger impact. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments on LTRU registry and initialization documents
John, what does it mean to put a registry document on the standards track? In particular, how do you get multiple implementations of a registry? --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Certainly one of the reasons I requested IETF-wide review for the ISMS recharter is so that decisions like this can be reviewed by the community. The IAB gets to see charters at about the same time as the IESG does; they have sent no negative comments to this charter. Sam, I've tried to search the ietf-announce archives, google, etc. for any sort of announcements, outside of the isms working group, concerning the draft re-chartering text for isms. Unfortunately I have not been able to find it, so I do not know what request of yours you are referring to. In any event, I think the significance of Eliot's (and Steve Bellovin's) postings have less to do with a chartering event and more to do with decisions made DURING a working group's normal activities. In particular, when a working group gets to the point of making a decision that has broad architectural or operational impact, it is the expertise of ADs, IAB members, and other senior participants, that can serve to raise a question to the larger community, exactly as Eliot is now doing. What I took from Steve Bellovin's posting was the implication that his valid concerns were expressed in a more limited context. What I am suggesting is that we should get into the habit of having such concerns raised in the broader community, when the impact is this large. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments on LTRU registry and initialization documents
--On Tuesday, 06 September, 2005 15:14 -0400 Sam Hartman <[EMAIL PROTECTED]> wrote: > John, what does it mean to put a registry document on the > standards track? In particular, how do you get multiple > implementations of a registry? One is reminded of the story of Eeyore's birthday party. Registering things --putting them into a registry so that they can be retrieved and examined using whatever key was used to put them there-- is always easy and, as you point out, untestable. But it is also almost never the point: the point is whether the right information is being placed in the registry to support the relevant applications and whether those applications can use the information in a way that promotes interoperability. With regard to that driving issue, it is certainly possible to have multiple implementations of matching rules. It is certainly possible to examine, in practice, different uses of the tagging system to determine whether its mechanisms are sufficient and, if sufficient, whether they meet some "minimum necessary" criteria or represent serious overkill and/or redundancy. With apologies to Spencer, let me turn your question around and ask how something can be identified as a "Best Common Practice" when * when it has not been practiced at all, * when there is no evidence that it is "best" (even if one agrees that no better options are on the table or even that none are likely to be searched out and found unless, someone, this approach is shown to fail as RFC 3066 was shown to fail), and * it certainly isn't "common" in the "widely disseminated and used" sense of that term. Things would be better if we had "PP" (proposed practice), "AGI" (apparently good idea), or "WTOSITD" (well thought-out shot in the dark), or "NRtBTWNW" (no reason to believe this will not work) categories. But we don't. And the model and mechanisms associated with Proposed Standard, when applied to the use cases rather than the registry itself, much more nearly meet application needs and community expectations than identifying a document like that as a BCP. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments on LTRU registry and initialization documents
This document defines structure and meaning for labels, as well as the procedure for registering parts of that structure. As such, the structure is "bits on the wire" and is subject to interoperability concerns. Yours, Joel M. Halpern At 03:14 PM 9/6/2005, Sam Hartman wrote: John, what does it mean to put a registry document on the standards track? In particular, how do you get multiple implementations of a registry? --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
[dropping NANOG] On 6-sep-2005, at 20:43, Eliot Lear wrote: I consider the fact that random people across the internet can't manage my equipment a feature rather than a bug. Use of a well known port that you can block will actually make it EASIER for you to make use of that "feature". Today if you leave your PC up with various forms of commercial software, you have no idea who is connecting to what. Ok. The IETF has been doing extensive work on NAT traversal, have a look and see if you can reuse some existing mechanism. All mechanisms used with the possible exception of an additional SNMP table will be re-used from existing IETF work (mostly SSH with help from the fact that it's based on TCP). You do realize that you import all the weaknesses of TCP then, don't you? I'm not too familiar with NAT traversal techniques, but AFAIK there isn't a good match between these mechanisms and what you want to do here. You may want to consider looking at the mechanism for HTTPS proxying. This works by having the client connect to the proxy, optionally authenticating itself, and then asking the proxy to connect it to the ultimate destination. The encryption is end-to-end and thus opaque to the proxy, but the proxy does have the opportunity to assert access restrictions. You'd probably need a mechanism for internal to-be-managed systems to register their manageability with the proxy. A simple split horizon (in addition to the normal layers of access control) could avoid these proxies from being abused for spam and the like. Obviously the SSL in HTTPS is a bit different from SSH, but that shouldn't be too hard to fix one way or another. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group and charter problems
>> The IETF has been doing extensive work on NAT traversal, have a look >> and see if you can reuse some existing mechanism. > All mechanisms used with the possible exception of an additional SNMP > table will be re-used from existing IETF work (mostly SSH with help > from the fact that it's based on TCP). Perhaps then it's time we consider mandating a "NAT-Traversal" section to standards track documents much like IANA and Security considerations have become common place to this day. Anything that's not covered by the BEHAVE work already done should be covered there, as the IETF seems to have indeed accepted the proliferation and widespread acceptance of NAT functionality. -Tom ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group and charter problems
At 06:00 PM 9/6/2005, you wrote: >> The IETF has been doing extensive work on NAT traversal, have a look >> and see if you can reuse some existing mechanism. > All mechanisms used with the possible exception of an additional SNMP > table will be re-used from existing IETF work (mostly SSH with help > from the fact that it's based on TCP). Perhaps then it's time we consider mandating a "NAT-Traversal" section to standards track documents much like IANA and Security considerations have become common place to this day. Anything that's not covered by the BEHAVE work already done should be covered there, as the IETF seems to have indeed accepted the proliferation and widespread acceptance of NAT functionality. Actually, a "Firewall Considerations" section would make sense. That section might indeed be a good place to discuss NAT issues, if any, but firewall interactions with protocols exist in many cases where NAT is in use. Though many have expressed their hope that NAT does not persist in the IPv6 world, there should be no doubt in anyone's mind that firewalls will be with us permanently. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
In message <[EMAIL PROTECTED]>, Daniel Senie writes: >At 06:00 PM 9/6/2005, you wrote: >> >> The IETF has been doing extensive work on NAT traversal, have a look >> >> and see if you can reuse some existing mechanism. >> >> > All mechanisms used with the possible exception of an additional SNMP >> > table will be re-used from existing IETF work (mostly SSH with help >> > from the fact that it's based on TCP). >> >>Perhaps then it's time we consider mandating a "NAT-Traversal" section to >>standards track documents much like IANA and Security considerations have >>become common place to this day. Anything that's not covered by the BEHAVE >>work already done should be covered there, as the IETF seems to have indeed >>accepted the proliferation and widespread acceptance of NAT functionality. > >Actually, a "Firewall Considerations" section would make sense. That >section might indeed be a good place to discuss NAT issues, if any, >but firewall interactions with protocols exist in many cases where >NAT is in use. Though many have expressed their hope that NAT does >not persist in the IPv6 world, there should be no doubt in anyone's >mind that firewalls will be with us permanently. > Indeed. In Hal Burch's dissertation, he concluded that at least 93% of hosts attached to the Internet are behind a ltering device of some type. Because this excludes hosts behind rewalls that block all incoming connection attempts, the true percentage is even higher than 93%. Clearly, rewalls are an important consideration when designing protocols and developing models for the Internet. More of his measurements concluded that at least 56% of hosts are behind a firewall that blocks by default. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
On 7-sep-2005, at 0:16, Daniel Senie wrote: Actually, a "Firewall Considerations" section would make sense. What would be in such a section? There are only three possibilities: 1. There is no firewall: no need for text. 2. There is a firewall, and it doesn't try to block the protocol: no need for text. 3. There is a firewall, and it tries to block the protocol. So what text would be helpful in case #3? Either the firewall successfully blocks the protocol and the firewall works and the protocol doesn't, or the firewall doesn't manage to block the protocol and the protocol works but the firewall doesn't. So whatever happens, someone is going to be unhappy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
In message <[EMAIL PROTECTED]>, Eliot Lear writes: > >More and more voice over ip (VoIP) has gained acceptance in the market >place. However, the ability to debug end points real time is limited. >Wouldn't it be nice for a manager to query a phone to determine how >many data packets it thinks it has sent to a far end and then follow >that stream to determine who is dropping? In order to accomplish this >task, the manager has to have access to a phone which, if remote, may >well be sitting behind a firewall such as the one you have at home. Eliot, I have very grave reservations about this. Quite frankly, I don't think that arbitrary management stations should have any right whatsoever to connect to my devices. I agree that the functionality you suggest is useful. The trick is to permit that without permitting misbehavior. (I'll note here that the interests of vendors and the interests of users are not identical. More and more, vendors like subscription-based models, where users keep on paying, to give just one example.) This requires not just a view-based access control model -- where the view might be "MIB variables for this call only" -- but an express intent by the user to permit the access for that particular call. This demands a different notion of "view" than has been traditional; it also implies a user interface issue and -- given the existence of firewalls -- a multi- party protocol: my endpoint, your endpoint, my management proxy (which is accessible through the firewall), your management proxy, and the vendor's diagnostic station. I'd be hard-pressed to see this as within scope for ISMS. It may, however, be a very nice subject for a separate working group. >Furthermore, if the phone wants to send a notification to a manager, it >too is likely to reside behind a firewall. Not if the site is properly managed. The manager's port should be exposed to the outside. Just as web servers have to permit inbound port 80 and mail servers have to permit inbound port 25, a management station has to accept its own traffic. A firewall can, at best, protect the other ports on the machine -- but those should be turned off anyway. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments on LTRU registry and initialization documents
John C Klensin wrote: > (ii) either put the initialization draft on the standards > track with it or publish it as informational and use the > downref procedure, That's a formal point: The initial registry is too long to put it in the IANA considerations of the main document, and it will be soon obsolete. Therefore it had to be a separate document. Because the WG wanted a proper last call also for this part it was published as I-D. Same idea as for e.g. RfC 4021 - a part of the header field registry defined in RfC 3864. Apparently RfC 4021 is "standards track", but "informational" for the initial registry is also possible. I don't get the need for "downref" in this case, the reference to the initial registry in the main document _is_ only informational. Do "informational" RfCs created by a WG get a "last call" ? I'm not sure what the last paragraph in 2026 4.2.3 means. Something's odd with the procedures here, I'd be surprised if RfC 4021 would be promoted on stadards track, it's only a (now already obsolete) snapshot of a part of a registry. > The documents make reference to the "record-jar" format. I > believe the text in ltru-registry is sufficient to define > the portion of that spec that is relevant Yes, the defined format is "inspired by" record-jar, it does not claim to be the real thing. E.g. it doesn't have arbitrary comment lines, OTOH it defines a way to encode Unicode by the known &#x; sequences for u+. > a dependency on a moderately expensive book that could go out > of print as part of the definition for an IANA registry No, it's also only informational for those interested in "the real thing" instead of what's used for the registry and future extension registries. > incidentally, the reference given is incomplete. Yes, the draft author knows already how to add the proper ISBN with xml2rfc, "easily fixed" as you said. Not referencing the original idea at all would be wrong. But the reference in the initial registry draft is in fact unnecessary. Think of it as some kind of "informational credits" in the main document. We also considered a pure 2822-like format with CRLF CRLF as a record separator, but the WG preferred CRLF "%%" CRLF, that's all - no copyright traps and no necessity to buy the book (e.g. I don't have it). Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
In message <[EMAIL PROTECTED]>, Iljitsch van Beijn um writes: >On 7-sep-2005, at 0:16, Daniel Senie wrote: > >> Actually, a "Firewall Considerations" section would make sense. > >What would be in such a section? There are only three possibilities: > >1. There is no firewall: no need for text. >2. There is a firewall, and it doesn't try to block the protocol: no >need for text. >3. There is a firewall, and it tries to block the protocol. > >So what text would be helpful in case #3? Either the firewall >successfully blocks the protocol and the firewall works and the >protocol doesn't, or the firewall doesn't manage to block the >protocol and the protocol works but the firewall doesn't. So whatever >happens, someone is going to be unhappy. > Not at all. Often, a firewall needs to know a fair amount about the protocol to do its job. FTP is the simplest case -- it has to look for the PORT (and, in some configuration, the PASV) command. H.323 and SIP are more complex. But for complex protocols, we need to go a step further. SIP has, built-in, provision for gateways. There are a number of reasons for this, but firewall friendliness is certainly one of them. The proper question is this: would adding something to the protocol enable it to operate properly in the presence of a firewall *without* subverting site security policy. The lack of that latter consideration has led to people using http as the universal firewall traversal protocol, with the obvious bad side-effects. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
On 7-sep-2005, at 1:04, Steven M. Bellovin wrote: Either the firewall successfully blocks the protocol and the firewall works and the protocol doesn't, or the firewall doesn't manage to block the protocol and the protocol works but the firewall doesn't. So whatever happens, someone is going to be unhappy. Not at all. Often, a firewall needs to know a fair amount about the protocol to do its job. FTP is the simplest case -- it has to look for the PORT (and, in some configuration, the PASV) command. H.323 and SIP are more complex. I'm not very comfortable with the notion of having a third party device deciding what is valid communication between two hosts connected to the internet. This is just too fragile. For instance, a popular filter on *BSD (they're all named [i]pf[w] so I can never remember which is which) is unable to handle RFC 1323 window scaling properly. PIX firewalls truncate(d) EDNS0 packets. ICMP packet too bigs are filtered in many places, as is ECN. I recognize that carrying all existing firewalls to the scrap heop won't immediately solve our problems, but we do have to realize that current filter practice do almost as much harm as they do good. We really need better stuff here. (It's amusing to see that to some people, security means encrypting their communication, while to others it means inspecting that same communication.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group and charter problems
>>> Actually, a "Firewall Considerations" section would make sense. >> Agreed. >>What would be in such a section? There are only three possibilities: >> >>1. There is no firewall: no need for text. >>2. There is a firewall, and it doesn't try to block the protocol: no >>need for text. >>3. There is a firewall, and it tries to block the protocol. >> >>So what text would be helpful in case #3? Either the firewall >>successfully blocks the protocol and the firewall works and the >>protocol doesn't, or the firewall doesn't manage to block the protocol >>and the protocol works but the firewall doesn't. So whatever happens, >>someone is going to be unhappy. >> >Not at all. Often, a firewall needs to know a fair amount about the protocol to do its job. FTP is the simplest >case -- it has to look for the PORT (and, in some configuration, the PASV) command. H.323 and SIP are more >complex. > Exactly, ignoring the particulars of a protocol and choosing to just block/not block it doesn't really make the firewall useful to that protocol. That's certainly one of the valid choices for a firewall to take, however. >But for complex protocols, we need to go a step further. SIP has, built-in, provision for gateways. There are a >number of reasons for this, but firewall friendliness is certainly one of them. The proper question is this: >>would adding something to the protocol enable it to operate properly in the presence of a firewall *without* >>subverting site security policy. The lack of that latter consideration has led to people using http as the >>universal firewall traversal protocol, with the obvious bad side-effects. Indeed this section could be a way of documenting the proper behavior of a firewall in the context of a certain protocol. For example a firewall could say with regard to protocol X I either: A) treat it as unknown/don't recognize the protocol <- this is fine if you don't use the protocol B) meet the full criteria specified in the "Firewall Considerations" section <-this may be a factor if the particular protocol receives heavy use in your organization C) Do something inbetween, which while possibly helpful should not be considered compliant for the sake of differentiating devices. Much like you can configure port forwarding and a DMZ among a multitude of other things commonly on firwall/nats allowing for the possibility of consistent behavior/options relating to a new protocol among firewall vendors MUST be better than leaving it to itself like has happened with the NAT situation. -Tom ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
In message <[EMAIL PROTECTED]>, Iljitsch van Beijn um writes: >On 7-sep-2005, at 1:04, Steven M. Bellovin wrote: > >>> Either the firewall >>> successfully blocks the protocol and the firewall works and the >>> protocol doesn't, or the firewall doesn't manage to block the >>> protocol and the protocol works but the firewall doesn't. So whatever >>> happens, someone is going to be unhappy. > >> Not at all. Often, a firewall needs to know a fair amount about the >> protocol to do its job. FTP is the simplest case -- it has to look >> for >> the PORT (and, in some configuration, the PASV) command. H.323 and >> SIP >> are more complex. > >I'm not very comfortable with the notion of having a third party >device deciding what is valid communication between two hosts >connected to the internet. This is just too fragile. For instance, a >popular filter on *BSD (they're all named [i]pf[w] so I can never >remember which is which) is unable to handle RFC 1323 window scaling >properly. PIX firewalls truncate(d) EDNS0 packets. ICMP packet too >bigs are filtered in many places, as is ECN. > >I recognize that carrying all existing firewalls to the scrap heop >won't immediately solve our problems, but we do have to realize that >current filter practice do almost as much harm as they do good. We >really need better stuff here. > >(It's amusing to see that to some people, security means encrypting >their communication, while to others it means inspecting that same >communication.) > I opt for each in its place. I'm also an advocate for distributed firewalls. But I *really* don't want to refight the whole firewall issue yet again; I've been through that too many times in the last decade or so. For right now, though, the issue is engineering. Again, the vast majority of hosts are behind firewalls. Is the philosophical issue that important that we should ignore it? I don't think so. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Question on level_idc in Session Description Protocol, RFC3984
Dear Experts, This is a scenario. A send B a SDP message: m=video 7080 RTP/AVP 100 a=rtpmap:100 H264/9 a=fmtp:100 profile-level-id = 420015; ... ... B can decode bitstream equal or below level 2.0, so B should reject this offer. But my concern is, on B's answer to A, can B request A to encode it's bitstream at a level equal or below 2.0, so that B can accept the offer? If this is possible, how should B reply? Or is it that the only options available to B is either to reject or accept the offer as a whole, and there is no room for negotiation? In addition, if B has profile_id of Baseline profile and constraint_set0_flag of 1 and level_idc of 2.1, B can accept the offer, right? Thank you very much. Warmest regards, Ryan Singapore [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Hi - > From: "Eliot Lear" <[EMAIL PROTECTED]> > To: "IETF Discussion" ; ; > Sent: Tuesday, September 06, 2005 10:37 AM > Subject: ISMS working group and charter problems ... > The addition of call home functionality won't represent a major > architectural change to SNMP. The major architectural change (if there > is one) will be the use of SSH at all and the use of TCP. ... Regardless of whether "call home functionality" as you defined it is desirable, I disagree with the claim that it wouldn't represent a major architectural change to SNMP. For notification originators, it is a quite natural extension, and I have no problem with it. For command responders, I think this would be a fairly significant addition to the architecture. I'm neutral on the question of whether it is needed, and perhaps we only differ in what we perceive as "major", but I think we need to be clear that it would indeed require changing the SNMP architecture. I also disagree that it is the use of SSH or TCP that results in the architectural changes. TCP use without "call home" (as in RFC 3430) requires no architectural changes. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Hi Steve, > I agree that the functionality you suggest is useful. The trick is to > permit that without permitting misbehavior. (I'll note here that the > interests of vendors and the interests of users are not identical. > More and more, vendors like subscription-based models, where users keep > on paying, to give just one example.) This requires not just a > view-based access control model -- where the view might be "MIB > variables for this call only" -- but an express intent by the user to > permit the access for that particular call. This demands a different > notion of "view" than has been traditional; it also implies a user > interface issue and -- given the existence of firewalls -- a multi- > party protocol: my endpoint, your endpoint, my management proxy (which > is accessible through the firewall), your management proxy, and the > vendor's diagnostic station. I'd be hard-pressed to see this as within > scope for ISMS. It may, however, be a very nice subject for a separate > working group. I think there are a few models that could be considered. The first is where a single administrative domain is at play, where really my management proxy = your management proxy. This might be an optimization of what you're saying. Arguably you're already talking to my management proxy through SIP. An alternative model that has been mentioned is a way to query OIDs over SIP. I'm not a SIP guy so I don't know if the SIP proxy can even initiate queries. In the case you mentioned, with four proxies, I'm okay with that as long as it's not mandated in the model. Anything that requires four of anything is never going to survive the Internet. e2e is hard enough with 2 devices ;-) > > >>Furthermore, if the phone wants to send a notification to a manager, it >>too is likely to reside behind a firewall. > > > Not if the site is properly managed. The manager's port should be > exposed to the outside. Just as web servers have to permit inbound > port 80 and mail servers have to permit inbound port 25, a management > station has to accept its own traffic. A firewall can, at best, > protect the other ports on the machine -- but those should be turned > off anyway. You can't really tell where the firewalls area going to be in the general case. And with mobile managed devices, you really can't tell, because access will vary. My point was that in the case where a notification connection is initiated in one direction and a request connection is initiated in another, you're all but guaranteed that one or the other will fail in the face of a firewall, and that is the current envisioned approach. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
Randy, > Regardless of whether "call home functionality" as you defined it is > desirable, I disagree with the claim that it wouldn't represent a > major architectural change to SNMP. For notification originators, it > is a quite natural extension, and I have no problem with it. For command > responders, I think this would be a fairly significant addition to the > architecture. > I'm neutral on the question of whether it is needed, and perhaps we only > differ in what we perceive as "major", but I think we need to be clear that > it would indeed require changing the SNMP architecture. There is a difference between a connection and a request. Reversing the transport connection direction doesn't say that we reverse request directions or notification directions. Quite the contrary. They stay the same. To me that means no substantial change over what is already proposed. Indeed the currently envisioned approach guarantees that either notifications or requests will be broken because one connection will initiate in one direction and another will initiate in the reverse. FTP all over again, as I said. > > I also disagree that it is the use of SSH or TCP that results in the > architectural > changes. TCP use without "call home" (as in RFC 3430) requires no > architectural changes. Clearly since SSH is now carrying authentication information there is a substantial change, where SNMP inherits bonafides from the process below. That is not the case in 3430. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments on LTRU registry and initialization documents
--On Wednesday, 07 September, 2005 01:10 +0200 Frank Ellermann <[EMAIL PROTECTED]> wrote: > John C Klensin wrote: > >> (ii) either put the initialization draft on the standards >> track with it or publish it as informational and use the >> downref procedure, > > That's a formal point: The initial registry is too long to > put it in the IANA considerations of the main document, and > it will be soon obsolete. Therefore it had to be a separate > document. > > Because the WG wanted a proper last call also for this part > it was published as I-D. Same idea as for e.g. RfC 4021 - a > part of the header field registry defined in RfC 3864. > > Apparently RfC 4021 is "standards track", but "informational" > for the initial registry is also possible. I don't get the > need for "downref" in this case, the reference to the initial > registry in the main document _is_ only informational. That wasn't clear from the text, but I may not have read closely enough.See below. > Do "informational" RfCs created by a WG get a "last call" ? > I'm not sure what the last paragraph in 2026 4.2.3 means. Independent of what that paragraph means, it is common for anything that is presented by the WG to IESG for comment to get a last call within the WG; I can't imagine a WG chair doing otherwise. Whether WG informational documents are then Last Called to the IETF is up to the IESG and relevant ADs. There is no requirement that it be done, but it generally is done if the AD concludes that the document is likely to be either consequential or controversial. > Something's odd with the procedures here, I'd be surprised > if RfC 4021 would be promoted on stadards track, it's only > a (now already obsolete) snapshot of a part of a registry. Personal opinion: What should be done in cases like this is to structure the I-D so that it clearly differentiates between: (i) The specification, rationale, and other contextual information for the initial registry contents, and (ii) The actual listing of the registry initialization and that the specification provide for some way of distinguishing between initial registry entries and subsequent ones by examining the registry (this could be as simple as the specification of a particular date. Then an instruction to the RFC Editor could be included in the I-D asking that they not publish the initialization document until the entries have been made in the IANA registry and then that the list of entries be dropped and replaced with a pointer paragraph and reference. That would lead to an RFC that was clearly informational and fairly short, saving everyone long-term problems. For draft-ietf-ltru-initial, that would mean retention of sections 1, 2, and 4-7 into the RFC but the replacement of section three with, e.g., "3. The initial contents of the registry as specified in this document are those entries in the IANA registry [IANA-registry] with a field-name of "Added" and a value of "2005-07-10". Note that [ltru-registry, Section 3.1] requires that an "Added" field appear in each registration record and that its Section 3.3(1) specifies that field must not be changed after registration." Then you are done. Presto, clearly informational document, historical information retained in the registry (which is where, IMO, it belongs), no chance of anyone ignoring the instructions in the third paragraph of Section 1 that the initialization list in the RFC is not the registry, and an RFC that runs around ten pages rather than 118. I think that would be a win all around. But, again, just my opinion. >> The documents make reference to the "record-jar" format. I >> believe the text in ltru-registry is sufficient to define >> the portion of that spec that is relevant > > Yes, the defined format is "inspired by" record-jar, it does > not claim to be the real thing. E.g. it doesn't have arbitrary > comment lines, OTOH it defines a way to encode Unicode by the > known &#x; sequences for u+. > >> a dependency on a moderately expensive book that could go out >> of print as part of the definition for an IANA registry > > No, it's also only informational for those interested in "the > real thing" instead of what's used for the registry and future > extension registries. I would recommend that, as an editorial matter, use of phrases like "inspired by" or "derived from" would clear up a lot of confusion before it starts, making it clear that the book is not needed. For example, the beginning of the second paragraph of 3.1 might read 'The registry will be in a text file format that is fully specified below. This format was inspired by the "record-jar" format [record-jar].' But, again, this is purely an editorial matter as far as I'm concerned. >> incidentally, the reference given is incomplete. > > Yes, the draft author knows already how to add
Re: ISMS working group and charter problems
--On 6. september 2005 11:00 -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: (By the way, I am awestruck at the potential impact of changing SNMP from UDP-based to TCP-based, given the extensive debates that took place about this when SNMP was originally developed. Has THIS decision been subject to adequate external review, preferably including a pass by the IAB?) just a formality note (and dropping nanog and the IESG): I believe that the ISMS WG's proposal is about ADDING the possibility of SNMP over TCP, not about CHANGING SNMP to use TCP. UDP will still work. And I believe Eliot's concern is about letting the TCP session that carries the SNMP PDUs be opened from the agent to the manager, rather than from the manager to the agent (yes I know - this is SNMPv1 terminology, but I've forgotten the SNMPv3 terminology); that is another feature that comes in addition to what the group is apparently currently working on. And just BTW: I find "call home" reasonable to specify too, once you've done TCP. It's obvious enough that I think it will be added to implementations whether or not we specify it, so we should have very strong reasons not to do so. I don't even believe you need to "turn" the session, since SNMPv3 doesn't recognize the concept of a "direction" for a session just let the PDUs flow Disclaimer: I, too, have not seen the charter being proposed, and I have not followed the ISMS group. I have, however, once upon a time been responsible AD for the SNMPv3 WG. Harald pgpOEmYmFJDBd.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
