Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Lawrence Conroy]

Hi Scott, folks,
 with due deference to Joe Touch & Bill Manning, whenever I have 
created/requested publication of an I-D, it never occurred to me that I was 
actually withdrawing the rights I had signed up to after six months (i.e., 
insisting on removal). That seems a novel reading of the boilerplate/2026.

There were times people have had to refresh a draft before it disappeared (with 
precious few changes), just to keep them published.
That always struck me as bonkers, and am roundly happy that/if expired drafts 
don't evaporate with the season.
I can't be alone in this -- these docs may not be current, but having a trail 
of drafts NOT take up gigabytes on [some] people's hard drives is good.

As for Scott's comments/efforts to have an expired-draft directory -- amen to 
that, for both reasons.
(I hadn't realised that Steve had just about done this; good chap, who's sorely 
missed).

It is VERY useful to be able to search through drafts to see how we got here, 
AND to see things that were explored and abandoned.
It's also useful to be able to check when things were published relative to 
applications; having that information potentially go away was/is a nuisance.

IMHO:
If authors insist, OK -- the expired draft is toast (although it being replaced 
by a published note that it has been deleted would be good).
Otherwise, why would/should the IESG decide to remove a document?

... which is a long way of saying: +1

all the best,
  Lawrence



On 14 Sep 2012, at 16:21, Bradner, Scott wrote:
> I don't think that the Note Well note has much to do with what Joe started 
> talking about
> 
> we have had this discussion before
> 
> quite a few years ago (pre tools) I suggested moving "expired" IDs to an 
> "expired IDs" directory
> rather than removing them from the IETF public repository as well as posting 
> all the old
> expired IDs in the same directory (changing only the filename to prepend 
> "expired-")
> 
> seemed like a good idea to me & to many other people, for the reasons people 
> find the tools ID archive
> useful & the IESG at the time said to move ahead
> 
> Steve Coya started the (long) process f pulling the old IDs from backup tapes 
> 
> as he was finishing that process a new IESG was seated and the new IESG was 
> not as in 
> favor of the idea and wanted a fuller mailing list discussion (there had been 
> a short
> discussion when I proposed the idea)
> 
> there were a few people (Joe was one) that felt that IDs were published under 
> the rights implied
> in rfc 2026, which said that IDs expired, and, thus, the IETF did to have the 
> right to not remove them
> (there fact that other repositories existed did not change the IETF's rights 
> in their opinion - in at least
> one case someone (I think Bill Manning) sent letters to some of those 
> archives asking that their 
> ID be removed)
> 
> with support from the then IETF lawyer, I suggested that there be a way for a 
> ID author to
> request that their ID be removed from the expired IDs directory but that idea 
> did not carry the
> day and the expired IDs directory idea died
> 
> then, at some later point, the tools function showed up - I do not think I 
> was still on the 
> IESG at that point so I do not know if the IESG discussed the question
> 
> I think this is a very useful service (for history of how the technology 
> evolved 
> and for prior art searches in patent cases) and think that pretending that 
> anything 
> published on the Internet ever quite goes away is not realistic.
> 
> Scott
> 
> 
> 
> On Sep 14, 2012, at 1:35 AM, Joe Touch  wrote:
> 
>> Note well, as you noted well, does not go back to the beginning of all IDs.
> 

WiFI and authentication

[Lawrence Conroy]

Hi Folks,
 whilst everyone is on the topic of WiFi ...
Now that the meeting in the PRC is over, is there any
intention to continue the WiFi authentication shenanigans?
[802.1X stuff, entering the magic number on your badge, ...]

That seemed to be another added complexity @ Maastricht, so
I'd prefer this to disappear.

If this business IS to be continued, why?

all the best,
  Lawrence

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [79all] IETF Badge

[Lawrence Conroy]

Hi Ole, folks,
 I missed it -- the IETF fee includes lunch now?
The IETF meetings have often had badge police on the food.
So .. were you referring to that, or anyone being allowed into the meetings?
[Requirement to fill in Blue sheets is an entirely different topic to barring 
entry]

all the best,
  Lawrence

