Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp

From: Jeff Macdonald <[email-masked]>
Date: Fri, 2 Jan 2009 10:27:28 -0500

On Wed, Dec 31, 2008 at 07:34:53PM -0500, J D Falk wrote:
>   On 30/12/2008 11:15, "Dave CROCKER" <[email-masked]> wrote:
>
>   > The fact that i= is defined to identify a user, rather than a mailbox,
>   and
>
>   A user, or a use!  But I doubt that makes things any clearer.

I thought i= was just an identity. It could have any of these
properties:

1) is a valid domain when it is the same as d=
2) could be a sub-domain of d= and might not even exist
3) could look like an address/mailbox (with 1 & 2) but that mailbox
doesn't have to exist
  
So it should be treated opaquely as it could really represent anything. 

-- 
Jeff Macdonald
[email-masked]

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 Jan 2009 07:53:42 -0800

On Dec 31, 2008, at 4:34 PM, J D Falk wrote:

> > The fact that i= is defined to identify a user, rather than a  
> mailbox, and
>

Matching against just the domain to confirm compliance with ADSP does  
not change that i= represents the "on-behalf-of" entity.  The MUA or  
the agent annotating the messages can confirm the "on-behalf-of"   
matches against the From header before adding annotation, such as  
making folder placements.  This would represent a very similar process  
needed for Sender-ID when the PRA does not match against the From.    
To allow "all" messages, ADSP should be able to accommodate a normal  
range of valid messages.  Otherwise, an imposed ADSP "on-behalf-of"  
limitation will impose a requirement to _violate_ the meaning of the  
i= parameter.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 06 Jan 2009 14:47:53 -0800

(catching up after the Holiday break)

John L wrote:

(The main implication being that just signing all your outgoing email
may not allow you to advertise "dkim=all", if you e.g. use the "i="
tag to identify a mailing list manager -- the only example of its use
given in RFC 4871.)

Ah, good point. That's straightforward to fix.

I'm not sure I understand the concern -- why would a mailing list
manager signature be considered an author signature, or conversely why
would a domain apply a mailing list manager signature when it intends
to apply an author signature?

The ability to apply a mailing list manager signature, and not have it
confused with an author signature when the (alleged) author and the
mailing list manager happen to be in the same domain, is one of the
strengths of using i=, including the local-part, in comparisons with
the From address.

For example, suppose the ietf.org mailing list manager signs its mail
using i=[email-masked].  The IETF Chair sends a message to the list,
using From: <[email-masked]>.  I contend it would be bad for the
mailing list manager signature to be confused with an author signature.

I suppose the alternative, now that we have some experience with i= in
real life, is to adjust the language in ADSP to match the experience.
Dunno how the other authors feel about that.

I'd like to understand what you have in mind.

2) Protecting subdomains

Something like this, perhaps? (added after 2nd para in Section 3.1)

Note: If an organization wants to publish Author Domain Signing
Practices for all its subdomains, too, it needs to create ADSP
records for every _adsp._domainkey_.<subdomain>.domain.example.
Note that wildcards cannot be used (see Section 6.3); however,
creating the ADSP records could be automated with suitable DNS
management tools.

OK.

It should also be pointed out that, in this context, hostnames also
need to have ADSP records published for them too, since they're
considered to be subdomains in the context of email addresses.

4) Minor clarifications/nits

I think clearly explaining when an organization that signs all
its outgoing email can actually publish a "dkim=all" policy is pretty
important -- although ADSP doesn't (and shouldn't) do everything,
we need to be clear about what it does.

It's when the signature matches the From: address. Shouldn't be too hard
to say it again.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Tue, 06 Jan 2009 14:53:57 -0800

John L wrote:

That would be fine with me, but what it says now is that the i= MUST match
the From: address. As I've said a few times, that's clearly wrong, but I
got shouted down in the past when I tried to change it.

Without getting into the merits of the argument (and I don't think we
should do all that again), the document does currently reflect the
WG's rough consensus so let's keep this to adding clarifications as
Pasi requested and not try re-open issues now after the end of IETF
LC.

