From dromasca@avaya.com Wed Jun 3 02:17:24 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AE33A6986 for ; Wed, 3 Jun 2009 02:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFn+WujvwTwR for ; Wed, 3 Jun 2009 02:17:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D8B7A3A6A56 for ; Wed, 3 Jun 2009 02:17:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,297,1241409600"; d="scan'208";a="172767117" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jun 2009 05:17:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jun 2009 05:17:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 11:17:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Updated residential gateway document Thread-Index: AcnkA+Aqb6hmVrI/TEa/jlcYMEnboQAKCz4g From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] FW: [Geopriv] Updated residential gateway document X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:17:24 -0000 FYI.=20 -----Original Message----- From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Thomson, Martin Sent: Wednesday, June 03, 2009 7:29 AM To: geopriv@ietf.org Subject: [Geopriv] Updated residential gateway document Hi All, I've been sitting a version of this document for a little while now. The document describes use of the reverse DNS tree for discovery to address those scenarios currently being discussed in ECRIT. The problem statement section of the document should provide an adequate description of where this is applicable. =20 I'm told that this version lacks a little polish, please forgive any shortcomings, they are as a result of me not giving this the time that it is due. I believe that most of the substance is correct. --Martin ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From dromasca@avaya.com Wed Jun 3 02:40:13 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B724D3A6BDD for ; Wed, 3 Jun 2009 02:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RilOz+BDNqhH for ; Wed, 3 Jun 2009 02:40:12 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 5887C3A6452 for ; Wed, 3 Jun 2009 02:40:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,297,1241409600"; d="txt'?scan'208,217";a="172768845" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jun 2009 05:40:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Jun 2009 05:40:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9E42F.4AAB4357" Date: Wed, 3 Jun 2009 11:40:11 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 Thread-Index: AcnkLwbnJkbCBpPSQ9SVbHKJ42MA2wAADaoA From: "Romascanu, Dan (Dan)" To: Cc: Bernard Aboba Subject: [dns-dir] FW: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:40:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E42F.4AAB4357 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9E42F.4AAB4357" ------_=_NextPart_002_01C9E42F.4AAB4357 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, June 03, 2009 12:38 PM To: Alan DeKok; secdir-secretary@mit.edu; raft-ietf-dnsext-dnsproxy.all@tools.ietf.org; aaa-doctors@ietf.org Subject: Re: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 =09 =09 There are also some pretty nasty effects on multi-homed hosts who may send DNS queries on multiple interfaces, including the "WiFi hotspot" interface.=20 =09 This can result in a user who has a perfectly serviceable alternative connection (e.g. Ethernet, HSDPA, etc.) being unable to resolve names because their WiFi hotspot has decided to (quickly) return a synthesized (bogus)=20 answer to every query.=20 =09 The load of support calls this can create is so large that the practice of forbidding multi-homing (via use of suitably configured connection managers) has become quite common place. =20 =09 =09 > Date: Sat, 30 May 2009 09:31:08 +0200 > From: aland@deployingradius.com > To: secdir-secretary@mit.edu; raft-ietf-dnsext-dnsproxy.all@tools.ietf.org; aaa-doctors@ietf.org > Subject: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Over all, the document appears to be clear. >=20 >=20 > I wonder about the following text in section 4.5, however: >=20 > NB: any DNS proxy (such as those commonly found in WiFi hotspot > "walled gardens") which transparently intercepts all DNS queries, and > which returns unsigned responses to signed queries, will also cause > TSIG authentication failures. >=20 >=20 > The problem with WiFi hotspot DNS proxies is much, much, worse than > this simple paragraph would suggest. There are issues found in in those > deployments that are not discussed in this document. I will summarize > them here: >=20 >=20 > Issue: responding to all DNS requests with the IP of the hotspot >=20 > Goal: to guide all client traffic to the hotspot >=20 > Background: Many client machines have VPN software that checks for the > existence of "internal" corporate DNS names. If the names resolve, the > client is assumed to be "within" the corporate network. If the name > does not resolve, the client is assumed to be elsewhere, and the VPN > software behaves differently. DNS proxies that return an answer for all > names result in the client erroneously believing it is in the "internal" > network. Various things then fail in weird and wonderful ways. >=20 > Even when VPN software doesn't exist, this practice can cause other > problems. A commonly used web browser (I.E. from a major vendor) can > cache the results of DNS queries at the application layer. This > information is cached even across DHCP lease assignments from a new > subnet, where DNS caches are usually flushed. The result is that the > web browser cannot view the first web page that the user tries to visit. > The captive portal page is always shown instead. >=20 > Suggestion: DNS proxies MUST NOT respond with an answer if the name is > not resolvable. DNS proxies MUST NOT synthesize an answer. >=20 >=20 > Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1) >=20 > Goal: to catch *different* kinds of traffic than the previous issue > (this is no explanation, I've never had one explained to me in a way I > understand) >=20 > Background: Some proxies return synthetic responses with "fake" IP > addresses. While 1.1.1.1 is not currently allocated, it may be in the > future. Using it is a bad choice. In fact, this whole practice is > completely wtong. >=20 > Suggestion: Same as above. DNS proxies MUST NOT synthesize an answer. >=20 >=20 > The above suggestions might be a little strong. There are valid cases > where a proxy inside of a corporate network might need to synthesize > incorrect answers. These situations are better described as "internal > corporate policy". i.e. Notwithstanding the suggestions above, if you > want to break your own network, there are often valid reasons for doing so. >=20 > Alan DeKok. > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors =09 ------_=_NextPart_002_01C9E42F.4AAB4357 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: aaa-doctors-bounces@ietf.org = [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Wednesday, June 03, 2009 12:38 PM
To: = Alan=20 DeKok; secdir-secretary@mit.edu; = raft-ietf-dnsext-dnsproxy.all@tools.ietf.org;=20 aaa-doctors@ietf.org
Subject: Re: [AAA-DOCTORS] Secdir = review of=20 draft-ietf-dnsext-dnsproxy-05

There are also some pretty  nasty effects on = multi-homed hosts=20 who may send DNS queries on
multiple interfaces, including the = "WiFi=20 hotspot" interface.

This can result in a user who has a = perfectly=20 serviceable alternative connection (e.g. Ethernet, HSDPA, = etc.)
being=20 unable to resolve names because their WiFi hotspot has decided to = (quickly)=20 return a synthesized (bogus)
answer to every query.

The = load of=20 support calls this can create is so large that the practice of = forbidding=20 multi-homing (via use of
suitably configured connection managers) = has=20 become quite common place.  


> Date: Sat, 30 May = 2009=20 09:31:08 +0200
> From: aland@deployingradius.com
> To:=20 secdir-secretary@mit.edu; = raft-ietf-dnsext-dnsproxy.all@tools.ietf.org;=20 aaa-doctors@ietf.org
> Subject: [AAA-DOCTORS] Secdir review of=20 draft-ietf-dnsext-dnsproxy-05
>
> I have reviewed this = document=20 as part of the security directorate's
> ongoing effort to review = all=20 IETF documents being processed by the
> IESG. These comments = were=20 written primarily for the benefit of the
> security area = directors.=20 Document editors and WG chairs should treat
> these comments = just like=20 any other last call comments.
>
> Over all, the document = appears=20 to be clear.
>
>
> I wonder about the following = text in=20 section 4.5, however:
>
> NB: any DNS proxy (such as = those=20 commonly found in WiFi hotspot
> "walled gardens") which = transparently=20 intercepts all DNS queries, and
> which returns unsigned = responses to=20 signed queries, will also cause
> TSIG authentication = failures.
>=20
>
> The problem with WiFi hotspot DNS proxies is much, = much,=20 worse than
> this simple paragraph would suggest. There are = issues found=20 in in those
> deployments that are not discussed in this = document. I=20 will summarize
> them here:
>
>
> Issue: = responding=20 to all DNS requests with the IP of the hotspot
>
> Goal: = to guide=20 all client traffic to the hotspot
>
> Background: Many = client=20 machines have VPN software that checks for the
> existence of = "internal"=20 corporate DNS names. If the names resolve, the
> client is = assumed to be=20 "within" the corporate network. If the name
> does not resolve, = the=20 client is assumed to be elsewhere, and the VPN
> software = behaves=20 differently. DNS proxies that return an answer for all
> names = result in=20 the client erroneously believing it is in the "internal"
> = network.=20 Various things then fail in weird and wonderful ways.
>
> = Even=20 when VPN software doesn't exist, this practice can cause other
> = problems. A commonly used web browser (I.E. from a major vendor) = can
>=20 cache the results of DNS queries at the application layer. = This
>=20 information is cached even across DHCP lease assignments from a = new
>=20 subnet, where DNS caches are usually flushed. The result is that = the
>=20 web browser cannot view the first web page that the user tries to=20 visit.
> The captive portal page is always shown = instead.
>=20
> Suggestion: DNS proxies MUST NOT respond with an answer if = the name=20 is
> not resolvable. DNS proxies MUST NOT synthesize an = answer.
>=20
>
> Issue: responding to all DNS requests with a fake IP = (commonly 1.1.1.1)
>
> Goal: to catch *different* kinds = of=20 traffic than the previous issue
> (this is no explanation, I've = never=20 had one explained to me in a way I
> understand)
> =
>=20 Background: Some proxies return synthetic responses with "fake" = IP
>=20 addresses. While 1.1.1.1 is not currently allocated, it may be in = the
>=20 future. Using it is a bad choice. In fact, this whole practice = is
>=20 completely wtong.
>
> Suggestion: Same as above. DNS = proxies MUST=20 NOT synthesize an answer.
>
>
> The above = suggestions=20 might be a little strong. There are valid cases
> where a proxy = inside=20 of a corporate network might need to synthesize
> incorrect = answers.=20 These situations are better described as "internal
> corporate = policy".=20 i.e. Notwithstanding the suggestions above, if you
> want to = break your=20 own network, there are often valid reasons for doing so.
> =
> Alan=20 DeKok.
> _______________________________________________
> = AAA-DOCTORS mailing list
> AAA-DOCTORS@ietf.org
>=20 = https://www.ietf.org/mailman/listinfo/aaa-doctors
= ------_=_NextPart_002_01C9E42F.4AAB4357-- ------_=_NextPart_001_01C9E42F.4AAB4357 Content-Type: text/plain; name="ATT16161509.txt" Content-Transfer-Encoding: base64 Content-Description: ATT16161509.txt Content-Disposition: inline; filename="ATT16161509.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFBQS1ET0NU T1JTIG1haWxpbmcgbGlzdA0KQUFBLURPQ1RPUlNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWFhLWRvY3RvcnMNCg== ------_=_NextPart_001_01C9E42F.4AAB4357-- From dromasca@avaya.com Wed Jun 3 02:44:05 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098643A6841 for ; Wed, 3 Jun 2009 02:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4TTRcCcd4CD for ; Wed, 3 Jun 2009 02:44:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 271553A6452 for ; Wed, 3 Jun 2009 02:44:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,297,1241409600"; d="scan'208";a="147511591" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Jun 2009 05:44:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Jun 2009 05:44:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jun 2009 11:43:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-enum-enumservices-guide (IANA Registrationof Enumservices: Guide, Template and IANA Considerations) to ProposedStandard Thread-Index: AcnkLmV0KPkB4UonTjKpXGNz7/spUgAAV0qA From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] FW: Last Call: draft-ietf-enum-enumservices-guide (IANA Registrationof Enumservices: Guide, Template and IANA Considerations) to ProposedStandard X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:44:05 -0000 Some DNS Consideration comments here from Pekka.=20 Dan -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Pekka Savola Sent: Wednesday, June 03, 2009 12:33 PM To: ietf@ietf.org Cc: enum-chairs@tools.ietf.org; draft-ietf-enum-enumservices-guide@tools.ietf.org Subject: Re: Last Call: draft-ietf-enum-enumservices-guide (IANA Registrationof Enumservices: Guide, Template and IANA Considerations) to ProposedStandard=20 On Tue, 26 May 2009, The IESG wrote: > - 'IANA Registration of Enumservices: Guide, Template and IANA > Considerations ' > 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 O&M 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.=20 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.=20 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 --------- 4.2.4. Data Type-Based Enumservice Class "Data Type" Enumservices typically refer to a specific data type or format, which may be addressed using one or more URI Schemes and protocols. It is RECOMMENDED to use a well known name of the data type or format as the Enumservice Type. Examples of such Enumservices include 'vpim' [RFC4238] and 'vCard' [RFC4969]. .. I would suggest replacing "vCard" with another example or removing it because it does not seem to conform to the RECOMMENDED all-lowercase representation. In Section 5.2: o Enumservice Subtype (): .. I understand that subtype can be empty. Does this mean it's unspecified and/or omitted? You should probably describe what to do in this case; the preamble in S 5.2 seems to indicate that all the following elements are mandatory -- if that's not the case, the mandatory or optional ones should be clearly marked. 6.4. Step 4: Submit Registration Document If the Registration Document is to be published as RFC, the normal IETF publication process applies (see [instructions2authors]), i.e. the Registration Document is submitted to the RFC Editor in the form of an Internet Draft. For Independent Submission the guidelines in Independent Submissions to the RFC Editor [RFC4846] apply. .. the second part in first sentence (after i.e.) is misleading. While that is the ultimate "submission", if IETF publication process is followed, the document needs to go through a working group or via AD-sponsored paths, and finally it will end up at the RFC-editor as an Internet-draft. It is not submitted to the RFC-editor directly. This occurs only when when independent submission to RFC-editor is used. Rewording seems necessary. (It seems both these choices are acceptable and the author can pick one.) 6.4. Step 4: Submit Registration Document For publications as RFC Steps 6 below does not apply. ... The Step 6 below does only apply in case the Registration Document is to be published in a specification other than RFC. .. unnecessary duplication, remove one of these? In 11.1.3: [I-D.hoeneisen-enum-enumservices-transition] updates the existing Enumservices into the new IANA Registration Template. .. replaced by draft-ietf-enum-enumservices-transition-00 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From ogud@ogud.com Wed Jun 3 10:59:46 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB793A69A4 for ; Wed, 3 Jun 2009 10:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4+zdzD8zlx1 for ; Wed, 3 Jun 2009 10:59:45 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3FBFC3A705B for ; Wed, 3 Jun 2009 10:59:05 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n53Hwtgh006324; Wed, 3 Jun 2009 13:58:55 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906031758.n53Hwtgh006324@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Jun 2009 13:58:44 -0400 To: "Romascanu, Dan (Dan)" , From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Cc: Bernard Aboba Subject: Re: [dns-dir] FW: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 17:59:46 -0000 Moral: DNS lies are a terrible idea. Olafur At 05:40 03/06/2009, Romascanu, Dan (Dan) wrote: > > > >---------- >From: aaa-doctors-bounces@ietf.org >[mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Bernard Aboba >Sent: Wednesday, June 03, 2009 12:38 PM >To: Alan DeKok; secdir-secretary@mit.edu; >raft-ietf-dnsext-dnsproxy.all@tools.ietf.org; aaa-doctors@ietf.org >Subject: Re: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 > >There are also some pretty nasty effects on multi-homed hosts who >may send DNS queries on >multiple interfaces, including the "WiFi hotspot" interface. > >This can result in a user who has a perfectly serviceable >alternative connection (e.g. Ethernet, HSDPA, etc.) >being unable to resolve names because their WiFi hotspot has decided >to (quickly) return a synthesized (bogus) >answer to every query. > >The load of support calls this can create is so large that the >practice of forbidding multi-homing (via use of >suitably configured connection managers) has become quite common place. > > > > Date: Sat, 30 May 2009 09:31:08 +0200 > > From: aland@deployingradius.com > > To: secdir-secretary@mit.edu; > raft-ietf-dnsext-dnsproxy.all@tools.ietf.org; aaa-doctors@ietf.org > > Subject: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > Over all, the document appears to be clear. > > > > > > I wonder about the following text in section 4.5, however: > > > > NB: any DNS proxy (such as those commonly found in WiFi hotspot > > "walled gardens") which transparently intercepts all DNS queries, and > > which returns unsigned responses to signed queries, will also cause > > TSIG authentication failures. > > > > > > The problem with WiFi hotspot DNS proxies is much, much, worse than > > this simple paragraph would suggest. There are issues found in in those > > deployments that are not discussed in this document. I will summarize > > them here: > > > > > > Issue: responding to all DNS requests with the IP of the hotspot > > > > Goal: to guide all client traffic to the hotspot > > > > Background: Many client machines have VPN software that checks for the > > existence of "internal" corporate DNS names. If the names resolve, the > > client is assumed to be "within" the corporate network. If the name > > does not resolve, the client is assumed to be elsewhere, and the VPN > > software behaves differently. DNS proxies that return an answer for all > > names result in the client erroneously believing it is in the "internal" > > network. Various things then fail in weird and wonderful ways. > > > > Even when VPN software doesn't exist, this practice can cause other > > problems. A commonly used web browser (I.E. from a major vendor) can > > cache the results of DNS queries at the application layer. This > > information is cached even across DHCP lease assignments from a new > > subnet, where DNS caches are usually flushed. The result is that the > > web browser cannot view the first web page that the user tries to visit. > > The captive portal page is always shown instead. > > > > Suggestion: DNS proxies MUST NOT respond with an answer if the name is > > not resolvable. DNS proxies MUST NOT synthesize an answer. > > > > > > Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1) > > > > Goal: to catch *different* kinds of traffic than the previous issue > > (this is no explanation, I've never had one explained to me in a way I > > understand) > > > > Background: Some proxies return synthetic responses with "fake" IP > > addresses. While 1.1.1.1 is not currently allocated, it may be in the > > future. Using it is a bad choice. In fact, this whole practice is > > completely wtong. > > > > Suggestion: Same as above. DNS proxies MUST NOT synthesize an answer. > > > > > > The above suggestions might be a little strong. There are valid cases > > where a proxy inside of a corporate network might need to synthesize > > incorrect answers. These situations are better described as "internal > > corporate policy". i.e. Notwithstanding the suggestions above, if you > > want to break your own network, there are often valid reasons for doing so. > > > > Alan DeKok. > > _______________________________________________ > > AAA-DOCTORS mailing list > > AAA-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/aaa-doctors > >_______________________________________________ >AAA-DOCTORS mailing list >AAA-DOCTORS@ietf.org >https://www.ietf.org/mailman/listinfo/aaa-doctors >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir From ogud@ogud.com Wed Jun 3 11:30:07 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22783A6E57 for ; Wed, 3 Jun 2009 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W39QeUMBRAh for ; Wed, 3 Jun 2009 11:30:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A94823A69A4 for ; Wed, 3 Jun 2009 11:30:06 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n53IU0B1006735 for ; Wed, 3 Jun 2009 14:30:06 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Wed, 3 Jun 2009 14:30:06 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090603_183006_065400.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-xmpp-3921bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 18:30:07 -0000 Count: 21 Network Working Group P. Saint-Andre Internet-Draft Cisco Obsoletes: 3921 (if approved) June 1, 2009 Intended status: Standards Track Expires: December 3, 2009 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence draft-ietf-xmpp-3921bis-00 Abstract This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with RFC 2779. This document obsoletes RFC 3921. From ogud@ogud.com Wed Jun 3 11:57:47 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8ED28C14C for ; Wed, 3 Jun 2009 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9ro+DbzChvq for ; Wed, 3 Jun 2009 11:57:46 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8454A3A6CBB for ; Wed, 3 Jun 2009 11:57:46 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n53IU7LX006750 for ; Wed, 3 Jun 2009 14:30:07 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Wed, 3 Jun 2009 14:30:07 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090603_183007_040862.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-xmpp-3920bis-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 18:57:47 -0000 Count: 61 Network Working Group P. Saint-Andre Internet-Draft Cisco Obsoletes: 3920 (if approved) June 1, 2009 Intended status: Standards Track Expires: December 3, 2009 Extensible Messaging and Presence Protocol (XMPP): Core draft-ietf-xmpp-3920bis-00 Abstract This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920. From ogud@ogud.com Thu Jun 4 11:30:11 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810AC3A707B for ; Thu, 4 Jun 2009 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7u1LNvaqNSY for ; Thu, 4 Jun 2009 11:30:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 775FE3A6F34 for ; Thu, 4 Jun 2009 11:30:10 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n54IU1p8008881 for ; Thu, 4 Jun 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 4 Jun 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090604_183001_042698.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-saintandre-tls-server-id-check-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 18:30:11 -0000 Count: 15 None P. Saint-Andre Internet-Draft Cisco Intended status: Standards Track K. Zeilenga Expires: December 5, 2009 Isode Limited J. Hodges NeuStar R. Morgan Internet2 June 3, 2009 Best Practices for Checking of Server Identities in the Context of Transport Layer Security (TLS) draft-saintandre-tls-server-id-check-00 Abstract This document specifies the how an entity establishing a TLS connection, or other PKI-based interaction, with a server should verify the server identity. From ogud@ogud.com Sat Jun 6 11:30:00 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725053A694D for ; Sat, 6 Jun 2009 11:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk1F2GNggxKZ for ; Sat, 6 Jun 2009 11:29:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9A3F13A6847 for ; Sat, 6 Jun 2009 11:29:59 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n56IU0Zd018197 for ; Sat, 6 Jun 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Sat, 6 Jun 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090606_183000_042540.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-blanchet-mif-problem-statement-01.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 18:30:00 -0000 Count: 15 Network Working Group M. Blanchet Ed. Internet-Draft Viagenie Intended status: Informational P. Seite Expires: December 7, 2009 France Telecom June 5, 2009 Multiple Interfaces Problem Statement draft-blanchet-mif-problem-statement-01.txt Abstract A multihomed host receives node configuration information from each of its access networks. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues. From dromasca@avaya.com Sun Jun 7 05:57:54 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645683A6BEA for ; Sun, 7 Jun 2009 05:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsAUGYIQIrGD for ; Sun, 7 Jun 2009 05:57:53 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 70AD53A6BE1 for ; Sun, 7 Jun 2009 05:57:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,319,1241409600"; d="scan'208";a="163558256" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 07 Jun 2009 08:57:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 07 Jun 2009 08:57:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Jun 2009 14:57:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-mipshop-mos-dns-discovery (Locating IEEE 802.21 Mobility Servers using DNS) to Proposed Standard Thread-Index: Acnl4xpgk9hsP+g4Su+JDcF5ovW5twBjG7ZA From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] FW: Last Call: draft-ietf-mipshop-mos-dns-discovery (Locating IEEE 802.21 Mobility Servers using DNS) to Proposed Standard X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 12:57:54 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 05, 2009 4:39 PM To: IETF-Announce Cc: mipshop@ietf.org Subject: Last Call: draft-ietf-mipshop-mos-dns-discovery (Locating IEEE 802.21 Mobility Servers using DNS) to Proposed Standard=20 The IESG has received a request from the Mobility for IP: Performance, Signaling and Handoff Optimization WG (mipshop) to consider the following document: - 'Locating IEEE 802.21 Mobility Servers using DNS ' 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 2009-06-19. 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-mipshop-mos-dns-discovery -06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 17213&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From peter@denic.de Sun Jun 7 11:25:46 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297EA3A6CEC for ; Sun, 7 Jun 2009 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRZChhoQ9sZV for ; Sun, 7 Jun 2009 11:25:45 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 5545F3A68DF for ; Sun, 7 Jun 2009 11:25:45 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1MDN40-0005sg-67; Sun, 07 Jun 2009 20:25:48 +0200 Received: from localhost by x27.adm.denic.de with local id 1MDN0O-0006Bd-I2; Sun, 07 Jun 2009 20:22:04 +0200 Date: Sun, 7 Jun 2009 20:22:04 +0200 From: Peter Koch To: IETF DNS Directorate Message-ID: <20090607182204.GB23478@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [dns-dir] 2009-06-08 DNS Directorate conf call X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 18:25:46 -0000 Dear DNS directorate members, following our rescheduling please find below the draft agenda for our next conf call, scheduled tomorrow, Monday, 2009-06-08, 1400 UTC Best regards, Peter ----------------------------------------------------------------------------- 2009-06-08 1400-1459 UTC ----------------------------------------------------------------------------- o Administrivia Mailing list status conf call schedule until Stockholm o DNSSEC strategy for the IETF "guidance" asked for by dnsext particpants GOST and DNSSEC and IETF [Olafur] operational (and other) consequences of multiple algorithms at the root o Role of DNS in service discovery o New DNSEXT charter o Recent draft reviews Alerts ----------------------------------------------------------------------------- From roy@dnss.ec Sun Jun 7 12:46:12 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BA93A6BE3 for ; Sun, 7 Jun 2009 12:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_FREE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDoBMfLiaL7K for ; Sun, 7 Jun 2009 12:46:12 -0700 (PDT) Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10]) by core3.amsl.com (Postfix) with ESMTP id DB3023A686D for ; Sun, 7 Jun 2009 12:46:11 -0700 (PDT) Received: from a82-94-105-57.adsl.xs4all.nl (a82-94-105-57.adsl.xs4all.nl [82.94.105.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by mail.schlyter.se (Postfix) with ESMTPSA id 0A6452D587; Sun, 7 Jun 2009 21:46:12 +0200 (MEST) Message-Id: From: Roy Arends To: IETF DNS Directorate In-Reply-To: <20090607182204.GB23478@x27.adm.denic.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 7 Jun 2009 21:46:12 +0200 References: <20090607182204.GB23478@x27.adm.denic.de> X-Mailer: Apple Mail (2.935.3) Subject: [dns-dir] 2009-06-08 DNS Directorate conf call logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 19:46:12 -0000 On Jun 7, 2009, at 8:22 PM, Peter Koch wrote: > Dear DNS directorate members, > > following our rescheduling please find below the draft agenda for our > next conf call, scheduled > > tomorrow, Monday, 2009-06-08, 1400 UTC Hi all, this time, we can use Nominets conference call accounts again. I'm currently working 50% and on the road to full recovery, after almost 4 months of absence. US (east) +1 7183541169 US (west) +1 4089616553 NL +31 202013852 UK +44 2078193600 FR +33 171230055 SE +46 858536827 CA 18667425608 FI +358 969379595 DE +49 6950070811 Conference Code: 4227104 Let me know asap if your country is not listed. Kind regards, Roy Arends From rdroms@cisco.com Mon Jun 8 07:02:02 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6639E3A6B4B for ; Mon, 8 Jun 2009 07:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_FREE=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCEGuBOfVKgd for ; Mon, 8 Jun 2009 07:02:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8BDEF3A6848 for ; Mon, 8 Jun 2009 07:02:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241395200"; d="scan'208";a="167934684" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2009 14:02:06 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n58E26Z7022062; Mon, 8 Jun 2009 10:02:06 -0400 Received: from [161.44.65.104] ([161.44.65.104]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n58E26IQ009734; Mon, 8 Jun 2009 14:02:06 GMT Message-Id: <7225BA61-BE82-4D1D-B6A2-AB02852F61F0@cisco.com> From: Ralph Droms To: Roy Arends In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 8 Jun 2009 10:02:06 -0400 References: <20090607182204.GB23478@x27.adm.denic.de> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1013; t=1244469726; x=1245333726; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dns-dir]=202009-06-08=20DNS=20Director ate=20conf=20call=20logistics |Sender:=20 |To:=20Roy=20Arends=20; bh=Sqprazu7FJMhjKqVvoqPHL5ThjPCtunK1WSdELv+dzw=; b=haZz/iIrGYG9GejXEc+L1sFtDJbGC4s3atWaSGVTXwPjcpOLNCWAgu40JS FJ73TmRpXZ7Qls//FEgydtz1pwv+qukcId3Wy+wbyg/Ts07YXAWBb1uPBlR6 k34VEz8wP3; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF DNS Directorate Subject: Re: [dns-dir] 2009-06-08 DNS Directorate conf call logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:02:02 -0000 Conf account phone numbers aren't working for me. - Ralph On Jun 7, 2009, at 3:46 PM 6/7/09, Roy Arends wrote: > On Jun 7, 2009, at 8:22 PM, Peter Koch wrote: > >> Dear DNS directorate members, >> >> following our rescheduling please find below the draft agenda for our >> next conf call, scheduled >> >> tomorrow, Monday, 2009-06-08, 1400 UTC > > Hi all, this time, we can use Nominets conference call accounts > again. I'm currently working 50% and on the road to full recovery, > after almost 4 months of absence. > > US (east) +1 7183541169 > US (west) +1 4089616553 > NL +31 202013852 > UK +44 2078193600 > FR +33 171230055 > SE +46 858536827 > CA 18667425608 > FI +358 969379595 > DE +49 6950070811 > > Conference Code: 4227104 > > Let me know asap if your country is not listed. > > Kind regards, > > Roy Arends > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From rdroms@cisco.com Mon Jun 8 07:06:57 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183F33A6B83 for ; Mon, 8 Jun 2009 07:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.219 X-Spam-Level: X-Spam-Status: No, score=-5.219 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, MANGLED_FREE=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGnMZ-2a6r3F for ; Mon, 8 Jun 2009 07:06:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A69053A6ADC for ; Mon, 8 Jun 2009 07:06:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241395200"; d="scan'208";a="173595339" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2009 14:07:00 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n58E70EA026508; Mon, 8 Jun 2009 10:07:00 -0400 Received: from [161.44.65.104] ([161.44.65.104]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n58E70Gn006145; Mon, 8 Jun 2009 14:07:00 GMT Message-Id: From: Ralph Droms To: Ralph Droms In-Reply-To: <7225BA61-BE82-4D1D-B6A2-AB02852F61F0@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 8 Jun 2009 10:07:00 -0400 References: <20090607182204.GB23478@x27.adm.denic.de> <7225BA61-BE82-4D1D-B6A2-AB02852F61F0@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1326; t=1244470020; x=1245334020; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dns-dir]=202009-06-08=20DNS=20Director ate=20conf=20call=20logistics |Sender:=20 |To:=20Ralph=20Droms=20; bh=5MzZ+j65NvNd4zuZZd7P8GZtl2mkE1xD88RyqmV/R/U=; b=S/ZflZJF7dkKDvsESEOzNfZnnfwA8FGx20qZOPT+uZMAkovvl/6nft1A+b iVCxTgukGRwK3DzEU22wRoLw48HJMOhVsbvftUKas14R9bVClsu6CFtkigJz QsPQvUQush; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: IETF DNS Directorate Subject: Re: [dns-dir] 2009-06-08 DNS Directorate conf call logistics X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:06:57 -0000 Never mind; I got through on my cell phone. - Ralph On Jun 8, 2009, at 10:02 AM 6/8/09, Ralph Droms wrote: > Conf account phone numbers aren't working for me. > > - Ralph > > On Jun 7, 2009, at 3:46 PM 6/7/09, Roy Arends wrote: > >> On Jun 7, 2009, at 8:22 PM, Peter Koch wrote: >> >>> Dear DNS directorate members, >>> >>> following our rescheduling please find below the draft agenda for >>> our >>> next conf call, scheduled >>> >>> tomorrow, Monday, 2009-06-08, 1400 UTC >> >> Hi all, this time, we can use Nominets conference call accounts >> again. I'm currently working 50% and on the road to full recovery, >> after almost 4 months of absence. >> >> US (east) +1 7183541169 >> US (west) +1 4089616553 >> NL +31 202013852 >> UK +44 2078193600 >> FR +33 171230055 >> SE +46 858536827 >> CA 18667425608 >> FI +358 969379595 >> DE +49 6950070811 >> >> Conference Code: 4227104 >> >> Let me know asap if your country is not listed. >> >> Kind regards, >> >> Roy Arends >> _______________________________________________ >> dns-dir mailing list >> dns-dir@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-dir > > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From dromasca@avaya.com Fri Jun 12 06:01:18 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096A63A6DFD; Fri, 12 Jun 2009 06:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBeFsuQHb-L4; Fri, 12 Jun 2009 06:01:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C687E3A65A5; Fri, 12 Jun 2009 06:01:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,209,1243828800"; d="scan'208";a="148396231" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jun 2009 09:01:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Jun 2009 09:01:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 15:01:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for June 18, 2009 Telechat Thread-Index: AcnrWhkye5L9ggO/S8eBCXjOCmJwQgAAxjdg From: "Romascanu, Dan (Dan)" To: , , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for June 18, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:01:18 -0000 Please find below the preliminary agenda of the IESG telechat on 6/18. Please send my your comments and questions related to the documents brought for approval and for the proposed WG charters before 6/17 COB.=20 Thanks and Regards, Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-rmt-pi-norm-revised-13.txt NACK-Oriented Reliable Multicast Transport Protocol (Proposed Standard) - 1=20 of 4=20 Note: Document Shepherd: Lorenzo Vicisano =20 Token: Magnus Westerlund o draft-ietf-ltru-4646bis-23.txt Tags for Identifying Languages (BCP) - 2 of 4=20 Note: Martin Drst is the document shepherd..=20 Token: Alexey Melnikov o draft-ietf-ltans-dssc-08.txt Data Structure for the Security Suitability of Cryptographic Algorithms=20 (DSSC) (Proposed Standard) - 3 of 4=20 Token: Tim Polk o draft-ietf-ippm-more-twamp-02.txt More Features for the Two-Way Active Measurement Protocol - TWAMP (Proposed=20 Standard) - 4 of 4=20 Token: Lars Eggert 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-sipping-cc-framework-11.txt A Call Control and Multi-party usage framework for the Session Initiation=20 Protocol (SIP) (Informational) - 1 of 5=20 Token: Cullen Jennings o draft-ietf-ntp-autokey-05.txt Network Time Protocol Version 4 Autokey Specification (Informational) - 2=20 of 5=20 Token: Ralph Droms o draft-ietf-pce-p2mp-app-01.txt Applicability of the Path Computation Element (PCE) to Point-to-Multipoint=20 (P2MP) Multiprotocol Label Switching (MPLS)and Generalized MPLS (GMPLS)=20 Traffic Engineering (TE) (Informational) - 3 of 5=20 Token: Ross Callon o draft-ietf-ltru-4645bis-10.txt Update to the Language Subtag Registry (Informational) - 4 of 5=20 Note: Please read 4646bis before reviewing this document.. Martin Drst is=20 the document shepherd. This document, as a draft, includes 'bis' in its=20 name because it is a second version of RFC 4645. However, it is not a direct update of RFC 4645. RFC 4645 served to initialize the Language =20 Subtag Registry (http://www.iana.org/assignments/language-subtag-registry).=20 This document re-initializes the Language Subtag Registry based on the =20 initial state of the registry from RFC 4645, the updates to the registry=20 made in the meantime, and the additions and changes made by the work on=20 4646bis (which is a true update of RFC 4646)..=20 Token: Alexey Melnikov o draft-ietf-opsec-blackhole-urpf-04.txt Remote Triggered Black Hole filtering with uRPF (Informational) - 5 of 5=20 Token: Ron Bonica 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-sinnreich-sip-tools-06.txt Simple SIP Usage Scenario for Applications in the Endpoints (Informational)=20 - 1 of 3=20 Note: Mary is Proto Shepherd.=20 Token: Cullen Jennings o draft-eronen-enterprise-number-documentation-01.txt Enterprise Number for Documentation Use (Informational) - 2 of 3=20 Token: Dan Romascanu o draft-housley-aes-key-wrap-with-pad-02.txt Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm=20 (Informational) - 3 of 3=20 Token: Tim Polk 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-irtf-mobopts-location-privacy-solutions-13.txt Mobile IPv6 Location Privacy Solutions (Experimental) - 1 of 1=20 Note: The document shepherd is Basavaraj Patil=20 =20 Token: Jari Arkko 3.3.2 Returning Item o draft-ford-behave-top-06.txt Unintended Consequence of two NAT deployments with Overlapping Address =20 Space (Informational) - 1 of 2=20 Token: Magnus Westerlund o draft-floyd-tcpm-ackcc-05.txt Adding Acknowledgement Congestion Control to TCP (Informational) - 2 of 2=20 Token: Lars Eggert 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Diameter Maintenance and Extensions (dime) - 1 of 2 Token: Dan Romascanu o Integrated Security Model for SNMP (isms) - 2 of 2 Token: Pasi Eronen 4.2.2 Proposed for Approval o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 2 Token: Magnus Westerlund o Geographic Location/Privacy (geopriv) - 2 of 2 Token: Cullen Jennings From ogud@ogud.com Sun Jun 14 11:29:53 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10813A6878 for ; Sun, 14 Jun 2009 11:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3-vbjrMGE9r for ; Sun, 14 Jun 2009 11:29:53 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 150CA3A6407 for ; Sun, 14 Jun 2009 11:29:52 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5EIU0iB020844 for ; Sun, 14 Jun 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Sun, 14 Jun 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090614_183000_059458.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-gudmundsson-dnsext-setting-ends0-do-bit-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 18:29:54 -0000 Count: 52 Intended Status: Standard Track O. Gudmundsson Network Working Group Shinkuro, Inc. Internet-Draft June 13, 2009 Updates: 4035 (if approved) Intended status: Standards Track Expires: December 15, 2009 DNSSEC OK buffer minimum size requirment and error handling draft-gudmundsson-dnsext-setting-ends0-do-bit-00 Abstract RFC3226 mandated support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or IPv6 address records. This requirement was motivated because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. From dromasca@avaya.com Mon Jun 15 00:21:16 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774AC28C0FC for ; Mon, 15 Jun 2009 00:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCRmaDqFkjj1 for ; Mon, 15 Jun 2009 00:21:12 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4B4443A6C1F for ; Mon, 15 Jun 2009 00:21:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,220,1243828800"; d="txt'?scan'208,217";a="148533773" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2009 03:21:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jun 2009 03:21:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9ED89.C8FAA05F" Date: Mon, 15 Jun 2009 09:20:38 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [drinks] request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAKBYJA From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] FW: [drinks] request for input X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 07:21:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ED89.C8FAA05F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9ED89.C8FAA05F" ------_=_NextPart_002_01C9ED89.C8FAA05F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Monday, June 15, 2009 5:37 AM To: drinks@ietf.org Subject: [drinks] request for input =09 =09 The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. =20 Thank you. Please reply to the list. =20 =20 ------_=_NextPart_002_01C9ED89.C8FAA05F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: drinks-bounces@ietf.org=20 [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah=20 A
Sent: Monday, June 15, 2009 5:37 AM
To:=20 drinks@ietf.org
Subject: [drinks] request for=20 input