On 13 Nov 2010, at 00:19, Ole Jacobsen wrote:
> Oops, sorry you did ask more than one question. This one:
> 
> "What I asked was whether or not the decision to require a strict 
> mapping of badge to person was an IAOC decision or the host/hotel/someone 
> else? 
> You sort of indicate that it was "the local host" and the (paraphrasing here)
> "cultural artifact".  But then go on to "its no big thing"
> 
> Prior to the day pass experiment (and I would guess even during) 
> companies would pass around badges for folks that wanted to attend - 
> especially local first timers, but didn't need to be there for more 
> than a day or a meeting.  As far as I know we (IETF) have no policy on 
> this."
> 
> Answer (my own opinion): We may not have a policy that states you 
> cannot pass around a badge to a number of people, but I think it 
> violates the spirit of "no free lunch" particularly now that the 
> meeting fees are a significant source of income to balanace the 
> meeting expenses. Ditto (obviously) for day passes. Buying one and 
> sending 5 people clearly defeats the purpose.
> 
> (I think the registration page says that you can send a substitute, 
> but that's a different matter).
> 
> Ole

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [79all] IETF Badge

[Lawrence Conroy]

Hi Ole, folks,
 That woke me up.
I'm not a registered attendee of the Beijing meeting.
BUT ...
1. The suggestion this is run like a RIPE meeting seems out of place
   -- I had thought this was the IETF.
2. In the 14 years I have been going to IETFs, there has been a badge
   police of varying competence on two main areas; food/refreshments
   and the terminal room.
   I have NOT seen badge police blocking access to IETF WG meetings.
   In the past it has been amusing watching Hotel staff trying to work
   out whether or not the people walking in towards the meetings were
   derelicts off the street or nerds -- notably @ Wardman Park Hotel
   and @ Philly. But restricting access to WG meetings? Nah.

Do I think the introduction of badge police to control access to IETF
 WG meetings is a big deal? DAMN RIGHT.

Is this really the case now? If so, I must have missed the discussion.

all the best,
  Lawrence


On 11 Nov 2010, at 14:58, Ole Jacobsen wrote:

> 
> 
> On Thu, 11 Nov 2010, Samuel Weiler wrote:
> 
>> Thank you very much for the timely response.
>> 
>> 
>> "Why might it be a good idea?" is not the question of the week.  The question
>> of the week is about process and transparency.  And, apparently, whether we
>> allow the local host (or hotel) to dictate how we run our meetings.
> 
> *** Ole: See response from Henk and myself.
> 
>> 
>>> I cannot tell you at this stage if this was a hotel requirement, a host
>>> requirement (as part of their government approval to host this meeting) or a
>>> combination of both.
>> 
>> This is disappointing, if not distressing.  I asked the IAOC about this in
>> private mail on Tuesday morning -- at a normal meeting, surely three days
>> would be enough time to discern who was responsible and get a clear public
>> explanation.
>> 
>> Instead, the confusion just keeps growing.  Last night, we heard that it is a
>> host requirement.  Now we're apparently not sure if it's the host or the
>> hotel.
> 
> *** Ole: What's the confusion?  See previous response. Why does it 
> matter? Let's split the difference and call it a "local requirement"
> 
>> 
>> I will take this as explanation for why you did not push back on the 
>> host (or hotel) earlier, rather than as an attempt to start a 
>> conversation about the reasonableness of such a change in general.
>> 
>> You have now heard that others think this is a more serious matter.
> 
> *** Ole: Yes, I've counted one+one. Out of 1,338 registered attendees.
>> 
>> Given the absence of a credible explanation from the host (or hotel) and
>> consultation with the community, will the IAOC, as I called for in my earlier
>> message, please tell the host (or hotel) "we want to have a normal meeting"
>> and tell the guards to back down?
> 
> *** Ole: Why would we do that exactly? What part of this meeting is not 
> normal?
> 
>> 
>> -- Sam
>> 
>> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-iab-dns-applications - clarification re: Send-N

[Lawrence Conroy]

Hi Jon, Richard, Ray, folks,
 I've been looking though the DNS-applications draft, and I'm unsure on its 
underlying aim.

We've already discussed the potential for "ENUM-Ops" style work to put 
clarifications
on how ENUM and ENUM-like systems should be used. The fact that there has been 
little
on the appropriate mailing lists on that topic doesn't mean that task has been 
overlooked
(there have been other distractions :).

There is certainly a good reason to issue DNS application guidance now,
 and some of the features of DNS may not be what applications expect.
... BUT ...

Q: Are you arguing that some applications will make cacheing less effective and 
that this will be a problem?

Q: Are you arguing that over-use of DNS is generally a problem (e.g. due to 
lack of prioritisation of query processing)?

Q: Are you arguing that volume and size of data will unbalance intermediary 
cacheing servers and undermine their effectiveness/"hit rate"?

Q: Are you arguing that the size of RRSets will cause upstream servers to face 
difficult decisions in populating the answer and authority section of DNS 
responses?

Q: Are you arguing that the size of RRSets will force difficult decisions on 
upstream servers populating the additional section of DNS responses?

Q: Are you concerned that answers may vary depending on who's asking, and that 
this may damage the effectiveness of cacheing and/or the DNS infrastructure?

-- consider the Yahoo/Google (edns-client-subnet) proposals for 
Internet-answering resolvers to support CDNs better (dwarfing use in 
private/internal telecommunications data networks)
-- consider the Google opt-in scheme for IPv6 networks, giving different 
answers depending on whether or not the network is "known to work with" IPv6 
answers "correctly"+?
  +: see  for requirements



I believe that there ARE underlying issues with application use of DNS, and so 
guidance is definitely needed.
I'm however not convinced that the current draft chooses the best exemplars of 
these issues.

*  Frankly, the dynamism of the telecommunications data set is low (as you all 
know).
 The queries are susceptible to cacheing (or the systems WILL be designed to 
cope, where that is not a valid assumption).
(ASSUMING OF COURSE THAT "in-use" STATUS IS NOT TO BE REFLECTED IN DNS. No-one 
has ever suggested to me that fine grained presence data should be in DNS, yet 
that seems to be the only valid coherency concern).

*  Telecommunications data is under the control of those provisioning the data 
into DNS;
 For Telecommunication data provisioning, synchronisation seems to be an issue 
only of appropriate TTLs.
 Dynamic update DNS services already face this issue and deal with it.
 - "Applications should consider data dynamism and DNS synchronisation" is an 
eminently valid guideline, but ISPs' dynamic address assignment and third party 
Dynamic DNS services would seem a more appropriate example.

*  The size of ENUM answers is subject to the same restrictions as other users 
of DNS.
 Performance may will be helped by support for EDNS, but this is needed for all 
users of DNSSEC.
The approach used already (for example) for gmail.com's MX records has NOT been 
proposed for public ENUM use.
It's unclear if the concern over size raised in the DNS-applications draft will 
be misinterpreted as advice for people to apply such "techniques" to ENUM 
answers provided on the Internet.

*  The number of queries in a valid chain is limited; there simply aren't that 
many queries that need to be made for communications-related data.
 "Communications" may involve more than just application server addresses, but 
it IS limited.
 The new version of the ENUM standard has recommended "loop control" (see 
draft-ietf-enum-3761bis-09.txt, ends of sections 5.1 and 5.2),
 and has a recommended mechanism for "leakage control" (ibid, 3.4.3.1).
 Thus the concerns over long chains and leakage raised in the IAB-applications 
draft seem outdated, at least as far as ENUM is concerned.

Maybe it's just me, but I want a good guidelines document (so we don't HAVE to 
work so hard for an ENUM-specific set :),
but I'd like the guidance to spell out answers to the six questions above, or 
cover them more clearly.
At present I'm just guessing.

