Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-06.txt

From: Margaret Wasserman <[email-masked]>
Date: Wed, 14 Mar 2007 08:33:22 -0400

BTW, I also see no indication that the document title change or the  
other last minute changes were discussed on the v6ops WG list.

Margaret

On Mar 14, 2007, at 8:29 AM, Margaret Wasserman wrote:

>
> Hi All,
>
> I would like to understand why the title of this document was  
> changed at the last minute.  I also have at least a minor objection  
> to the new title, particularly to what it means by the word  
> "protection".
>
> The word "protection" in the original title referred to protecting  
> the end-to-end Internet architecture (the network architecture)  
> from NAT.  In other words, we could use certain facilities in IPv6  
> instead of NAT as a way to protect the end-to-end nature of IPv6  
> networks.
>
> What does the word protection mean now, though?  That the  
> facilities in this document protect the local network?  From what?
>
> Margaret
>
>
> On Jan 11, 2007, at 3:50 PM, [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IPv6 Operations Working Group of  
>> the IETF.
>>
>> 	Title		: Local Network Protection for IPv6
>> 	Author(s)	: G. Van de Velde, et al.
>> 	Filename	: draft-ietf-v6ops-nap-06.txt
>> 	Pages		: 46
>> 	Date		: 2007-1-11
>> 	
>> Although there are many perceived benefits to Network Address
>>    Translation (NAT), its primary benefit of "amplifying" available
>>    address space is not needed in IPv6.  In addition to NAT's many
>>    serious disadvantages, there is a perception that other benefits
>>    exist, such as a variety of management and security attributes  
>> that
>>    could be useful for an Internet Protocol site.  IPv6 was designed
>>    with the intention of making NAT unnecessary, and this document  
>> shows
>>    how Local Network Protection (LNP) using IPv6 can provide the  
>> same or
>>    more benefits without the need for address translation.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-06.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] 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-v6ops-nap-06.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:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-v6ops-nap-06.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.
>> Content-Type: text/plain
>> Content-ID:	<[email-masked]>
>

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 14 Mar 2007 08:29:22 -0400

Hi All,

I would like to understand why the title of this document was changed  
at the last minute.  I also have at least a minor objection to the  
new title, particularly to what it means by the word "protection".

The word "protection" in the original title referred to protecting  
the end-to-end Internet architecture (the network architecture) from  
NAT.  In other words, we could use certain facilities in IPv6 instead  
of NAT as a way to protect the end-to-end nature of IPv6 networks.

What does the word protection mean now, though?  That the facilities  
in this document protect the local network?  From what?

Margaret

On Jan 11, 2007, at 3:50 PM, [email-masked] wrote:

>    exist, such as a variety of management and security attributes that
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Wed, 14 Mar 2007 13:56:53 +0100

The name change was the result of an IESG DISCUSS item from Cullen
Jennings on the believe that 'NAP' as a term 
was confusing for a variety of reasons. Middle ground solution was
elected and as result 'LNP' came out of pandora box (after an initial
change to NAP6).

The word 'Local Network Protection' refers to what is described in the
abstract. No change wrt to 'NAP'. 
This name change was discussed with [email-masked] and v6ops chairs in cc
(see 14th December 2006). 
(I can fwd you and any who wants to know the mail if you can not locate
it) 

Now after (exactly) 4 months... it is maybe a comment that should have
been spoken out loud 4 months ago when the suggestion for the name was
initially made.

There are many people and organisations waiting on this document to
become informational RFC, and I believe that we should aim to get the
document through the last step asap, and not re-discuss agreed items of
4 months ago. 