Since I don't understand what the people who want to use i= think it's
supposed to do, I'll defer to the other authors and them them fix it this
time around.

Sure, I'd be willing to write some text about this.  I don't want to
reopen the can of worms by changing the semantics of the document at
this late stage.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 06 Jan 2009 15:09:36 -0800

MH Michael Hammer (5304) wrote:
>
> Is there anyone on the list that would realistically plan on
> implementing/publishing ADSP using an "i=" override? If so, could they
> explain the logic and necessity of doing so? What is the anticipated
> benefit?
>   

It really applies to the implementation of the checker, and not to the
publication of ADSP records.

At the risk of repeating myself, here's an example of when it's
important.  Suppose the ietf.org mailing list manager signs its mail
using i=[email-masked].  The IETF Chair sends a message to the list,
using From: <[email-masked]>.  I contend it would be bad for the mailing
list manager signature to be confused with an author signature.

This example involves the use of local-parts, but one could also come up
with (somewhat more contrived) examples where the mailing list manager
is at lists.example.com and some users are at users.example.com.  If the
keys are published in the example.com domain (d=example.com) and i=
isn't being used, it isn't possible to distinguish author signatures and
list signatures.

-Jim

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 6 Jan 2009 20:01:36 -0500

> -----Original Message-----
> From: Jim Fenton [mailto:[email-masked]]
> Sent: Tuesday, January 06, 2009 6:10 PM
> To: MH Michael Hammer (5304)
> Cc: John L; [email-masked]
> Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
> 
mailing
> list manager signature to be confused with an author signature.