all the best,
  Lawrence


On 21 Oct 2010, at 05:11, Peterson, Jon wrote:
> As tempting as it is to join the cries of "imminent death of the PSTN 
> predicted," I wanted to drill down at some length into Ray's question on 
> send-n and some of Rich's comments.
> 
> Regarding send-n, the argument made by the dns-applications draft today is 
> that the synchronization required to coordinate different levels in the DNS 
> tree with the state of resources in the telephone network creates a 
> fundamental brittleness in this architecture. It is presented in those terms 
> to try to abstract out the architecture principle rather than staying 
> strictly within the particulars of 

Re: draft-iab-dns-applications - clarification re: Send-N

[Lawrence Conroy]

Hi folks,
What you're saying is that you are not the target customer for this stuff.
I would guess that few people on this list are either.

That does not however mean that a few billion users around the world mostly
use smartphones or PCs; either that or I have missed the heaps of 12 digit
phones at landfill sites, or bulging re-cycling warehouses.

Everyone MOSTLY calls from a small contact list, and the same holds for the
group of people who call them. The goal is to support them when they don't.
I don't know how long a phone number in Marrakech should be. Rather than
place an International call to find out I've missed a digit, I would like
a scheme to help me, ideally before I even get into the voice application.
I guess I could use google, but that is too Web 2.0 for my taste or patience.