Groetjes,
G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Margaret Wasserman
Sent: Wednesday, March 14, 2007 1:29 PM
To: David Kessens; [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-06.txt 

Hi All,

I would like to understand why the title of this document was changed at
the last minute.  I also have at least a minor objection to the new
title, particularly to what it means by the word "protection".

The word "protection" in the original title referred to protecting the
end-to-end Internet architecture (the network architecture) from NAT.
In other words, we could use certain facilities in IPv6 instead of NAT
as a way to protect the end-to-end nature of IPv6 networks.

What does the word protection mean now, though?  That the facilities in
this document protect the local network?  From what?

Margaret

On Jan 11, 2007, at 3:50 PM, [email-masked] wrote:

> This draft is a work item of the IPv6 Operations Working Group of the 
> IETF.
>
>    how Local Network Protection (LNP) using IPv6 can provide the same 
> or

> logging in, type "cd internet-drafts" and then "get 
> draft-ietf-v6ops-nap-06.txt".
>
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Mar 2007 14:13:52 +0100

Hi Margaret,

Needless to say, I was recused from the IESG decision
on this draft, so what I say now, I say as an author.

The authors accepted the title change in response to
IESG comments that "NAP" or "NAP6" could too readily be
confused with "NAT", especially on the phone. I didn't like
the change personally, but didn't think it was confusing.

I agree that apparently there was no WG discussion after
the -05 and -06 versions appeared, although they were of
course announced to the mailing list, i.e. nothing was
hidden.

I just reviewed the diffs between the -04 and -06 versions.
I persnally think they're all editorial, with one possible
exception - this was deleted:

  At the same time a NAT creates a smaller pool of addresses for a much	 		
  more focused point of attack, where the adversary does not need to			
  scan the entire local network but can instead concentrate on the			
  active ports associated with the NAT adress. By periodically			
  scanning the limited 16 bit port range on the public side of the NAT,			
  the attack will routinely find all ports that are open to active			
  nodes.

because Cullen (I think) pointed out that it doesn't apply to the
majority of commonly deployed NATs.

      Brian

On 2007-03-14 13:33, Margaret Wasserman wrote:
>> at the last minute.  I also have at least a minor objection to the new 
>>>    with the intention of making NAT unnecessary, and this document shows
>>>    how Local Network Protection (LNP) using IPv6 can provide the same or

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Mar 2007 14:24:21 +0100

Gunter,

See my mail ... Margaret didn't see any of that email, since
it wasn't cc'ed to the WG list. So the question she's raising
is whether these were purely editorial changes (which often
happen without WG involvement) or whether they should have
been referred to the WG. That's a fair question to ask.

     Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 14 Mar 2007 10:19:23 -0400

Hi Brian,

I was quite surprised by a title change at this late date.  I still  
think that the old title made more sense than the new one, but I can  
live with the new title if it is okay with the rest of the WG.

> exception - this was deleted:

<snip>

I agree that the rest of the changes could be considered  
editorial...  However, in the aggregate, they seem (to my reading at  
least) to result in a slight shift in this document's position  
regarding the role and value of IPv4 NATs.  BTW, I personally think  
that those changes make the document much clearer, more accurate and  
more balanced, so I support them.

Margaret

---

From: David Kessens <[email-masked]>
Date: Wed, 14 Mar 2007 11:33:49 -0700

Margaret,

I believe you have received sufficient explanation from the authors
regarding these changes.

As far as me concerned, I believe they were mostly editorial. At the
same time, I agree that there were a few more changes than what I like
to see happening during IESG review and there were a few quite close
to being non-editorial. We (=me and workinggroup chairs) made the
judgment call that they did not have to go back to the working group
due to their editorial character and in the interest of getting
closure on this document. However, as with all cases where one has to
decide whether something is 'editorial but close to not being editorial',
different people might reach somewhat different conclusions. I hope
that you can see how we came to this judgment call however.

I hope this helps,

David Kessens
---

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 15 Mar 2007 19:21:41 -0400

Hi David,

Yes, the reasons for the title change were explained to me.  I don't  
fully understand why the IESG had a blocking problem with the  
original title, but I agree with the decision to change the title, if  
that was necessary to publish the document.

In general, it is hard for me to see how the IESG could have blocking  
problems with a document that could be addressed by purely editorial  
changes...  So, I'd prefer to see all discuss resolutions sent to the  
WG mailing list.  However, I'm reasonably happy with the results in  
this case, so I see no reason for further discussion.

Margaret

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Mar 2007 22:26:05 +0100

Hi Margaret,

I asked for this change because I did not think it was editorial - I  
was involved with several conversation where it introduced  
significant confusion to the conversation. There was certainly  
differences of opinions on how much confusion this would cause or if  
it would matter but I think it was pretty clear in the conversations  
that there were problems if we were talking about nat or nap - it got  
worse with speakers where english was not their best languages. I  
only asked for this to be changed because I thought it was causing  
confusion in exactly the community that most needed to understand  
this document and I believed the document would have a higher chance  
of meeting it's goals without this confusion. No one brought up a  
down side to changing the name other than the possible delay but we  
were making plenty of other changes and I don't think this introduced  
any additional delay.

I'm sure I make mistakes, if you think this is one of them, catch me  
over coffee at some break and we can talk about this.

Thanks, Cullen

On Mar 16, 2007, at 12:21 AM, Margaret Wasserman wrote:

>
> Hi David,
>
> Yes, the reasons for the title change were explained to me.  I  
> don't fully understand why the IESG had a blocking problem with the  
> original title, but I agree with the decision to change the title,  
> if that was necessary to publish the document.
>
> In general, it is hard for me to see how the IESG could have  
> blocking problems with a document that could be addressed by purely  
> editorial changes...  So, I'd prefer to see all discuss resolutions  
> sent to the WG mailing list.  However, I'm reasonably happy with  
> the results in this case, so I see no reason for further discussion.
>
> Margaret
>
>
>>> changed

---

From: David Kessens <[email-masked]>
Date: Fri, 16 Mar 2007 14:45:20 -0700

Cullen,

On Fri, Mar 16, 2007 at 10:26:05PM +0100, Cullen Jennings wrote:
> 
> I asked for this change because I did not think it was editorial 

With all due respect, the title change was a clarification to avoid
any confusion between this document and the term 'nat'. To me that is
editorial as it didn't really change the meaning of the document in
any kind of way.

Although I don't believe that this change was really necessary, I
agree that such an editorial change can be defendable from your point
of view: the IESG has a cross area responsibility and it is possible
to argue that while the difference is clear to the people within the
v6ops community, the term might easily cause confusion to the
larger public. To me it was more important to get the document out the
door than having a long discussion on an issue that can be argued
either way, but that in the end didn't fundamentally change the
document if we made the requested change.

David Kessens
---

> - I  

David Kessens
---

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Mar 2007 13:44:07 +0100

> document if we made the requested change.

I think it's unfortunate that this name change was made, as it doesn't
really capture the spirit of what the draft is about, and I know so many
people who know what NAP is now in the IPv6 context and who would not know
what LNP is.

I must admit I didn't notice the change immediately because the draft
retained -nap-06 rather than becoming lnp-00 or lnp-06.

The table in section 1 summarises quite nicely the perceived benefits of
NAT, of which 'local network protection' is one part, but not the whole
part.   In section 2, LNP really applies to 2.2 and maybe 2.4, but not so
much the other topics.  So I'm not convinced it's an appropriate 
alternative.

Maybe I'm alone, but I would like the IESG to consider reinstating the
original NAP name.   It's more appropriate, and is well-known within the
IPv6 community today.

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Mar 2007 08:38:26 -0700

> original NAP name.   It's more appropriate, and is well-known 

Seconded.

Fred
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Mar 2007 07:51:07 +0930

Hi,

On Mon, 26 Mar 2007 08:38:26 -0700

> > original NAP name.   It's more appropriate, and is well-known 

While I generally prefer NAP over LNP, I wonder if it is really
necessary to give this group of techniques a formal name. I think
giving it a formal name starts to imply a fixed set of techniques,
implying that there won't be additions to the set.

How about titling it "NAT alternatives when using IPv6" or something
similarly descriptive ?

Regards,
Mark.

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 26 Mar 2007 19:19:22 -0700 (PDT)

1) in 2.9 Default Route has only a statement about what ::/0 is. Any other Address
Type seems to have a guidance on how to treat it. Should Default Route have an
advertising statement similar to draft-ietf-v6ops-routing-guidelines-01.txt?  

