
MIME-Version: 1.0
In-Reply-To: <EE8D912486CB3B40978DC42135F2BF8C88AAE9@ma02exchtmp01.Cantata.com>
Content-class: urn:content-classes:message
Subject: FW: [APPS-REVIEW] Review of draft-daigle-unaptr-01
Date: Thu, 11 Jan 2007 00:29:51 -0500
Message-ID: <EE8D912486CB3B40978DC42135F2BF8C88AB6A@ma02exchtmp01.Cantata.com>
Thread-Topic: [APPS-REVIEW] Review of draft-daigle-unaptr-01
Thread-Index: Acc0NwOJy19+sK/tRka6QB3vTdba6QBCoD/U
References: <EE8D912486CB3B40978DC42135F2BF8C88AAE9@ma02exchtmp01.Cantata.com>
From: "Burger, Eric" <eburger@cantata.com>
To: <apps-review@ietf.org>
Precedence: list
Content-Type: multipart/mixed; boundary="===============1543940298=="
Errors-To: apps-review-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1543940298==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73541.8478AFA5"
Content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73541.8478AFA5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

John said it was OK to post.
Thanks to John for doing this one.

--
Sent from my wireless device. Sorry if terse. Can't wait for lemonade!  =
What is lemonade? See <http://flyingfox.cantata.com/i-d/lemonade>

 -----Original Message-----
From: 	John C Klensin [mailto:klensin@jck.com]
Sent:	Tuesday, January 09, 2007 04:42 PM Eastern Standard Time
To:	Burger, Eric
Subject:	Re: [APPS-REVIEW] Review of draft-daigle-unaptr-01

I've read fairly carefully through this document.

The proposal is, as noted, a rather minor extension of RFC 3958.=20
It is worth doing, standardizing, and getting right before we=20
end up with local variations, since the requirement is fairly=20
obvious.

I have a fundamental architectural concern about this general=20
type of work and the relationship of DDDS to the network and=20
DNS, but, since the IETF has already signed off on RFC3401-3404,=20
this document would be an inappropriate place to raise the=20
concern (I have discussed that issue separately with Leslie).

My most significant difficulty with this draft is that the third=20
sentence  of the third paragraph of Section 1 "Introduction",=20
(starting "However,...") is hard to follow.  But, at worst, the=20
RFC Editor's attention should be called to that one to make sure=20
it is fixed.  The problem does not have a negative impact on=20
ability to understand the protocol.   Similarly, the Security=20
Considerations section would be easier to follow if some=20
references were inserted directly there, even though those=20
references could be deduced from other parts of the document.

Of course, if there were any real problems, I probably would not=20
comment on either of the above, but I feel some need to=20
demonstrate that I read the thing :-)

Solid piece of work.

    john


------_=_NextPart_001_01C73541.8478AFA5
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7638.1">
<TITLE>FW: [APPS-REVIEW] Review of draft-daigle-unaptr-01</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>John said it was OK to post.<BR>
Thanks to John for doing this one.<BR>
<BR>
--<BR>
Sent from my wireless device. Sorry if terse. Can't wait for =
lemonade!&nbsp; What is lemonade? See &lt;<A =
HREF=3D"http://flyingfox.cantata.com/i-d/lemonade">http://flyingfox.canta=
ta.com/i-d/lemonade</A>&gt;<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; John C Klensin [<A =
HREF=3D"mailto:klensin@jck.com">mailto:klensin@jck.com</A>]<BR>
Sent:&nbsp;&nbsp; Tuesday, January 09, 2007 04:42 PM Eastern Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Burger, Eric<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [APPS-REVIEW] =
Review of draft-daigle-unaptr-01<BR>
<BR>
I've read fairly carefully through this document.<BR>
<BR>
The proposal is, as noted, a rather minor extension of RFC 3958.<BR>
It is worth doing, standardizing, and getting right before we<BR>
end up with local variations, since the requirement is fairly<BR>
obvious.<BR>
<BR>
I have a fundamental architectural concern about this general<BR>
type of work and the relationship of DDDS to the network and<BR>
DNS, but, since the IETF has already signed off on RFC3401-3404,<BR>
this document would be an inappropriate place to raise the<BR>
concern (I have discussed that issue separately with Leslie).<BR>
<BR>
My most significant difficulty with this draft is that the third<BR>
sentence&nbsp; of the third paragraph of Section 1 =
&quot;Introduction&quot;,<BR>
(starting &quot;However,...&quot;) is hard to follow.&nbsp; But, at =
worst, the<BR>
RFC Editor's attention should be called to that one to make sure<BR>
it is fixed.&nbsp; The problem does not have a negative impact on<BR>
ability to understand the protocol.&nbsp;&nbsp; Similarly, the =
Security<BR>
Considerations section would be easier to follow if some<BR>
references were inserted directly there, even though those<BR>
references could be deduced from other parts of the document.<BR>
<BR>
Of course, if there were any real problems, I probably would not<BR>
comment on either of the above, but I feel some need to<BR>
demonstrate that I read the thing :-)<BR>
<BR>
Solid piece of work.<BR>
<BR>
&nbsp;&nbsp;&nbsp; john<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C73541.8478AFA5--


--===============1543940298==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW@ietf.org
https://www1.ietf.org/mailman/listinfo/apps-review

--===============1543940298==--