As for overlap signalling being obsolete -- it depends on your definition.
I'm pretty sure every equipment provider would be VERY happy if big Telcos
removed the requirement, and the requirement to continue to support it for
years. EnBloc dialling has definite benefits, but until landlines ALL go
away we're stuck with digit-by-digit dialling.

I'm AssUMing that you are not suggesting that the IETF is s slow that
by the time anything is specified, we'll all be using wristwatch mobiles?

all the best,
  Lawrence

On 21 Oct 2010, at 12:57, Phillip Hallam-Baker wrote:
> It is quite possible and rather likely that the PSTN will disappear but the
> numbering system will not.
> 
> Telephone numbers have a major advantage of being able to be dialed from a
> 12 button keypad without kludges. China and other countries that
> have syllabaries rather than alphabets are likely to prefer numbers as a
> naming system since they use a limited character set that can be expressed
> directly on a keyboard.
> 
> 
> What I expect to disappear is digit-by-digit dialing. Telephone numbers are
> only dialed digit by digit by the user in exceptional cases today. The need
> to support efficient dialing in this fashion seems to arise as an artifact
> of a poorly integrated system.
> 
> 
> 
> 
> On Wed, Oct 20, 2010 at 10:51 PM, David Conrad  wrote:
> 
>> On Oct 20, 2010, at 5:28 PM, Masataka Ohta wrote:
>>> Richard Shockey wrote:
 So what is your point ..you don't use phone numbers so the rest of the
 planet shouldn't?
>>> 
>>> As PSTN will disappear, E.164 will also disappear, because there
>>> will be no PSTN operator to maintain E.164 number space.
>> 
>> "In the long run, we're all dead" -- John Maynard Keynes
>> 
>> In the intervening decades, it is probably worthwhile dealing with the
>> reality that PSTN (and hence E.164) exists.
>> 
>> Regards,
>> -drc
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Lawrence Conroy]

Hi Cullen, folks,
 It seems to me ...
There have been a number of cases where things are not developed  
within the IETF

but are "out there".
Whether or not folk LIKE those schemes/the companies that promulgate  
them/the author(s)

/the document style/the weather is not really important.
Having an Informational RFC to describe these protocols or file  
formats is useful.

If nothing else, it tells you what the heck is going on down the wire.
IF the IESG wants to tag on a comment that the described protocol/ 
format is broken
or conflicts with a more sensible IETF-anointed approach, it can and  
does.


I support this as an Informational document. I would like this  
description out now.
Burying it in a WG to try (and fail) to turn this into an IETF  
standards-track
document is not helpful. I fear that someone will go postal if we do  
Zeroconf again.
There has been So much history that it is simply not worth  
repeating the pain.

