Subject: RE: [Ltru] Re: Summary of comments, draft-ietf-ltru-matching-07

From: "Addison Phillips" <[email-masked]>
Date: Wed, 7 Dec 2005 09:18:42 -0800

+1

If we wish to go down the STD track:

1. I will need to modify the draft to indicate this.

2. We ought to find out what effect this has on the publication of 3066bis, since in theory that document is supposed to tandem with this one. I could see the two in tandem when both were BCPs, but one BCP and one STD?!? Incroyable.　Okay, maybe that's a bit too melodramatic...

3. We will (eventually) need to have implementations of each scheme. I think we'll want this sooner rather than later to demonstrate whether each scheme works the way we think it does.

Addison

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Duerst
> Sent: Wednesday, December 07, 2005 3:10 AM
> To: Frank Ellermann; [email-masked]
> Subject: Re: [Ltru] Re: Summary of comments, draft-ietf-ltru-matching-07
> 
> At 14:48 05/12/07, Frank Ellermann wrote:
>  >John.Cowan wrote:
>  >
>  >> That smells like a standards-track RFC to me.  Comments?
>  >
>  >+1
> 
> [as a technical contributor]
> 
> It seems to make sense to me, but I agree with Harald
> that in that case, we have to be considerably more
> precise (many less "MAY"s, even though I don't agree
> with Harald that we have to completely eliminate them).
> 
> Regards,   Martin.
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Thu, 08 Dec 2005 12:50:45 +0900

[chair hat on]

 >1. I will need to modify the draft to indicate this.

Yes. But that's very easily done.

 >2. We ought to find out what effect this has on the publication of 3066bis,
 >since in theory that document is supposed to tandem with this one. I could
 >see the two in tandem when both were BCPs, but one BCP and one STD?!?
 >Incroyable.　Okay, maybe that's a bit too melodramatic...

In my understanding, the main reason for the tandem is the obsoletion
of RFC 3066: The IESG/RFC Editor don't want to obsolete part of
RFC 3066 by publishing draft-registry without draft-matching.

 >3. We will (eventually) need to have implementations of each scheme. I
 >think we'll want this sooner rather than later to demonstrate whether each
 >scheme works the way we think it does.

Yes. As far as I understand, we already have implementations for
filtering with basic range (Apache HTTP), and we may have implementations
for lookup depending on how we end up with that. And if no implementations
come up, we will just have to drop that scheme when doing to Draft
Standard.

Currently, I understand Frank and Addison are for going the STD route.
Harald and me [as a technical contributor] seem to be okay with that.
What about others?

Regards,   Martin.