The protocol design team has been working on a = data model=20 and protocol for the registry provisioning interface.

We have associated with each public identifier = routing=20 information in the form of resolution answers on the name = server. =20 Initially we looked at specific types of routing info – such as = NS and NAPTR=20 Resource Records. We have heard feedback that this is too DNS-centric. = We are=20 discussing collapsing these into a “generic” Route Object. = This may lead to a=20 long set of attributes, one would be route type, but many others would = be=20 optional and may only apply to a given route type.

We would appreciate some feedback –does it = make sense to=20 collapse into a generic Route Object? Other suggestions are=20 welcome.

 

Thank you. Please reply to the = list.

 

 

------_=_NextPart_002_01C9ED89.C8FAA05F-- ------_=_NextPart_001_01C9ED89.C8FAA05F Content-Type: text/plain; name="ATT18853855.txt" Content-Transfer-Encoding: base64 Content-Description: ATT18853855.txt Content-Disposition: inline; filename="ATT18853855.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRyaW5rcyBt YWlsaW5nIGxpc3QNCmRyaW5rc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kcmlua3MNCg== ------_=_NextPart_001_01C9ED89.C8FAA05F-- From ogud@ogud.com Mon Jun 15 11:29:55 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC4F3A68A9 for ; Mon, 15 Jun 2009 11:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrGzx9zVn-IP for ; Mon, 15 Jun 2009 11:29:55 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id F3F9F3A682A for ; Mon, 15 Jun 2009 11:29:54 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5FIU13P011211 for ; Mon, 15 Jun 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 15 Jun 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090615_183001_007078.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-bcx-behave-learn-address-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:29:55 -0000 Count: 15 Network Working Group C. Bao Internet-Draft X. Li Intended status: Informational CERNET Center/Tsinghua University Expires: December 17, 2009 June 15, 2009 How Host A learns the IP address of Host B draft-bcx-behave-learn-address-00 Abstract This document describes how host A learns the IP address of host B in BEHAVE's "An IPv6 network to the IPv4 Internet" scenario. In this scenario, an IPv6-only host A must know the IPv6 address representation of host B. From dromasca@avaya.com Wed Jun 24 01:36:51 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C3B3A6F30; Wed, 24 Jun 2009 01:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME7fYJJK1oHW; Wed, 24 Jun 2009 01:36:50 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 14EBE28C420; Wed, 24 Jun 2009 01:36:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,281,1243828800"; d="scan'208";a="165227582" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Jun 2009 04:37:06 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jun 2009 04:37:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 10:37:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Site Multihoming by IPv6 Intermediation (shim6) thread-index: Acn0QYfWiOwp43QRSaCNN9sbkS73KQAZWMPw From: "Romascanu, Dan (Dan)" To: , "Ops Directorate" , Subject: [dns-dir] FW: WG Review: Recharter of Site Multihoming by IPv6 Intermediation (shim6) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:36:51 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 23, 2009 11:30 PM To: new-work@ietf.org Subject: WG Review: Recharter of Site Multihoming by IPv6 Intermediation (shim6)=20 A modified charter has been submitted for the Site Multihoming by IPv6 Intermediation (shim6) working group in the Internet Area of the IETF.=20 The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. Site Multihoming by IPv6 Intermediation (shim6) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2009-06-17 Current Status: Active Working Group=20 Additional information is available at tools.ietf.org/wg/shim6 Chair(s): Kurt Lindqvist Geoff Huston=20 Internet Area Director(s): Ralph Droms Jari Arkko=20 Internet Area Advisor: Jari Arkko=20 Technical Advisor(s): Thomas Narten=20 Mailing Lists: General Discussion: shim6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/shim6 Archive: http://www.ietf.org/mail-archive/web/shim6/current/maillist.html Description of Working Group: Earlier efforts in this working group completed the Shim6 protocol specification, documented in RFCs 5533 through 5535. This protocol is a layer 3 shim for providing locator agility with failover capabilities for IPv6 nodes. Hosts that employ Shim6 use multiple IPv6 address prefixes and setup state with peer hosts. This state can later be used to failover to a different set of locators, should the original locators stop working. The Shim6 approach has a number of advantages, such as enabling small sites to be multihomed without requiring a provider independent IPv6 address prefix for the site. But the approach has also been criticized, e.g., for the operational impacts that the use of multiple prefixes causes. At this time there is no clear view on how well Shim6 works in practice. Implementation and deployment in select networks is needed to determine its true characteristics. The Shim6 working group is chartered to track the implementation and testing or deployment efforts. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications. The specific work items of the group are: o Write an implementation and/or deployment experience report. o Specify socket API extensions. This API enables interactions between applications and the Shim6 layer for advanced locator management, and access to information about failure detection and path exploration. It also enables some applications to turn Shim6 off. o Complete the work on the applicability draft. This draft explains in detail in which types of networks Shim6 is applicable, and what its advantages and disadvantages are. The draft will also explain how firewalls are impacted by the use of Shim6. Finally, the draft will also explain how Shim6 can be used in situations where native IPv6 connectivity is not available, such as using Shim6 over 6to4. The group will also work in co-operation with the 6MAN working group as they continue their efforts in improving IPv6 address selection mechanisms. The group shall not work on extensions to the Shim6 protocol itself at this time. However, new work items can be added through rechartering as others get completed. Goals and Milestones: Sep 2009 Next revision of the API document Nov 2009 First WG draft on an implementation report Jan 2010 Submit API document to IESG for publication as Informational RFC Jan 2010 Next revision of the applicability document Dec 2010 Submit implementation report to IESG for publication as Informational RFC Dec 2010 Submit applicability document to IESG for publication as Informational RFC Dec 2010 Close or re-charter From dromasca@avaya.com Wed Jun 24 01:37:01 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8AF3A6F00 for ; Wed, 24 Jun 2009 01:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnE3hpR--CKX for ; Wed, 24 Jun 2009 01:37:01 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id BE94B3A6A87 for ; Wed, 24 Jun 2009 01:37:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,281,1243828800"; d="scan'208";a="149418949" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jun 2009 04:37:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jun 2009 04:37:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 10:37:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions (dime) thread-index: Acn0QZAzKLyt0PQESK+jepaxbrJJhAAZWTIQ From: "Romascanu, Dan (Dan)" To: Subject: [dns-dir] FW: WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:37:01 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 23, 2009 11:30 PM To: new-work@ietf.org Subject: WG Review: Recharter of Diameter Maintenance and Extensions (dime)=20 A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. Diameter Maintenance and Extensions (dime) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2009-06-10 Current Status: Working Group Chair(s): Hannes Tschofenig Victor Fajardo=20 Operations and Management Area Director(s): Dan Romascanu Ronald Bonica=20 Operations and Management Area Advisor: Dan Romascanu=20 Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done Submit 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Nov 2009 Submit 'Revision of Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Aug 2009 Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Jun 2009 Submit new DIME charter to the IESG Jun 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Nov 2009 Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard From dromasca@avaya.com Wed Jun 24 01:49:36 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37EAC3A6963; Wed, 24 Jun 2009 01:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyzjPnbLK942; Wed, 24 Jun 2009 01:49:35 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id BCDF13A682D; Wed, 24 Jun 2009 01:49:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,282,1243828800"; d="scan'208";a="165228639" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Jun 2009 04:49:50 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Jun 2009 04:49:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 10:49:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: STORage Maintenance (storm) thread-index: Acn0PVLxg4O1hYVdRfa+pHaS+KtelwAa11NA From: "Romascanu, Dan (Dan)" To: "Ops Directorate" , , Subject: [dns-dir] FW: WG Review: STORage Maintenance (storm) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:49:36 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 23, 2009 11:00 PM To: ietf-announce@ietf.org Cc: storm@ietf.org Subject: WG Review: STORage Maintenance (storm)=20 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. STORage Maintenance (storm) ---------------------------------- Last Modified: 2009-06-18 Current Status: Proposed Working Group Chairs: - TBD=20 Transport Area Director(s): - Magnus Westerlund - Lars Eggert Transport Area Advisor: - Lars Eggert Mailing Lists: General Discussion: storm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/storm Archive: http://www.ietf.org/mail-archive/web/storm/index.html Description of Working Group: The IETF ips (IP Storage) and rddp (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, making backwards compatibility with existing implementations a requirement for all protocol changes and additions. This is a requirement for implementation compatibility - if all implementations of a protocol have done something different than what the RFC specified, then it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unimplemented original behavior. Initial list of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but it is up to the WG to decide whether to advance it to Draft Standard. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but that allocated number is not used by FCIP. The working group will consider whether that allocated number should be returned to IANA for future reallocation. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with it as specified in RFC 4172, and moreover, only the Address Transparent mode of iFCP is in use. This change is to be done via a short draft that updates RFC 4172, as opposed to a complete rewrite of RFC 4172. A combined draft is expected that encompasses items (3) and (4); this draft should also update the iFCP MIB (RFC 4369) to deprecate support for iFCP Address Translation mode. (5) RDDP Connection Setup: Good support for MPI applications requires a small update to MPA startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggests a few minor updates to reflect what has been done in practice. The working group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Goals and Milestones: July 2009 First version of FCIP protocol number and iFCP Address Translation mode draft. Aug 2009 First version of iSCSI SAM-4 (and other) new features draft. Aug 2009 First version of RDDP MPA startup change draft Sep 2009 Working Group Last Call on FCIP protocol number and iFCP address change draft Sep 2009 First version of combined iSCSI draft (3720bis) Oct 2009 First version of iSER update draft Oct 2009 Working Group Last Call on RDDP MPA startup change draft. Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features draft, plus iSCSI MIB update draft. Feb 2010 Working Group Last Call on iSER update draft Mar 2010 Working Group Last Call on iSCSI SAM-4 (and other) new features draft. Apr 2010 Working Group decision on whether to seek Draft Standard RFC status for the combined iSCSI draft (3720bis). [Note: decision may be made significantly before this date.] Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) and iSCSI MIB update draft. From dromasca@avaya.com Thu Jun 25 23:05:33 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1B63A6890; Thu, 25 Jun 2009 23:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro1I3PGy4SWQ; Thu, 25 Jun 2009 23:05:32 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 24DC23A67DF; Thu, 25 Jun 2009 23:05:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,294,1243828800"; d="scan'208";a="175159817" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Jun 2009 02:05:49 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jun 2009 02:05:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 08:05:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for July 2, 2009 Telechat thread-index: Acn15pHq058PO0HKRmCPjjRa2W/jdQAPTQ4g From: "Romascanu, Dan (Dan)" To: , , , "Ops Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for July 2, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 06:05:34 -0000 Please find below the preliminary agenda of the 7/2 IESG telechat. Please send me all comments, questions and concerns before 7/1 COB.=20 Thanks and Regards, Dan =20 2.1 WG Submissions 2.1.1 New Item o draft-ietf-avt-rtcpssm-18.txt RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback=20 (Proposed Standard) - 1 of 12=20 Token: Cullen Jennings o draft-ietf-tcpm-rfc2581bis-05.txt TCP Congestion Control (Draft Standard) - 2 of 12=20 Note: Document Shepherd: Wesley Eddy (wesley.m.eddy@nasa.gov). Interop =20 Report: http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html=20 Token: Lars Eggert o draft-ietf-adslmib-vdsl2-07.txt Definitions of Managed Objects for Very High Speed Digital Subscriber Line=20 2 (VDSL2) (Proposed Standard) - 3 of 12=20 Token: Dan Romascanu o draft-ietf-mipshop-mos-dns-discovery-06.txt Locating IEEE 802.21 Mobility Servers using DNS (Proposed Standard) - 4 of=20 12=20 Note: Document shepherd is Vijay Devarapalli =20 Token: Jari Arkko o draft-ietf-avt-rtp-mps-02.txt RTP Payload Format for Elementary Streams with MPEG Surround multi- channel=20 audio (Proposed Standard) - 5 of 12=20 Token: Cullen Jennings o draft-ietf-dime-qos-attributes-12.txt Quality of Service Attributes for Diameter (Proposed Standard) - 6 of 12=20 Token: Dan Romascanu o draft-ietf-geopriv-civic-address-recommendations-02.txt Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA=20 Registry Definition (BCP) - 7 of 12=20 Token: Cullen Jennings o draft-ietf-sip-body-handling-06.txt Message Body Handling in the Session Initiation Protocol (SIP) (Proposed=20 Standard) - 8 of 12=20 Note: Theo Zourzouvillys is the document shepherd=20 Token: Robert Sparks o draft-ietf-ospf-dynamic-hostname-04.txt Dynamic Hostname Exchange Mechanism for OSPF (Proposed Standard) - 9 of 12=20 Token: Ross Callon o draft-ietf-l2tpext-circuit-status-extensions-04.txt L2TPv3 Extended Circuit Status Values (Proposed Standard) - 10 of 12 Note: Ignacio Goyret is the WG=20 shepherd. for this document..=20 Token: Ralph Droms o draft-ietf-sipcore-subnot-etags-02.txt An Extension to Session Initiation Protocol (SIP) Events for Conditional=20 Event Notification (Proposed Standard) - 11 of 12=20 Note: Dean Willis (dean.willis@softarmor.com) is document shepherd.=20 Token: Robert Sparks o draft-ietf-pwe3-vccv-bfd-05.txt Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit=20 Connectivity Verification (VCCV) (Proposed Standard) - 12 of 12=20 Token: Ralph Droms 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-dusseault-impl-reports-03.txt Guidance on Interoperation and Implementation Reports (BCP) - 1 of 2 Token: Tim Polk o draft-dawkins-nomcom-dont-wait-03.txt Nominating Committee Process: Earlier Announcement of Open Positions and=20 Solicitation of Volunteers (BCP) - 2 of 2=20 Token: Russ Housley 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-geopriv-l7-lcp-ps-09.txt GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and =20 Requirements (Informational) - 1 of 9=20 Token: Cullen Jennings o draft-ietf-pwe3-ms-pw-arch-06.txt An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge=20 (Informational) - 2 of 9=20 Note: David Sinicrope (david.sinicrope@ericsson.com) is the. =20 Document Shepherd for this document.=20 Token: Ralph Droms o draft-ietf-pce-inter-layer-frwk-10.txt Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering =20 (Informational) - 3 of 9=20 Token: Ross Callon o draft-ietf-opsec-blackhole-urpf-04.txt Remote Triggered Black Hole filtering with uRPF (Informational) - 4 of 9=20 Token: Ron Bonica o draft-ietf-dccp-ccid4-04.txt Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4:=20 TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental) - 5 of=20 9=20 Note: Document Shepherd: Pasi Sarolahti (pasi.sarolahti@iki.fi) [was Gorry=20 Fairhurst, but he's not a DCCP chair anymore]=20 Token: Lars Eggert o draft-ietf-smime-new-asn1-05.txt New ASN.1 Modules for CMS and S/MIME (Informational) - 6 of 9=20 Note: Sean Turner (turners@ieca.com) is the document shepherd.=20 Token: Tim Polk o draft-ietf-ancp-security-threats-07.txt Security Threats and Security Requirements for the Access Node Control =20 Protocol (ANCP) (Informational) - 7 of 9=20 Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document =20 shepherd.=20 Token: Ralph Droms o draft-ietf-dccp-quickstart-05.txt Quick-Start for Datagram Congestion Control Protocol (DCCP) (Experimental)=20 - 8 of 9=20 Note: Document shepherd is Pasi Sarolahti =20 Token: Lars Eggert o draft-ietf-pkix-tac-04.txt Traceable Anonymous Certificate (Experimental) - 9 of 9=20 Token: Tim Polk 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-livingood-woundy-p4p-experiences-10.txt Comcast's ISP Experiences In a P4P Technical Trial (Informational) - 1 of 1=20 Token: Lisa Dusseault 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-irtf-mobopts-location-privacy-solutions-15.txt Mobile IPv6 Location Privacy Solutions (Experimental) - 1 of 1=20 Note: The document shepherd is Basavaraj Patil=20 =20 Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o STORage Maintenance (storm) - 1 of 1 Token: Lars Eggert 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 3 Token: Magnus Westerlund o IP Flow Information Export (ipfix) - 2 of 3 Token: Dan Romascanu o DNS Extensions (dnsext) - 3 of 3 Token: Ralph Droms 4.2.2 Proposed for Approval o Site Multihoming by IPv6 Intermediation (shim6) - 1 of 3 Token: Jari Arkko o Diameter Maintenance and Extensions (dime) - 2 of 3 Token: Dan Romascanu o Integrated Security Model for SNMP (isms) - 3 of 3 Token: Pasi Eronen From dromasca@avaya.com Thu Jun 25 23:05:59 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796973A67E5; Thu, 25 Jun 2009 23:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCeSF3V8HzEg; Thu, 25 Jun 2009 23:05:58 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 68C523A67DF; Thu, 25 Jun 2009 23:05:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,294,1243828800"; d="scan'208";a="149653926" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jun 2009 02:06:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Jun 2009 02:06:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 08:05:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Integrated Security Model for SNMP (isms) thread-index: Acn15I3WITPoDzoTT1qN/I8FUTkbkwAP5NuQ From: "Romascanu, Dan (Dan)" To: "Ops Directorate" , , , Subject: [dns-dir] FW: WG Review: Recharter of Integrated Security Model for SNMP (isms) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 06:05:59 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Friday, June 26, 2009 1:30 AM To: new-work@ietf.org Subject: WG Review: Recharter of Integrated Security Model for SNMP (isms)=20 A modified charter has been submitted for the Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, July 2, 2009. Integrated Security Model for SNMP (isms) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2009-06-18 Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.ht ml Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG From ogud@ogud.com Fri Jun 26 04:51:13 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18B4F3A69FF for ; Fri, 26 Jun 2009 04:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSB5XMPsRS3s for ; Fri, 26 Jun 2009 04:51:11 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 4608B3A68ED for ; Fri, 26 Jun 2009 04:51:11 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5QBoiNS008150 for ; Fri, 26 Jun 2009 07:50:44 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906261150.n5QBoiNS008150@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Jun 2009 07:49:39 -0400 To: From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for July 2, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 11:51:13 -0000 Early-warning drafts please someone review and post a comment if the drafts need attention. tschofenig-geopriv-l7-lcp-ps 03 21 geopriv-l7-lcp-ps 00 21 mipshop-mos-dns-discovery 00 45 01 47 04 51 05 53 Olafur At 02:05 26/06/2009, Romascanu, Dan (Dan) wrote: >Please find below the preliminary agenda of the 7/2 IESG telechat. >Please send me all comments, questions and concerns before 7/1 COB. > >Thanks and Regards, > >Dan > > > >2.1 WG Submissions >2.1.1 New Item > o draft-ietf-avt-rtcpssm-18.txt > RTCP Extensions for Single-Source Multicast Sessions with Unicast >Feedback > (Proposed Standard) - 1 of 12 > Token: Cullen Jennings > o draft-ietf-tcpm-rfc2581bis-05.txt > TCP Congestion Control (Draft Standard) - 2 of 12 > Note: Document Shepherd: Wesley Eddy (wesley.m.eddy@nasa.gov). >Interop > > Report: >http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html > Token: Lars Eggert > o draft-ietf-adslmib-vdsl2-07.txt > Definitions of Managed Objects for Very High Speed Digital >Subscriber >Line > 2 (VDSL2) (Proposed Standard) - 3 of 12 > Token: Dan Romascanu > o draft-ietf-mipshop-mos-dns-discovery-06.txt > Locating IEEE 802.21 Mobility Servers using DNS (Proposed Standard) >- >4 of > 12 > Note: Document shepherd is Vijay Devarapalli > > Token: Jari Arkko > o draft-ietf-avt-rtp-mps-02.txt > RTP Payload Format for Elementary Streams with MPEG Surround multi- >channel > audio (Proposed Standard) - 5 of 12 > Token: Cullen Jennings > o draft-ietf-dime-qos-attributes-12.txt > Quality of Service Attributes for Diameter (Proposed Standard) - 6 >of >12 > Token: Dan Romascanu > o draft-ietf-geopriv-civic-address-recommendations-02.txt > Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA > Registry Definition (BCP) - 7 of 12 > Token: Cullen Jennings > o draft-ietf-sip-body-handling-06.txt > Message Body Handling in the Session Initiation Protocol (SIP) >(Proposed > Standard) - 8 of 12 > Note: Theo Zourzouvillys is the document shepherd > Token: Robert Sparks > o draft-ietf-ospf-dynamic-hostname-04.txt > Dynamic Hostname Exchange Mechanism for OSPF (Proposed Standard) - 9 >of 12 > Token: Ross Callon > o draft-ietf-l2tpext-circuit-status-extensions-04.txt > L2TPv3 Extended Circuit Status Values (Proposed Standard) - 10 of 12 > > Note: Ignacio Goyret is the >WG > shepherd. for this document.. > Token: Ralph Droms > o draft-ietf-sipcore-subnot-etags-02.txt > An Extension to Session Initiation Protocol (SIP) Events for >Conditional > Event Notification (Proposed Standard) - 11 of 12 > Note: Dean Willis (dean.willis@softarmor.com) is document shepherd. > Token: Robert Sparks > o draft-ietf-pwe3-vccv-bfd-05.txt > Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual >Circuit > Connectivity Verification (VCCV) (Proposed Standard) - 12 of 12 > Token: Ralph Droms > >2.1.2 Returning Item >NONE > >2.2 Individual Submissions >2.2.1 New Item > o draft-dusseault-impl-reports-03.txt > Guidance on Interoperation and Implementation Reports (BCP) - 1 of 2 > > Token: Tim Polk > o draft-dawkins-nomcom-dont-wait-03.txt > Nominating Committee Process: Earlier Announcement of Open Positions >and > Solicitation of Volunteers (BCP) - 2 of 2 > Token: Russ Housley > >2.2.2 Returning Item >NONE > >3. Document Actions > >3.1 WG Submissions > Reviews should focus on these questions: "Is this document a >reasonable > contribution to the area of Internet engineering which it >covers? If > not, what changes would make it so?" > >3.1.1 New Item > o draft-ietf-geopriv-l7-lcp-ps-09.txt > GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement >and > > Requirements (Informational) - 1 of 9 > Token: Cullen Jennings > o draft-ietf-pwe3-ms-pw-arch-06.txt > An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge > (Informational) - 2 of 9 > Note: David Sinicrope (david.sinicrope@ericsson.com) is the. > > Document Shepherd for this document. > Token: Ralph Droms > o draft-ietf-pce-inter-layer-frwk-10.txt > Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic >Engineering > > (Informational) - 3 of 9 > Token: Ross Callon > o draft-ietf-opsec-blackhole-urpf-04.txt > Remote Triggered Black Hole filtering with uRPF (Informational) - 4 >of >9 > Token: Ron Bonica > o draft-ietf-dccp-ccid4-04.txt > Profile for Datagram Congestion Control Protocol (DCCP) Congestion >ID >4: > TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental) >- >5 of > 9 > Note: Document Shepherd: Pasi Sarolahti (pasi.sarolahti@iki.fi) [was >Gorry > Fairhurst, but he's not a DCCP chair anymore] > Token: Lars Eggert > o draft-ietf-smime-new-asn1-05.txt > New ASN.1 Modules for CMS and S/MIME (Informational) - 6 of 9 > Note: Sean Turner (turners@ieca.com) is the document shepherd. > Token: Tim Polk > o draft-ietf-ancp-security-threats-07.txt > Security Threats and Security Requirements for the Access Node >Control > > Protocol (ANCP) (Informational) - 7 of 9 > Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the >document > > shepherd. > Token: Ralph Droms > o draft-ietf-dccp-quickstart-05.txt > Quick-Start for Datagram Congestion Control Protocol (DCCP) >(Experimental) > - 8 of 9 > Note: Document shepherd is Pasi Sarolahti > > Token: Lars Eggert > o draft-ietf-pkix-tac-04.txt > Traceable Anonymous Certificate (Experimental) - 9 of 9 > Token: Tim Polk > >3.1.2 Returning Item >NONE > >3.2 Individual Submissions Via AD > Reviews should focus on these questions: "Is this document a >reasonable > contribution to the area of Internet engineering which it >covers? If > not, what changes would make it so?" > >3.2.1 New Item > o draft-livingood-woundy-p4p-experiences-10.txt > Comcast's ISP Experiences In a P4P Technical Trial (Informational) - >1 >of 1 > Token: Lisa Dusseault > >3.2.2 Returning Item >NONE >3.3 Independent Submissions Via RFC Editor > The IESG will use RFC 3932 responses: 1) The IESG has not > found any conflict between this document and IETF work; 2) The > IESG thinks that this work is related to IETF work done in WG > , but this does not prevent publishing; 3) The IESG thinks > that publication is harmful to work in WG and recommends > not publishing at this time; 4) The IESG thinks that this > document violates the IETF procedures for and should > therefore not be published without IETF review and IESG > approval; 5) The IESG thinks that this document extends an > IETF protocol in a way that requires IETF review and should > therefore not be published without IETF review and IESG >approval. > > The document shepherd must propose one of these responses in > the Data Tracker note and supply complete text in the IESG > Note portion of the write-up. The Area Director ballot positions > indicate consensus with the response proposed by the > document shepherd. > > Other matters may be recorded in comments, and the comments will > be passed on to the RFC Editor as community review of the >document. > > >3.3.1 New Item >NONE >3.3.2 Returning Item > o draft-irtf-mobopts-location-privacy-solutions-15.txt > Mobile IPv6 Location Privacy Solutions (Experimental) - 1 of 1 > Note: The document shepherd is Basavaraj Patil > > Token: Jari Arkko > > >4. Working Group Actions >4.1 WG Creation >4.1.1 Proposed for IETF Review > NONE >4.1.2 Proposed for Approval > o STORage Maintenance (storm) - 1 of 1 > Token: Lars Eggert >4.2 WG Rechartering >4.2.1 Under evaluation for IETF Review > o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 3 > Token: Magnus Westerlund > o IP Flow Information Export (ipfix) - 2 of 3 > Token: Dan Romascanu > o DNS Extensions (dnsext) - 3 of 3 > Token: Ralph Droms >4.2.2 Proposed for Approval > o Site Multihoming by IPv6 Intermediation (shim6) - 1 of 3 > Token: Jari Arkko > o Diameter Maintenance and Extensions (dime) - 2 of 3 > Token: Dan Romascanu > o Integrated Security Model for SNMP (isms) - 3 of 3 > Token: Pasi Eronen > > > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir From ajs@shinkuro.com Fri Jun 26 06:41:16 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E0B3A6AD3 for ; Fri, 26 Jun 2009 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C82+W-xXtXM for ; Fri, 26 Jun 2009 06:41:16 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id F411D3A684F for ; Fri, 26 Jun 2009 06:41:15 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DE2FC2FE9664 for ; Fri, 26 Jun 2009 13:41:14 +0000 (UTC) Date: Fri, 26 Jun 2009 09:41:13 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090626134112.GA481@shinkuro.com> References: <200906261150.n5QBoiNS008150@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906261150.n5QBoiNS008150@stora.ogud.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for July 2, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 13:41:16 -0000 On Fri, Jun 26, 2009 at 07:49:39AM -0400, Olafur Gudmundsson wrote: > Early-warning drafts please someone review and post a comment if the drafts > need attention. > > tschofenig-geopriv-l7-lcp-ps 03 21 > geopriv-l7-lcp-ps 00 21 > mipshop-mos-dns-discovery 00 45 01 47 04 51 05 53 I will take one of these, and perform the review by Monday noon. Unless I hear otherwise by the end of today-ish, I'll pick the last one. If anyone prefers to read that one, please let me know. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Mon Jun 29 08:41:55 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793CA28C296 for ; Mon, 29 Jun 2009 08:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIt3Jvw9BiiK for ; Mon, 29 Jun 2009 08:41:54 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2EF2D28C12A for ; Mon, 29 Jun 2009 08:41:54 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A18502FE9664; Mon, 29 Jun 2009 15:42:13 +0000 (UTC) Date: Mon, 29 Jun 2009 11:42:11 -0400 From: Andrew Sullivan To: "Romascanu, Dan (Dan)" Message-ID: <20090629154211.GH1525@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: dns-dir@ietf.org Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for July 2, 2009 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:41:55 -0000 Dear colleagues, On Fri, Jun 26, 2009 at 08:05:29AM +0200, Romascanu, Dan (Dan) wrote: > o draft-ietf-mipshop-mos-dns-discovery-06.txt > Locating IEEE 802.21 Mobility Servers using DNS (Proposed Standard) I have read this document. I think it has received some previous DNS Directorate attention. I think the reason this document previously received some objections has to do with certain notions embedded in it. In particular, this passage stands out: When the MN needs to discover Mobility Services in its home domain, the input to the First Well Known Rule MUST be the MN's home domain, which is assumed to be pre-configured in the MN. I imagine the issue has really been this notion of a "home domain", and how it fits into the DNS (where it's either an entirely alien notion or one of the suffixes in the search path, depending on how you feel about these things). I had a look through the other associated drafts, and I was not able to find a definition of "home domain" or "home network" there; neither was it in RFC 5164. I don't have the IEEE 802.21 standard, so I don't know whether it is defined there. Defining this term, however, would go a long way to improving the document. All of that said, I was able (I think) to figure out what is meant by "home domain"; anyway, my _ad hoc_ definition ("the DNS domain in which the MN thinks its hostname is part of") made the document make sense to me. I could live with publication with this missing definition, but I think it would be a big improvement if it were added. The following text in section 2.2 is a little weak: Note, that the regexp field in the NAPTR example above is empty. This document discourages the use of this field as its usage can be complex and error prone; and the discovery of the MIH services do not require the flexibility provided by this field over a static target present in the TARGET field. It seems to me that since the regexp field is previously defined to be empty (in what I assume is the normative text), then a returned NAPTR record with a populated regexp field is not just discouraged: it's undefined, and is not an instance of a NAPTR record that conforms with the specification in this draft. I do not object to the publication of the draft with this text still there, but I think it would be a significant improvement to strengthen this since I think the document will be easier to understand if this is made plainer. I believe that Alfred Hoenes has already pointed out that Section 2.3 suggests a possibility of an IP address in TARGET. That's not right: the SRV definition in RFC 2782 defines "Target" as "The domain name of the target host." There should not be an IP address returned here. I think this must be fixed before publication, because the document seems to be suggesting something is possible that is not. (Similarly, an SRV record should always have a port number as far as I can tell -- certainly, RFC 2782 does not make the field optional. Is the idea that the port could be "0"?) The IANA considerations says that the Protocol field of the new registry contains the name and acronym for the protocol, along with a reference to a document that describes the transport protocol; but the initial values defined in the draft don't do that. They also don't contain the name, address, email address, and telephone number of the person registering. (I actually think this is a very bad idea -- we already have a broad range of examples of stale information of this sort in the RFC database itself, and adding more stale examples to an IANA registry seems to me to be a mistake). It would be nice to start IANA off with a clean registry. The above said, _apart from fixing the SRV record treatment_ (which I think is necessary), I have no strong objection to publishing the document as it stands. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dromasca@avaya.com Mon Jun 29 08:51:20 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B8728C11B for ; Mon, 29 Jun 2009 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Cf+6JSAJH+p for ; Mon, 29 Jun 2009 08:51:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 75A853A6890 for ; Mon, 29 Jun 2009 08:51:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,309,1243828800"; d="scan'208";a="149895166" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Jun 2009 11:49:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jun 2009 11:49:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 17:49:11 +0200 Message-ID: In-Reply-To: <20090629154211.GH1525@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] FW: PRELIMINARY Agenda and Package for July 2, 2009Telechat thread-index: Acn40C79QXFNCgtFRwKfuA9H4OD9VwAAL1ew References: <20090629154211.GH1525@shinkuro.com> From: "Romascanu, Dan (Dan)" To: "Andrew Sullivan" Cc: dns-dir@ietf.org Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for July 2, 2009Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:51:21 -0000 Thanks, Andrew. Unless I hear other objections or comments, I plan to open a DISCUSS on the SRV record issue, and include the other comments as non-blocking COMMENTs.=20 Dan =20 > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@shinkuro.com]=20 > Sent: Monday, June 29, 2009 6:42 PM > To: Romascanu, Dan (Dan) > Cc: dns-dir@ietf.org > Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for=20 > July 2, 2009Telechat >=20 > Dear colleagues, >=20 > On Fri, Jun 26, 2009 at 08:05:29AM +0200, Romascanu, Dan (Dan) wrote: > > o draft-ietf-mipshop-mos-dns-discovery-06.txt > > Locating IEEE 802.21 Mobility Servers using DNS (Proposed=20 > > Standard) >=20 > I have read this document. I think it has received some=20 > previous DNS Directorate attention. >=20 > I think the reason this document previously received some=20 > objections has to do with certain notions embedded in it. In=20 > particular, this passage stands out: >=20 > When the MN needs to discover Mobility Services in its home domain, > the input to the First Well Known Rule MUST be the MN's=20 > home domain, > which is assumed to be pre-configured in the MN. >=20 > I imagine the issue has really been this notion of a "home=20 > domain", and how it fits into the DNS (where it's either an=20 > entirely alien notion or one of the suffixes in the search=20 > path, depending on how you feel about these things). I had a=20 > look through the other associated drafts, and I was not able=20 > to find a definition of "home domain" or "home network"=20 > there; neither was it in RFC 5164. I don't have the IEEE=20 > 802.21 standard, so I don't know whether it is defined there. > Defining this term, however, would go a long way to improving=20 > the document. All of that said, I was able (I think) to=20 > figure out what is meant by "home domain"; anyway, my _ad=20 > hoc_ definition ("the DNS domain in which the MN thinks its=20 > hostname is part of") made the document make sense to me. I=20 > could live with publication with this missing definition, but=20 > I think it would be a big improvement if it were added. >=20 > The following text in section 2.2 is a little weak: >=20 > Note, that the regexp field in the NAPTR example above is empty. > This document discourages the use of this field as its usage can be > complex and error prone; and the discovery of the MIH services do > not require the flexibility provided by this field over a static > target present in the TARGET field. >=20 > It seems to me that since the regexp field is previously=20 > defined to be empty (in what I assume is the normative text),=20 > then a returned NAPTR record with a populated regexp field is=20 > not just discouraged: it's undefined, and is not an instance=20 > of a NAPTR record that conforms with the specification in=20 > this draft. I do not object to the publication of the draft=20 > with this text still there, but I think it would be a=20 > significant improvement to strengthen this since I think the=20 > document will be easier to understand if this is made plainer. >=20 > I believe that Alfred Hoenes has already pointed out that=20 > Section 2.3 suggests a possibility of an IP address in=20 > TARGET. That's not right: > the SRV definition in RFC 2782 defines "Target" as "The=20 > domain name of the target host." There should not be an IP=20 > address returned here. I think this must be fixed before=20 > publication, because the document seems to be suggesting=20 > something is possible that is not. (Similarly, an SRV record=20 > should always have a port number as far as I can tell --=20 > certainly, RFC 2782 does not make the field optional. Is the=20 > idea that the port could be "0"?) >=20 > The IANA considerations says that the Protocol field of the=20 > new registry contains the name and acronym for the protocol,=20 > along with a reference to a document that describes the=20 > transport protocol; but the initial values defined in the=20 > draft don't do that. They also don't contain the name,=20 > address, email address, and telephone number of the person=20 > registering. (I actually think this is a very bad idea > -- we already have a broad range of examples of stale=20 > information of this sort in the RFC database itself, and=20 > adding more stale examples to an IANA registry seems to me to=20 > be a mistake). It would be nice to start IANA off with a=20 > clean registry. =20 >=20 > The above said, _apart from fixing the SRV record treatment_=20 > (which I think is necessary), I have no strong objection to=20 > publishing the document as it stands. >=20 > Best regards, >=20 > Andrew >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. >=20 >=20 >=20 >=20 From pk@DENIC.DE Tue Jun 30 09:30:55 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348C13A6B72 for ; Tue, 30 Jun 2009 09:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.562 X-Spam-Level: X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ojldsvXGm+B for ; Tue, 30 Jun 2009 09:30:54 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 642C53A6973 for ; Tue, 30 Jun 2009 09:30:54 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.182]) by office.denic.de with esmtp id 1MLgDr-0002za-NV; Tue, 30 Jun 2009 18:30:19 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 81F081A40DB; Tue, 30 Jun 2009 18:30:19 +0200 (CEST) Date: Tue, 30 Jun 2009 18:30:18 +0200 From: Peter Koch To: dns-dir@ietf.org Message-ID: <20090630163018.GI18678@unknown.office.denic.de> Mail-Followup-To: dns-dir@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [dns-dir] Next Meeting 2009-07-06 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:30:55 -0000 Dear DNS WG members, although I missed yesterday's one-week deadline, I'd like to suggest we have our next regular conf call Monday next week, 2009-07-06, 1400 UTC, to discuss open reviews, DNS and DNSSEC specifics for Stockholm and to share information about new and upcoming working group documents in the non-DNS WGs that might benefit from our attention. Regards, Peter From dromasca@avaya.com Tue Jun 30 09:35:24 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB0C3A6A1E for ; Tue, 30 Jun 2009 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZihgqjqNMlkF for ; Tue, 30 Jun 2009 09:35:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DE27D3A6973 for ; Tue, 30 Jun 2009 09:35:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,317,1243828800"; d="scan'208";a="150018688" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Jun 2009 12:32:48 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Jun 2009 12:32:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jun 2009 18:32:25 +0200 Message-ID: In-Reply-To: <20090630163018.GI18678@unknown.office.denic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Next Meeting 2009-07-06 thread-index: Acn5oDJ5DmN/Or8ES7Ks0e/dYCy2MQAABKdw References: <20090630163018.GI18678@unknown.office.denic.de> From: "Romascanu, Dan (Dan)" To: "Peter Koch" , Subject: Re: [dns-dir] Next Meeting 2009-07-06 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:35:24 -0000 I will pass on this one as I will be on vacation 7/3 to 7/12.=20 Dan =20 > -----Original Message----- > From: dns-dir-bounces@ietf.org=20 > [mailto:dns-dir-bounces@ietf.org] On Behalf Of Peter Koch > Sent: Tuesday, June 30, 2009 7:30 PM > To: dns-dir@ietf.org > Subject: [dns-dir] Next Meeting 2009-07-06 >=20 > Dear DNS WG members, >=20 > although I missed yesterday's one-week deadline, I'd like to=20 > suggest we have our next regular conf call Monday next week,=20 > 2009-07-06, 1400 UTC, to discuss open reviews, DNS and DNSSEC=20 > specifics for Stockholm and to share information about new=20 > and upcoming working group documents in the non-DNS WGs that=20 > might benefit from our attention. >=20 > Regards, > Peter > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir >=20 From ajs@shinkuro.com Tue Jun 30 09:50:58 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534873A6924 for ; Tue, 30 Jun 2009 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGGLh5UBa3L5 for ; Tue, 30 Jun 2009 09:50:57 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6C7B43A6C0B for ; Tue, 30 Jun 2009 09:50:57 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AEED12FE9664 for ; Tue, 30 Jun 2009 16:49:02 +0000 (UTC) Date: Tue, 30 Jun 2009 12:49:00 -0400 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20090630164900.GE3059@shinkuro.com> References: <20090630163018.GI18678@unknown.office.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090630163018.GI18678@unknown.office.denic.de> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] Next Meeting 2009-07-06 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:50:58 -0000 On Tue, Jun 30, 2009 at 06:30:18PM +0200, Peter Koch wrote: > Dear DNS WG members, > > although I missed yesterday's one-week deadline, I'd like to suggest we have > our next regular conf call Monday next week, 2009-07-06, 1400 UTC, to discuss > open reviews, DNS and DNSSEC specifics for Stockholm and to share information > about new and upcoming working group documents in the non-DNS WGs that might > benefit from our attention. Ok with me. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ogud@ogud.com Tue Jun 30 11:31:03 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4773A69DC for ; Tue, 30 Jun 2009 11:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdaem+OdYL0f for ; Tue, 30 Jun 2009 11:31:02 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id AA0A63A67FF for ; Tue, 30 Jun 2009 11:31:02 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5UIUCgQ063533 for ; Tue, 30 Jun 2009 14:30:12 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 30 Jun 2009 14:30:12 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090630_183012_081473.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-wijngaards-dnsop-trust-history-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:31:03 -0000 Count: 24 DNS Extensions Working Group W. Wijngaards Internet-Draft NLnet Labs Intended status: Standards Track June 30, 2009 Expires: January 1, 2010 DNSSEC Trust Anchor History Service draft-wijngaards-dnsop-trust-history-00 Abstract When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. From ogud@ogud.com Tue Jun 30 11:31:05 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2BF28C3F3 for ; Tue, 30 Jun 2009 11:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDFiPke-UtxV for ; Tue, 30 Jun 2009 11:31:04 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9712028C212 for ; Tue, 30 Jun 2009 11:31:04 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5UIU1Ew063434 for ; Tue, 30 Jun 2009 14:30:02 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 30 Jun 2009 14:30:02 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090630_183002_049996.ogud@ogud.com> Subject: [dns-dir] DNS Early Warn: draft-templin-intarea-vet-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:31:05 -0000 Count: 16 Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Standards Track June 29, 2009 Expires: December 31, 2009 Virtual Enterprise Traversal (VET) draft-templin-intarea-vet-00.txt Abstract Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. From mlarson@verisign.com Tue Jun 30 20:16:59 2009 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F73C3A6EB2 for ; Tue, 30 Jun 2009 20:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFwmKMwA8eWY for ; Tue, 30 Jun 2009 20:16:58 -0700 (PDT) Received: from mail.kahlerlarson.org (tornado.kahlerlarson.org [64.22.125.99]) by core3.amsl.com (Postfix) with ESMTP id 996CF3A6B4F for ; Tue, 30 Jun 2009 20:16:58 -0700 (PDT) Received: from sirocco.local (pool-71-163-176-44.washdc.fios.verizon.net [71.163.176.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kahlerlarson.org (Postfix) with ESMTP id 9F4F037CBD for ; Tue, 30 Jun 2009 23:17:11 -0400 (EDT) Date: Tue, 30 Jun 2009 23:17:10 -0400 From: Matt Larson To: dns-dir@ietf.org Message-ID: <20090701031709.GC2909@sirocco.local> References: <20090630163018.GI18678@unknown.office.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] Next Meeting 2009-07-06 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 03:16:59 -0000 On Tue, 30 Jun 2009, Romascanu, Dan (Dan) wrote: > I will pass on this one as I will be on vacation 7/3 to 7/12. I will also be on vacation and will miss this call. Matt