(I seem to recall discussions on this starting out @IETF-41 in LA,
 since which time it's in very wide use "out there" :).

Please can we ship this as an Informational, and soon?

all the best,
  Lawrence

On 18 Nov 2009, at 15:41, Cullen Jennings wrote:
Can someone walk me through the pro/cons of this being standards  
track vs informational?


Thanks, Cullen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Non-smoking rooms at the Hiroshima venue?

[Lawrence Conroy]

Hi Dave, folks,
 Don't count me in.
After freezing my fingers off in MSP, that's a plus point about Japan.
At least this time I have a choice. So, apparently, do you.
all the best,
  Lawrence

On 1 Sep 2009, at 08:52, David Partain wrote:

Greetings,

I just set about to reserve a room at the meeting hotel via
http://www.ichotelsgroup.com/h/d/cp/1/en/cwshome/DPRD-7LT5AJ/HIJJA  
(which
required that I join their PriorityClub...).  Check-in on Saturday,  
check-out
on Friday (nothing odd there).  I was, though, VERY surprised that  
there are

no non-smoking rooms available.  All I got was:

1 SINGLE BED STANDARD SMOKING at ￥13,500.

If I want non-smoking, I seem to have to pay 23,000 and have 2 beds.

Is this other's experience as well?  While I can survive a smoking  
room, I'd
really rather not.  I haven't tried calling, so perhaps that's the  
solution.


Can anything be done to get us some non-smoking rooms since I  
suspect that's

what almost everyone wants?

Cheers,

David


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Enum] Last Call: draft-ietf-enum-3761bis (The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)) to Proposed Standard

[Lawrence Conroy]

Hi IESG members, folks,
 I'm one of the authors of the draft, so this is rather odd. But...
as per request, I'm pushing this issue as a comment into the IETF
LC/IESG review for draft rfc3761bis. This has an error that should be
fixed and has caused confusion.

draft rfc3761bis-04 inherits a lot of text directly from rfc3761.
In particular, the DDDS application template specifications covered in
rfc3761bis-04 sections 2.1, 2.2, 2.3 and 2.4 define respectively the
Application Unique String (AUS), the First Well Known Rule, expected
output of this application, and the Rules database & the way that
record fields are used. Unsurprisingly, large chunks of this came
straight from rfc3761.

Unfortunately, these sections include a bug that has been present since
rfc3761.

ENUM (as defined in rfc3761 and in rfc3761bis) is a DDDS application,
and so has to fit within the DDDS framework.

DDDS states that the "First Well Known Rule" is used to turn the AUS
into a key that is used to query the database.
Unfortunately, rfc3761 describes this as identity -- given that the AUS
is a string holding a telephone number, this is NOT going to produce a
suitable domain name. It was wrong then and rfc3761bis-04 inherits this
error.

rfc3761 then goes on to describe how keys into the database are used;
it shows how a telephone number can be converted into a domain name
that can be queried in DNS. For most cases the two steps will cancel
out each other's errors.

However, non-terminal NAPTRs generate domain names that are then
queried to get the "next round" of NAPTRs. If the steps described in
the database section are applied to those domain names then the result
will not be what was intended -- in effect, it reverses the telephone
number as it re-constructs an "ENUM domain".

What *should* be present is a description of the first well known rule
that does create a domain name (i.e. including the steps currently in
the database section), and the database section should just refer to
rfc3403 -- this database is the DNS and is unsurprisingly used as
expected, i.e. domains are queried for NAPTRs, and those NAPTRs hold
DDDS rules.

This is a relatively simple bug fix, has no impact at all on the vast
majority of ENUM systems that do not hold or use non-terminal NAPTRs,
whilst permitting ENUM to work correctly with non-terminal NAPTRs where
it is, at best, ambiguous at present.

Proposed text for this fix can be found in:
.

That text should replace the existing section 2.1 through to the end of
section 2.4. The main changes are to sections 2.2 and 2.4 (which loses
the misplaced 2.4.1 and so subsequent sub-sections are renumbered).

Finally, is it worth raising an erratum against rfc3761 as well, when
rfc3761bis is intended to replace it and can incorporate this fix RSN?

all the best,
  Lawrence

On 26 May 2009, at 15:12, The IESG wrote:

The IESG has received a request from the Telephone Number Mapping WG
(enum) to consider the following document:

- 'The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
  Discovery System (DDDS) Application (ENUM) '
   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-09. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Lawrence Conroy]

