Fwd: [rt.amsl.com #1387] AutoReply: submit new internet draft about Universal Resource Name Resolution

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

Re: Fwd: [rt.amsl.com #1387] AutoReply: submit new internet draft about Universal Resource Name Resolution

On Feb 2, 2008, at 4:59 AM, Lican Huang wrote:

> Hi,
>
> Who can tell me why I got a response of a trouble tickect  message  
> as following when I submit an Internet Draft to Internet- 
> Drafts <at> ietf.org <Internet-Drafts <at> ietf.org> ?

AMS just finished transition of all IETF IT services, and
it appears as though they've got a bit more tweaking to
do.  I forwarded your email to ietf-action <at> , see email
below for more details..

-danny

Begin forwarded message:
> From: Ray Pelletier <rpelletier <at> isoc.org>
> Date: January 31, 2008 6:58:35 PM MST
> To: The IESG <iesg <at> ietf.org>, IAB <iab <at> ietf.org>,  Working Group  
> Chairs <wgchairs <at> ietf.org>, IAOC <iaoc <at> ietf.org>
> Subject: IT Services Transitioned
>
> All IT services have been transitioned.  As previously reported,
> please bear in mind that the AMS setup is not the same as the NSS
> setup.  Some changes were necessary as part of the transition.  It
> is possible there will be some issues that need attention as the
> community begins to use the services in their new production
> environment.
>
> The good news is that all services, except jabber, are now available
> on both IPv4 and IPv6.  This includes the web, ftp, email, and
> rsync for those who mirror internet-drafts.
>
> The status that you need to know is as follows.
>
> 1. Reminder, iab and iesg mailing lists have been moved to be in
>   their respective domains.  This may affect your filtering but
>   should not effect distribution.
>
> 2. As it turns out we did not move the irtf mailing lists into
>   irtf.org.  In order to do this we need to be hosting the irtf.org
>   web site for mailman to work properly.  Since this site is an
>   independent site we have set this aside for now.
>
> 3. We have also noticed that GMail.com is blocking the IETF servers'
>   email delivery.  They started this 5 minutes after email was
>   enabled.  We have already filed the appropriate reports and hope
>   for a resolution in 24-48 hours.  Please tell your friends on
>   GMail.com that they are not getting IETF email.
>
> 4. Finally, site automation is not enabled at this time.  This means
>   that "static" web pages or files that are automatically
>   generated, e.g.,
>   http://www.ietf.org/internet-drafts/1id-index.txt, are not
>   current.  This is a priority work item and will be completed as
>   soon as possible.
>
> We would appreciate it if IETF participants would report any
> discrepancies or problems immediately to ietf-action <at> ietf.org
> as they examine web pages or services of importance to them. AMS  
> will address all concerns as quickly as they can.
>
> We will keep the community informed if there are major concerns or
> delays.
>
> On behalf of AMS and the transition team thank you for your
> support and patience.
>
> Ray Pelletier
> IETF Administrative Director
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

FWD: Document Action: '6to4 Reverse DNS Delegation Specification' to Informational RFC

Dear WG,

FYI, draft-huston-6to4-reverse-dns-07.txt, reviewed here upon request of the
IAB, was approved by the IESG.  Thanks a lot to all involved!

-Peter

----- Forwarded message from The IESG <iesg-secretary <at> ietf.org> -----

From: The IESG <iesg-secretary <at> ietf.org>
To: IETF-Announce <ietf-announce <at> ietf.org>
Cc: Internet Architecture Board <iab <at> iab.org>,
        RFC Editor <rfc-editor <at> rfc-editor.org>
Subject: Document Action: '6to4 Reverse DNS Delegation 
 Specification' to Informational RFC 
Date: Tue, 22 Jan 2008 17:35:54 -0500

The IESG has approved the following document:

- '6to4 Reverse DNS Delegation Specification '
   <draft-huston-6to4-reverse-dns-07.txt> as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-huston-6to4-reverse-dns-07.txt

Technical Summary

  This document describes the service mechanism for requesting and
  maintaining a delegation for the DNS reverse mapping of 6to4 IPv6
address
  space within the 2.0.0.2.ip6.arpa domain via an automated interface.

Publication Requested was in Oct 24.
However, it fell through the cracks as it was not added to the tracker
when the publication request was sent to the secretariat.

----

Working Group Summary

The dnsop WG reviewed this document on request of the IAB.

Document Quality

  The service is operational as described and is provided by the NRO.
  The 2.0.0.2.ip6.arpa zone contains several hundred delegations.

---------
RFC Editor Note:

Please add the following text to the Security Considerations section:

   For a general threat analysis of 6to4, especially the additional risk
   of address spoofing in 2002::/16, see [RFC3964].

   Section 4 notes that the local site administrator could take
   appropriate access control measures to prevent clients inside a 6to4
   site performing unauthorized changes to the delegation details.  This
   may be in the form of a firewall configuration regarding control of
   access to the service from the interior of 6to4 site, or a similar
   mechanism that enforces local access policies.

-----------------
Another RFC Editor Note:

Current text

The potential issues with this structure include:

...

   o  IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses
      dynamically-assigned external IPv4 interface addresses, could
      inherit nonsense reverse entries created by previous users of the
      dynamically assigned address.  In this case the client site could
      request delegation of the reverse zone as required.

Proposed text

The potential issues with this structure include:

...

   o  IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses
      dynamically-assigned external IPv4 interface addresses, could
      inherit nonsense reverse entries created by previous users of the
      dynamically assigned address.  In this case the client site could
      request delegation of the reverse zone as required. More
      generally, given the potential for inheritance of 'stale' reverse
      DNS information in this context, in  those cases where the issues
      of potential inheritance of 'stale' reverse DNS information is a
      concern, it is recommended that a 6to4 site either use a static
      IPv4 address in preference to a dynamically-assigned address, or
      ensure that the reverse delegation information is updated using
      the service mechanism described here upon each dyanamic address
      assignment event.
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

draft-ietf-dnsop-dnssec-trust-anchor-00

As instructed by chair we have submitted a version 00 that is IDENTICAL
to the 02 version of the individual submission.

Please ignore this version as 01 will be posted early next week with
the edits we have accumulated.

	Olafur & Matt

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title           : DNSSEC Trust Anchor Configuration and Maintenance
	Author(s)       : M. Larson, O. Gudmundsson
	Filename        : draft-ietf-dnsop-dnssec-trust-anchor-00.txt
	Pages           : 14
	Date            : 2008-02-08

This document recommends a preferred format for specifying trust
anchors in DNSSEC validating security-aware resolvers and describes
how such a resolver should initialize trust anchors for use.  This
document also describes different mechanisms for keeping trust
anchors up to date over time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-trust-anchor-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-dnsop-dnssec-trust-anchor-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-dnssec-trust-anchor-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

Call for Agenda Items

Dear WG,

it's only four weeks left to IETF71, so here's the usual call for agenda items.
Please submit any proposals and suggestions to Rob and me by Tuesday, 26 FEB,
2200 UTC.
The preliminary agenda at <https://datatracker.ietf.org/meeting/71/agenda.html>
gives us a two hour slot on Tuesday afternoon.  Please remember, though, that
rescheduling might occur.

An agenda outline is available at
<http://www.ietf.org/proceedings/08mar/agenda/dnsop.txt>, where additions
will be made before the draft dnsop agenda gets posted.

Here's an excerpt of <http://www.ietf.org/meetings/71-cutoff_dates.html>:

	Mon, 18 FEB, 2200 UTC   Cut-off for -00 I-Ds
	Mon, 25 FEB,            Final agenda to be published
	Mon, 25 FEB, 2200 UTC   Cut-off for all I-Ds
	Tue, 26 FEB, 2200 UTC   DNSOP Agenda items due
	Wed, 27 FEB, 2200 UTC   Draft WG Agendas due
	Mon, 03 MAR, 2200 UTC   Revised WG Agendas due

The preferred way of submitting I-Ds is now via the online submission tool:
<https://datatracker.ietf.org/idst/upload.cgi>

-Peter
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title           : DNSSEC Trust Anchor Configuration and Maintenance
	Author(s)       : M. Larson, O. Gudmundsson
	Filename        : draft-ietf-dnsop-dnssec-trust-anchor-01.txt
	Pages           : 14
	Date            : 2008-02-11

This document recommends a preferred format for specifying trust
anchors in DNSSEC validating security-aware resolvers and describes
how such a resolver should initialize trust anchors for use.  This
document also describes different mechanisms for keeping trust
anchors up to date over time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-trust-anchor-01.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-dnsop-dnssec-trust-anchor-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-dnssec-trust-anchor-01.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

Re: I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-01.txt

At 11:00 11/02/2008, Internet-Drafts <at> ietf.org wrote:

>         Title           : DNSSEC Trust Anchor Configuration and Maintenance
>         Author(s)       : M. Larson, O. Gudmundsson
>         Filename        : draft-ietf-dnsop-dnssec-trust-anchor-01.txt
>         Pages           : 14
>         Date            : 2008-02-11

The changes since last version include, number of grammatical and English
improvements. Security considerations has been improved.

The editors think this document is ready for WGLC, please send in comments.

         thanks
         Matt & Olafur  

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

Re: I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-01.txt

Some comments on draft-ietf-dnsop-dnssec-trust-anchor-01:

Section 2, last para

#                           A validating resolver MAY support
#configuration using a truncated DS hash value as a human-factors
#convenience: shorter strings are easier to type and less prone to
#error when entered manually.

There should be some guidance on the amount of truncation allowed.
For instance, can the DS hash be truncated to a single byte?
(I assume not)

-------------

Section 3 :

I don't understand the usage of the word "priming" here. The steps
that are described are *exactly* what would need to happen during
the normal DNSSEC validation process. I can see the need for priming
DNSKEYs when trust anchors are also configured as DNSKEYs (in
which case priming helps the validator determine if the configured
DNSKEYs are the same as the ones published) but I don't see the need
for priming DNSKEYs when the trust anchors are specified as DS
records. Or, are we instead saying here that DNSKEYs fetched through
the priming process will not be subject to TTL expiration (which,
I think, shouldn't be the case either)?

-------------

Also in Section 3, second-last para

# A validating resolver should remove a trust anchor
# that has been revoked as indicated by the REVOKE bit in the
# corresponding DNSKEY record as described in RFC 5011 [6].

We may not want to necessarily combine resolver behavior with
trust anchor management. The two are different tasks and can be
accomplished using different tools. I'd suggest simply deleting this
sentence and modifying the para to read:

"If there are multiple trust anchors configured for a zone, any one of
them is sufficient to validate data in the zone.  For this reason,
old trust anchors SHOULD be removed from a validating resolver's
trust anchor list soon after the corresponding keys are no longer
used by the zone, as described in RFC 5011 [6]."
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop

Re: I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-01.txt

Olafur Gudmundsson wrote:
> At 11:00 11/02/2008, Internet-Drafts <at> ietf.org wrote:
> 
> 
>>         Title           : DNSSEC Trust Anchor Configuration and Maintenance
>>         Author(s)       : M. Larson, O. Gudmundsson
>>         Filename        : draft-ietf-dnsop-dnssec-trust-anchor-01.txt
>>         Pages           : 14
>>         Date            : 2008-02-11
> 
> The changes since last version include, number of grammatical and English
> improvements. Security considerations has been improved.
> 

Just an open suggestion, but should there be more text to clarify what 
happens when a zone intends to delete it's outstanding trust anchors and 
link its security through its parent by having a DS RR in the parent zone?

There is text in RFC 5011 on how a zone operator does this, but there 
isn't a lot of detail in this draft.  Worst case scenario is that the 
validator declares the zone responses bogus, which isn't good.

I agree with Suresh's comment about limiting truncation.  I don't have a 
good number in mind though. It is a good document otherwise.

Scott

> The editors think this document is ready for WGLC, please send in comments.
> 
>          thanks
>          Matt & Olafur  
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP <at> ietf.org
> http://www.ietf.org/mailman/listinfo/dnsop
> 

--

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
scott.rose <at> nist.gov

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
http://www.ietf.org/mailman/listinfo/dnsop