2) how ::/128 is different from ::/0? if they are different how a router would know
looking at the packet?

Thanks,

Peter

____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Mar 2007 08:25:35 +0300 (EEST)

(FWIW, I think this version of the document is better.  The draft 
still has recommendations what should be filtered and I'm not sure if 
that's necessary, but those are mostly non-contentious prefixes..)

> advertising statement similar to draft-ietf-v6ops-routing-guidelines-01.txt?

I'd say that section 2.9 should be removed.  Default route is IMHO not 
a special address(-prefix) in any way.  How you want to treat it 
differs in each network both in IGP and BGP, so perhaps saying nothing 
is the right thing to do.

2.10 is somewhat incorrect on Multicast:

    ff00::/8 are multicast addresses [RFC4291].  They have a 4 bits scope
    in the address field.  Only addresses having the 'E' value in the
    scope field are of global scope, all other values are local or
    reserved.  Therefore, only ffXe:: routes may be advertised outside a
    site, where X may be any value.

'site-scope' multicast has the scope value '5' and the rest between 6 
through D are unassigned except for '7' (organization-local scope).

The document defines:

         scopes labeled "(unassigned)" are available for administrators
         to define additional multicast regions.

Therefore I think it would be an end run to say only 'E' should be 
acceptable because administrators are welcome to use anything higher 
than '5' in scopes greater than a site.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2007 08:42:25 +0200

As a co-author (and of course I was recused in
the IESG discussion) my main concern is to
see the RFC published ASAP. Despite having personally
invented the NAP acronym, I would prefer no further
change so that the RFC Editor team can do their job
as quickly as possible.

     Brian

---

From: Remi Denis-Courmont <[email-masked]>
Date: Tue, 27 Mar 2007 9:56:32 +0200

On Mon, 26 Mar 2007 19:19:22 -0700 (PDT), Peter Sherbin <[email-masked]> wrote:

> 2) how ::/128 is different from ::/0? if they are different how a router