Hi Brian, folks,
 Having just recovered from the heat in Paris...
IIUC, Microsoft would be free to put in an application for .local if  
it is so all-fired important to them.
Also, if I've decoded the slightly delphic comments correctly, the  
bidding war with Apple might be fun.
Finally, the lawyers of Thomson Local Directories in the UK might be  
interested and raise an objection.


I'll believe it has become a problem when the RFP, evaluation and  
objection process have been ->finalised<-, the evaluations have been  
done, and any agreement has been signed. It could take some time...)


all the best,
  Lawrence
(speaking personally)

On 27 Jun 2008, at 22:39, Brian E Carpenter wrote:

I think all the external evidence is that ICANN is deeply reluctant to
set up mechanisms that require the application of common sense (a.k.a.
judgment) as to whether or not a particular domain name may be  
registered.

I see no reason to expect this to be different now they have opened
the floodgates to greed at the TLD level too. So I think that any such
technical review process is doomed. The best we can do is proceed
under the second paragraph of section 4.3 of RFC 2850, i.e. designate
specific TLDs as reserved for technical reasons, and so instruct IANA.
Furthermore, I believe this is not only the *best* we can; it's
essential that we do so, although translating 'example' into every
script and language may be going a bit too far. So I believe that
2606bis is very necessary.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

SHOULD vs MUST (was Re: Review of draft-ietf-geopriv-http-location-delivery-07)

[Lawrence Conroy]

Hi Eric, folks,
 [renamed for this specific point, and CC list trimmed]

I am puzzled by this point in your review.
I suspect that other potential authors will be too.
To me, the last sentence is exactly right:
the SHOULD means "do this unless...",
and the last phrase covers the "unless".

I had read 2119 to mean that a MUST was unconditional
- do this or be non-complaint.
Do you believe that MUST can have an "unless" clause?
Doesn't this mean that any SHOULD with an explicit "unless" will
need to be changed into a MUST - could you expand on this, please?

all the best,
  Lawrence

On 20 Jun 2008, at 20:59, Eric Rescorla wrote:

  The LIS MUST implement the server
  authentication method described in [RFC2818]. When TLS is used,
  the Device SHOULD fail a request if server authentication fails,
  except in the event of an emergency.

Does that address your concerns?

Why did this become a SHOULD when it was a MUST?


___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Enum] DRAFT-ALLOCCHIO-GSTN-02.TXT Updated version

[Lawrence Conroy]

At 10:36 am +0100 22/2/02, Claudio Allocchio wrote:
>Hallo,
>
>here is the updated version of DRAFT-ALLOCCHIO-GSTN-02.TXT, which
>includes, as the only difference from the previous one, an "implementer's
>note" regarding 'pause' and 'tonewait' which was suggested as helpful.
>
>As mentioned in the first release of the draft, "the intention for this
>document is to provide a unique syntax for Dial Sequences, including
>expecially phone numbers as a subset. The definitions contained in the
>draft actually come from existing Draft Standard and Proposed Standard
>specifications, but were collected here to provide a quick, easy and
>unique reference document for anybody needing this particualr encoding.
>The original idea comes from the Application Area Directors, and I made
>the collection and edited the I-D."
>
>I kindly invite you to provide me your comments and suggestions!
>
>Thank you all, and regards!
>
>Claudio Allocchio
>ietf fax wg co-chair

I am pretty bemused at this - I seem to have missed the earlier ones.
The Application ADs suggested it?

What exactly does this add to RFC2806?
It doesn't seem to update 2806, so I don't understand how I use this,
or where.

In particular, the phone-context stuff in 2806 is there for a good reason
- the phone string could well be sent to Finland (inside an email, for
instance). This is not going to work if one uses local phone string
format (with 001 to call the U.S.).

It doesn't seem to be in this draft, so perhaps a warning that this
will break unless you KNOW where the recipient will be dialling could
be (re-)added?

Hey, I'm sure you don't have anything else to do before 2300 MET, right? :).

BR,   L
-- 
[EMAIL PROTECTED]: +44 1794 833666:::