But in terms of the receiving domain checking, why would they make a
distinction from an ADSP perspective? The question at hand is whether
all email from a particular (sub) domain is signed. If a domain is
making this type of assertion, then it is looking at ietf.org and
shouldn't really care whether the user is chair@ or ietf@. If you are
asserting that one might be signed and the other not then I think there
is an issue. If you assert that both are signed but the signatures might
be different (within the same domain but with different selectors for
example then I'm going to say fine because if ietf.org asserts it signs
all mail then it still works. It is the domain that is important, not
the user part for the all assertion. 

> isn't being used, it isn't possible to distinguish author signatures
and

Distinguish to what purpose Jim? 

Either they are signed or they aren't signed from an ADSP perspective.
If distinguishing at this granularity is important then publish ADSP for
lists.example.com/DKIM sign for that domain (d=) and publish ADSP for
users.example.com/DKIM sign for that domain (d=). The author signatures
are clearly distinguished from the list signatures. 

Mike

---

From: Jim Fenton <[email-masked]>
Date: Tue, 06 Jan 2009 17:20:18 -0800

Hi, Mike...comments inline:

> the user part for the all assertion. 

Suppose that ietf.org asserts an ADSP record but doesn't require
signatures on incoming messages, even from its own domain (there's no
requirement that they do).  Someone spoofs a message from
[email-masked], which is of course unsigned.  The message coming out of
the list looks like it has an author signature.  I have a problem with that.

In this situation, we could require that the mailing list manager not
apply a signature if it might be confused with an author signature, but
then there's no way for it to apply a signature representing the list.
>   
>> This example involves the use of local-parts, but one could also come
>>     
> up
>   
>> is at lists.example.com and some users are at users.example.com.  If
>>     
> the
>   
>> isn't being used, it isn't possible to distinguish author signatures
>>     
> and
>   
>> list signatures.
>>
>>     
>

The d=/i= distinction was originally created to simplify key management
by domains having many subdomains, in that they could publish the keys
in a parent domain (d=) while signing for a subdomain (i=).  You're
basically suggesting that we abandon that optimization so that we can
use the d= domain  rather than the i= domain for ADSP.

Remember that the lookup address for ADSP is always the domain of the
>From address (users.example.com) and not the d=domain.  In this
situation ADSP records for lists.example.com and for example.com would
never be referenced.

-Jim

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 6 Jan 2009 21:06:48 -0500

I'll stick t o inline comments at the risk of this getting confusing.

> Sent: Tuesday, January 06, 2009 8:20 PM

If ietf.org is willing to put it's signature on the spoof message I
would assert that it has a DKIM problem more than an ADSP problem. 

Either the message has a valid signature or it does not. If there is a
valid signature then ietf.org is claiming responsibility. If it doesn't
have a valid signature....then not so much. If ietf.org is sending out
spoofed messages spoofing a "from" then it has a problem regardless of
whether it DKIM signs, uses ADSP or does anything else..

> then there's no way for it to apply a signature representing the list.

Then perhaps ietf.org should reconsider whether or how it DKIM signs,
whether it is a suitable candidate for ADSP and how it manages it's
lists.

By DKIM signing ietf.org is claiming responsibility for the mail - good
bad or indifferent. If it fixes the problem quickly and otherwise it has
a good reputation then it maintains it's reputation. If it consistently
signs problem mail then it may lose it's reputation.

> > are clearly distinguished from the list signatures.

But they are all domain signatures. If you go back and look at the
discussion that took place before I suggested the name Author Domain
Signing Policy, I pointed out that authors don't sign, domains do
(unless an author also has control of DNS for a domain). 
> use the d= domain  rather than the i= domain for ADSP.

I'm too tired to wade back through the list to find the discussion that
included statements from receivers that for the most part the finer
granularity desired by some senders was not necessarily useful from the
receiver perspective. I'm not going to argue with receivers. I sign
email with DKIM because it helps them identify legitimate mail from our
domains vs the spoofed mail. For my use case I try to keep it as simple
as possible.

Other than hypotheticals I haven't heard any implementers on the sending
side indicating this is an issue. I can only speak from my experience
which is 5 domains with roughly 750 million signed emails in the past
year. 

> situation ADSP records for lists.example.com and for example.com would

d=users.example.com 
d=lists.example.com   

You look at the lack of optimization. I look at where you are going and
wonder why someone with lots of subdomains is going to turn to ADSP in
the first place. 

I sign for sub.sub.sub.domain.com but I don't sign for
sub.sub.domain.com but I sign for sub.domain.com but I don't want to
publish ADSP for this.
I sign and I want to publish ADSP discardable for
sub.sub.sub.domain.com. I think I know where and how I send email but
I'm not really sure. Right. This is not an organization that is a
suitable candidate for publishing ADSP.

Mike

---

From: John L <[email-masked]>
Date: Tue, 6 Jan 2009 20:28:49 -0500 (EST)

> the list looks like it has an author signature.  I have a problem with that.

Ooh, DKIM vs. list managers again.

I don't think that anyone other than the management of ietf.org gets to 
decide what their signing policy is.  There are zillions of ways that 
mailing lists decide what gets posted to a list.  If you like their list 
management policy, you can trust their signatures.  If you don't, you 
don't.

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Tue, 06 Jan 2009 20:56:26 -0800

> would assert that it has a DKIM problem more than an ADSP problem. 

There could be different criteria for signing as a mailing list than for
signing as an author.  A mailing list manager could, for example, sign
all messages that it forwards to the list in order to allow subscribers
to reliably ascertain all messages on the mailing list.  I'm not saying
that they would necessarily do this, just that it's one way of looking
at it.
> whether it DKIM signs, uses ADSP or does anything else..

This gets to the heart of the matter.  If it's just a question of
whether the message has a valid signature or not, then ADSP concepts
like "author signature" don't apply.  ADSP defines a more nuanced
meaning of the signature that depends on some relationship between the
signing address and the From address.
> signs problem mail then it may lose it's reputation.

Again, it's a question of whether there is just a claim of
responsibility (defined in RFC 4871) or the additional meaning of
claiming responsibility as author which we're trying to define here.

> (unless an author also has control of DNS for a domain). 

Domains do sign, but my view is that they might do so for different
reasons in different situations.

> wonder why someone with lots of subdomains is going to turn to ADSP in

Some heavily phished domains do use quite a few subdomains, for example
to separate transactional email from marketing materials.  They would
likely want to publish a different ADSP for the transactional and
marketing subdomains.  If d= gets used they might need to do their key
management differently for any subdomain that uses ADSP.  I don't see
sufficient reason why the use of ADSP should impact key
management/publication, rather than just to match against the i= address
(the domain part, anyway...this is a separate issue from the local part
issue discussed above).

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Jan 2009 09:35:16 +0000

Folks,

Can we restrict ourselves to the subject on the subject
line or start a separate thread?

I don't believe this discussion is necessary in order to
progress the ADSP draft, which, for better or worse, is
where the WG's rough consensus ended up.

Thanks,
Stephen.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Jan 2009 07:02:51 -0800

Stephen Farrell wrote:
> I don't believe this discussion is necessary in order to progress the ADSP 
> draft, which, for better or worse, is where the WG's rough consensus ended 
> up.

Stephen,

Happily, a community learns things about specifications as time progresses.
Sometimes that learning uncovers problems and the problems get resolved.  For
example, that's was RFC Errata are for.

In the current case, this is a rather fundamental and persistent confusion in
the community about DKIM's "output".

The Signing specification states:

> 1. Introduction
> 
> DomainKeys Identified Mail (DKIM) defines a mechanism ...
>     permitting a signing domain to claim
> responsibility ...
> Message recipients can ...  confirm that the
> message was attested to by a party in possession of the private key for the
> signing domain.

and

> 1.1 Signing Identity
> 
> DKIM separates the question of the identity of the signer of the message from
>  the purported author of the message. In particular, a signature includes the
>  identity of the signer. Verifiers can use the signing information to decide 
> how they want to process the message. The signing identity is included as 
> part of the signature header field

This language declares that the result of a DKIM verification is an identifier 
that declares some responsibility.

The question, now, is which string represents that identifier?

The fact that there are serious, knowledgeable folk who declare it is the d= tag 
and other, equally serious and knowledgeable folk who declare that it is the i= 
tag, and that there are substantial numbers of each means that we have a real 
and basic problem:

           The community does not currently have consensus about
           where to find the one value that is DKIM's output!

This is not something that can get resolved by fiat, Steve, such as saying that 
a prior decision by the working group resolves the matter.  And it is not 
something that gets resolved by one or another person pointing to some other 
language in the Signing spec and declaring that it provides the one true answer.

If the real world has competing interpretations of the spec, then the spec will 
not be used in a consistent matter.  And it's difficult to find a more serious 
problem with a specification, since it means that the core semantic has 
ambiguous interpretation.

What we are seeing, now, is that work on ADSP is (again) surfacing this basic 
confusion.

Approving ADSP, in the absence of resolving this basic confusion about what 
value to use, merely entrenches the confusion further.

It doesn't actually resolve it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 07 Jan 2009 17:18:07 -0000

> would assert that it has a DKIM problem more than an ADSP problem.

Ietf is no different from any other domain. It is entitled to choose, in  
its ADSP policy, either 'unknown' or 'all' or 'discardable'.

If it chooses 'unknown', then the list manager might adopt the (very  
sensible) policy of signing all list submnissions with 'i=[email-masked]'  
(Note that 'lists@' would probably be more sensible than Jim's original  
'ietf@'. I would not expect receivers to be particularly concerned about  
the presence or absence of this signature, but individual recipients might  
like to inspect it if a message appeared suspicious.

But if it chooses 'all', or even 'discardable', then the ietf chair (whose  
real name might be 'john') would have to arrange to submit his messages  
via the ietf server if he wished to use the From line [email-masked]'.  
More often, he would send it fron his own domain with a From line such as  
[email-masked]', in which case the signing policies of  
example.com would apply. But if his message is sent to the list, it would  
still attract an (additional) signature with [email-masked]'. Receivers  
would treat any other signature according to the example.com policies.

Note that, if john did choose to use 'From: [email-masked]', then it would  
probably attract two signatures. Moreover, if he was foolish enough to  
sent it via example.com's servers, then Receivers ought to be treating it  
with suspicion.

As to whether the list manager ought to be rejecting messages that already  
appear bogus, that is a separate issue (though one might expect list  
members to be aware if his policy). It is not covered by any of our  
present drafts.
> whether it DKIM signs, uses ADSP or does anything else..

If ietf asserts 'all', and the message sent to the list by the chair using  
the example.com server, and which receivers _ought_ to have treated as  
suspicious, passes the through on account of the list manager's signature,  
then indeed you may have identified a valid point. But it is a point that  
none of our drafts covers, nor was intended to cover, so I don't see it as  
a reason for mucking about with it at the present time. It belongs to some  
future Lists draft.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 7 Jan 2009 13:46:03 -0500

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Charles Lindsey
> Sent: Wednesday, January 07, 2009 12:18 PM
> To: DKIM
> >> [email-masked], which is of course unsigned.  The message coming
out
> > of
> >> the list looks like it has an author signature.  I have a problem
with
> >> that.

I absolutely agree. People can choose to do whatever they want. Remember
though, that inherent in the right to make choices is the right to make
suboptimal choices.

> like to inspect it if a message appeared suspicious.

If one chooses unknown I would question what one is doing with ADSP in
the first place.

> would treat any other signature according to the example.com policies.

No, because [email-masked] is not the From (if I follow you correctly)
then that signature is irrelevant from an ADSP perspective assuming that
the list doesn't rewrite the from line.

> members to be aware if his policy). It is not covered by any of our

That was exactly my point. The issue has nothing to do with DKIM other
than the list manager is choosing to take responsibility for the message
by signing.

> a reason for mucking about with it at the present time. It belongs to
some

My point was that if someone is implementing ADSP then they need to
exercise due diligence and care in both their initial overall messaging
implementation and in their ongoing operations. 

Receivers will do what receivers choose to do. They will whitelist,
blacklist, greylist, reputationalize, spam folderize, spindle and
mutilate. The sender cannot force them to do any particular thing. John
would at this point invoke King Canute.... I do so preemptively. 

I don't think this is something a draft will fix. It's called think
about what you are doing.

Just my 2 cents. I might be a bit slow with any additional responses
this week due to operational overload.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 7 Jan 2009 13:49:16 -0800

On Jan 6, 2009, at 6:06 PM, MH Michael Hammer (5304) wrote:

>> signatures on incoming messages, even from its own domain (there's  
>> no requirement that they do).  Someone spoofs a message from
>> out of the list looks like it has an author signature.  I have a  
>> problem with that.

An ADSP signature represents the Domain of the Author, and not that of  
the Author.

> would assert that it has a DKIM problem more than an ADSP problem.

Since the From is always included within a DKIM signature, when just  
d= compliance is required, it remains a matter of signing policy as to  
which message is signed by the domain.  If they have asserted that all  
of their email is signed, then proper list operation should not  
require a signature unable to indicate for which entity the message  
had been signed.  The signature should not be forced to affirm a From  
email-address, as might be the case with mailing lists.  The more  
fundamental aspect as to how an acceptable ADSP signature is defined,  
and whether it changes the RFC4781's definition for the i= parameter.

> Either the message has a valid signature or it does not. If there is  
> a valid signature then ietf.org is claiming responsibility. If it  
> doesn't have a valid signature....then not so much. If ietf.org is  
> sending out spoofed messages spoofing a "from" then it has a problem  
> regardless of whether it DKIM signs, uses ADSP or does anything else..

This of course would only be a problem when the domain used within the  
mailing list corresponds to the same domain as used by a mailing  
list.  When the i= does not match with that of the From, it should be  
obvious the signature is not indicating prior authentication of the  
 From entity.
...

>> The d=/i= distinction was originally created to simplify key  
>> management by domains having many subdomains, in that they could  
>> publish the keys in a parent domain (d=) while signing for a  
>> subdomain (i=).  You're basically suggesting that we abandon that  
>> optimization so that we can use the d= domain  rather than the i=  
>> domain for ADSP.
>
> I'm too tired to wade back through the list to find the discussion  
> that included statements from receivers that for the most part the  
> finer granularity desired by some senders was not necessarily useful  
> from the receiver perspective. I'm not going to argue with  
> receivers. I sign email with DKIM because it helps them identify  
> legitimate mail from our domains vs the spoofed mail. For my use  
> case I try to keep it as simple as possible.

I do not agree that by not restricting the use of the i= parameter,  
beyond what is already required by RFC4871 when assessing ADSP  
compliance, abandons any optimization.  The i= parameter will still  
allow the signature to communicate for which entity was the signature  
added.  In the normal range of email, there will be cases where a  
message is not introduced by one of the entities found within the From  
header field.  Basing compliance upon the d= parameters matching still  
allows the domain to determine what email they are willing to sign,  
and importantly, indicate on whose behalf the signature was applied.   
(The original definition of the i= parameter.)  I tend to agree with  
Michael more than Jim on this topic.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Jan 2009 12:33:48 +0000

Hi Dave,

I think you're making a reasonable point below about 4871.

Dave CROCKER wrote:
> 
> 
> Stephen Farrell wrote:
>> I don't believe this discussion is necessary in order to progress the
>> ADSP draft, which, for better or worse, is where the WG's rough
>> consensus ended up.
> 
> 
> Stephen,
> 

Right. So if there's a significant concern (and I'm not sure how many
people share the concern) then I'd expect a thread on here aimed at
generating another erratum for 4871. My guess is that folks who are
ok with the status quo are likely to be silent, so I'd expect those
who are concerned to push that a bit.