> would know looking at the packet?

Well, that would be pretty easy. If a router sees a packet whose destination is ::, it matches ::/128, otherwise it matches ::/0. Longest-prefix match first.

I think packets with :: as destination are invalid by the way, so it may make sense for a router to check it.

--

Rémi Denis-Courmont

http://www.remlab.net/

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Mar 2007 08:44:12 -0700

> see the RFC published ASAP.

Seconded.

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 Mar 2007 17:14:38 +0100

> > see the RFC published ASAP.

Very happy to defer to Brian's wishes.   The document has been widely
cited as a draft of course, but final publication will make it even easier
to point people at.    I suspect we'll end up referring to is by RFC
number rather than name as it'll be easier to say (like 2775 or 3041).

[BTW if NAT can apparently be confused with NAP in discussion, I wonder
 whether LNP's other common meaning will cause confusion that the draft
 formerly known as NAP has something to do with number portability for
 IPv6]

-- 
Tim

---

From: [email-masked]
Date: Tue, 27 Mar 2007 10:35:58 -0600

>  formerly known as NAP has something to do with number portability for

This is one of the reasons that I was not happy with the new LNP name. I was 
afraid that it might be confused with renumbering networks or local number 
portability - both of which are out of scope for this working group. 

On the other hand I know that the IPv6 Forum is already talking about the 
draft and is eagerly awaiting publication as an RFC so it can be made into a 
white paper and used in business cases. An RFC number is more impressive 
than a draft. 

But right now the important thing is to get it published.

---

From: james woodyatt <[email-masked]>
Date: Tue, 27 Mar 2007 10:21:48 -0700

On Mar 26, 2007, at 23:42, Brian E Carpenter wrote:
>
> As a co-author (and of course I was recused in the IESG discussion)  
> my main concern is to see the RFC published ASAP. [...]

As a member of the community who will have to live with the text of  
this RFC until it can be obsoleted by future revisions, I'd like to  
suggest that the co-author's desires to see the document published as  
quickly as possible should be secondary to concerns from the working  
group that the RFC not be misleading.

-- 
james woodyatt <[email-masked]>
member of technical staff
apple computer, inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2007 08:49:31 +0200

On 2007-03-27 19:21, james woodyatt wrote:
>> As a co-author (and of course I was recused in the IESG discussion) my 
>> main concern is to see the RFC published ASAP. [...]
> 
> As a member of the community who will have to live with the text of this 
> RFC until it can be obsoleted by future revisions, I'd like to suggest 
> that the co-author's desires to see the document published as quickly as 
> possible should be secondary to concerns from the working group that the 
> RFC not be misleading.

I don't believe the new title is misleading. If you read Cullen Jenning's
original DISCUSS comment, he felt strongly that the old title was
misleading.

     Brian

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Mar 2007 08:58:26 +0200

On Mar 27, 2007, at 7:21 PM, james woodyatt wrote:
>> As a co-author (and of course I was recused in the IESG  
>> discussion) my main concern is to see the RFC published ASAP. [...]
>
> suggest that the co-author's desires to see the document published  
> as quickly as possible should be secondary to concerns from the  
> working group that the RFC not be misleading.

Do you feel that the document is misleading? That is something I have  
not heard the working group say.

Keep talking...?

---

From: james woodyatt <[email-masked]>
Date: Wed, 28 Mar 2007 11:18:47 -0700

On Mar 27, 2007, at 23:58, Fred Baker wrote:
>> As a member of the community who will have to live with the text  
>> of this RFC until it can be obsoleted by future revisions, I'd  
>> like to suggest that the co-author's desires to see the document  
>> published as quickly as possible should be secondary to concerns  
>> from the working group that the RFC not be misleading.
>
> Do you feel that the document is misleading? That is something I  
> have not heard the working group say.

I do think the document needs editorial changes to keep from  
misleading readers.  I have no technical objections to the  
informational content of the document, and I'm in full support of its  
publication as an Informational RFC.  It's the editorial content of  
the document to which I'm objecting.

> Keep talking...?

Please review my messages on 2007-03-12 and 2007-03-13 and the thread  
of related discussion.

	<http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00055.html>
	<http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00062.html>

I don't have anything to add to those remarks at this time.  I  
apologize for not providing these comments at an earlier date, but I  
have only recently joined the working group.  I raised the issues as  
soon as they came to my attention.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Mar 2007 08:49:13 +0200

I'm sorry, but we've had WG Last Call, IETF Last Call,
and extensive IESG discussion, and the document has been
approved by the IESG. We are done.

I already observed in response to James that using
lower case 'should' in an informational document is
entirely reasonable, and I didn't think his quibble
about 'can' in his second message was worth comment.

Also his comment about "If an informational RFC is
to be a vehicle for expressing the opinions of its authors"
is irrelevant; it is a WG document that states its purpose
very clearly.

I object violently to any further editorial nit picking.

    Brian

On 2007-03-28 20:18, james woodyatt wrote:
> I do think the document needs editorial changes to keep from misleading 
> readers.  I have no technical objections to the informational content of 
> the document, and I'm in full support of its publication as an 
> Informational RFC.  It's the editorial content of the document to which 
> I'm objecting.
> 
>> Keep talking...?
> 
> Please review my messages on 2007-03-12 and 2007-03-13 and the thread of 
> related discussion.
> 
> I don't have anything to add to those remarks at this time.  I apologize 
> for not providing these comments at an earlier date, but I have only 
> recently joined the working group.  I raised the issues as soon as they 
> came to my attention.
> 
> 
> --james woodyatt <[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Thu, 29 Mar 2007 08:31:30 -0700

> I object violently to any further editorial nit picking.

My sincere apologies all around for giving the authors of this fine  
document cause to feel defensive.

It was never my intention to arouse any hostility.  I simply thought  
it was possible that the authors were very smart and busy people who,  
in a moment of completely understandable oversight, let slip some  
text that casual, less technically savvy readers might easily  
misinterpret.  I've had personal experience recently with exactly the  
sort of mistaken impression, which I mentioned in my first message,  
that I was concerned about.  That experience led me to take the very  
bold step of asking the authors to consider an editorial change to  
prevent what I thought were misunderstandings about the IETF consensus.

I now see that the authors have not made any oversight at all.  They  
have very deliberately chosen to express the consensus opinion of the  
IETF in this Informational RFC, and it was a mistake for me to think  
it was possible that anything else might be happening.

Again, my apologies all around.  I withdraw my objections.

---

From: james woodyatt <[email-masked]>
Date: Thu, 29 Mar 2007 10:25:32 -0700

On Mar 29, 2007, at 08:31, james woodyatt wrote:
>
> [...] I've had personal experience recently with exactly the sort  
> of mistaken impression, which I mentioned in my first message, that  
> I was concerned about.  That experience led me to take the very  
> prevent what I thought were misunderstandings about the IETF  
> consensus. [...]

I should explain that this experience was in the context of  
discussions inside Apple about how best to respond to this:

	<http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1338>

Despite the referenced draft being informational, and despite the  
caution in its introduction, and despite efforts to bring both these  
facts to the attention of decision makers, the NAP draft has been  
referenced as if it were an already published BCP.

I apologize again for not keeping up-to-date on the IETF consensus  
about this issue.  When I last spent much time participating in IETF  
discussions, this was the subject of a long-running and sometimes  
very heated controversy.  I suppose I should be thankful that the  
controversy has ended.

Again, my apologies all around.  I was trying to participate in good  
faith.  I did not mean to arouse hostility and I'm mortified to have  
done so.  I'd like to assure the working group that I'll make the  
appropriate recommendations to decision makers at Apple about how to  
proceed in compliance with the recommendations of the IETF.

apple inc.