>>  identity of the signer. Verifiers can use the signing information to
>> decide how they want to process the message. The signing identity is
>> included as part of the signature header field
> 
> 
> This language declares that the result of a DKIM verification is an
> identifier that declares some responsibility.
> 
> The fact that there are serious, knowledgeable folk who declare it is
> the d= tag and other, equally serious and knowledgeable folk who declare
> that it is the i= tag, and that there are substantial numbers of each
> means that we have a real and basic problem:
> 
> This is not something that can get resolved by fiat, Steve, such as
> saying that a prior decision by the working group resolves the matter. 

I don't think that noting that a spec (4871) that's been through
all our processes says "foo" is resolving anything by fiat, but
whatever.

> And it is not something that gets resolved by one or another person
> pointing to some other language in the Signing spec and declaring that
> it provides the one true answer.
> 
> If the real world has competing interpretations of the spec, then the
> spec will not be used in a consistent matter.  And it's difficult to
> find a more serious problem with a specification, since it means that
> the core semantic has ambiguous interpretation.
> 
> What we are seeing, now, is that work on ADSP is (again) surfacing this
> basic confusion.
>
> 
> Approving ADSP, in the absence of resolving this basic confusion about
> what value to use, merely entrenches the confusion further.
> 

Could be. However, I don't think we need to halt all progress on ADSP.
We can and should clarify ADSP (e.g. as requested by Pasi) and then if
it turns out that a new erratum on 4871 is agreed, we may or may not
need to revisit something in ADSP.

Given where we're at in the process for ADSP, I would have thought that
those who feel that i=/d= needs clarifying in 4871 would try resolve
that as a matter of (relative) urgency. Otherwise ADSP is likely to
be in Pasi's queue for a long time.

Stephen.

---

From: Byung-Hee HWANG <[email-masked]>
Date: Mon, 19 Jan 2009 03:18:16 +0900

Stephen Farrell wrote:
[...]
> be in Pasi's queue for a long time.

Hello Stephen and Dave, i'm not professional about Internet Draft. 
However, totally i agree with Stephen's opinion.

And I know that reappraisal about RFC4871 is tired. But i'm sure that 
the reappraisal *will* make more perfect ADSP ;;

byunghee