Subject: [v6ops] ICMPv6 Filtering Recommendations to BCP?

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2012 08:03:15 +0000

ICMPv6 PTB filtering is a well known operational problem
for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations,
is an Informational RFC.

Is it time to promote it to BCP?

Regards
   Brian Carpenter

---

From: Sander Steffann <[email-masked]>
Date: Thu, 20 Dec 2012 10:12:25 +0200

Hi,

> Is it time to promote it to BCP?

Yes please! It is already used like a BCP, so lets label it as such.

Met vriendelijke groet,
Sander Steffann

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Dec 2012 08:43:46 +0000

> Yes please! It is already used like a BCP, so lets label it as such.

On this aspect, certainly. The rest of the text should also be reviewed if we're promoting it.

Tim

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 20 Dec 2012 13:38:54 +0000

One (not mutually-exclusive) alternative is also to finish draft-ietf-opsec-icmp-filtering.

Thanks,

-- Carlos.

On Dec 20, 2012, at 3:03 AM, Brian E Carpenter <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Dec 2012 10:51:13 -0800

> Is it time to promote it to BCP?

Strike while the iron is still warmer than ambient temperature.

--
james woodyatt <[email-masked]>
core os networking

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 21 Dec 2012 16:58:11 +0000

Hi.
> >> Is it time to promote it to BCP?
Those with long memories will remember that progressing this doc as a
BCP was discussed when it was originally written, but it was not thought
that there was enough common practice to justify this designation at the
time. I'm glad it seems to have been useful :-) 

> On this aspect, certainly. The rest of the text should also be reviewed if we're promoting it.

Right:  Checking the IANA list, there have been at least 5 new codes put
into service (154-158) since the document was written.

As one of the original authors, I'd be happy to put in some extra cycles
to update the text, but I have not been deeply involved in IPv6
operational matters for some years so would need input from those more
involved at the moment to bring the text up to date.

The filter script in the appendix could doubtless do with a check as
well.

Regards,
Elwyn

---

From: Mohacsi Janos <[email-masked]>
Date: Sat, 22 Dec 2012 18:49:34 +0100 (CET)

Dear All,
 	As an other author of the draft, I am also ready to contribute and 
send updates.
 	Best Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Director Network and Multimedia
NIIF/HUNGARNET, HUNGARY
Co-chair of Hungarian IPv6 Forum
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 27 Dec 2012 05:47:50 +0000

I'll give this a few more days to percolate; most of us are some variation on a holiday right now, and those that aren't are likely to be in February. If I see more email supporting this action, I'll initiate the indicated last call, and let it run through January.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 27 Dec 2012 09:52:45 -0800

> I'll give this a few more days to percolate; most of us are some variation on a holiday right now, and those that aren't are likely to be in February. If I see more email supporting this action, I'…
I generally think of the existing informational doucments in the series 
as imutable, so changing the status of an informational document implies 
a new document which doesn't seem that hard in light of a probaable 
consensus to do so.

---

From: "George, Wes" <[email-masked]>
Date: Thu, 27 Dec 2012 13:13:46 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of joel jaeggli
>
> a new document
[WEG] +1
> >>>> ICMPv6 PTB filtering is a well known operational problem for PMTUD.
> >>>> I see that RFC 4890, ICMPv6 Filtering Recommendations, is an
> >>>> Informational RFC.
> >>>>

[WEG] The rest of the world (as in, those who don't regularly go for a swim in the IETF process cistern) sees an RFC as an RFC. The status or class of document matters very little as long as it is a product of consensus and not obsolete. So changing 4890 just for the sake of the status seems to me like busywork. Those who follow it now will continue to do so, those who do not won't suddenly start simply because we change the status. I would support a new BCP draft if it provides updated guidance from what is already available and therefore updates or obsoletes the existing document.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 27 Dec 2012 14:12:47 -0500

> [WEG] The rest of the world (as in, those who don't regularly go for a swim in the IETF process cistern) sees an RFC as an RFC. The status or class of document matters very little as long as it is…

I respectfully disagree:
- I agree that changing status is not the most important move and maybe not change anything in some circles.
- however, it is a good tool for a lot of people to better enforce good practice. BCP is sending a stronger signal. 

So I agree we should aim at BCP for this one, even if in some circles, it might not change anything; in some, it will.

Marc.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Dec 2012 08:09:34 +0000

> Le 2012-12-27 à 13:13, George, Wes a écrit :

...
> So I agree we should aim at BCP for this one, even if in some circles, it might not change anything; in some, it will.

I agree with you both. I would suggest a two-stage process

1. Reclassify RFC 4890 as BCP. With a well-constructed writeup and IETF Last Call
message, that could be done in a month.

2. Kick off an update document that will replace it when finished, which among other
things will have BCP boilerplate and SHOULD language. That will take some time.

   Brian

---

From: joel jaeggli <[email-masked]>
Date: Sat, 29 Dec 2012 19:31:35 -0800

> things will have BCP boilerplate and SHOULD language. That will take some time.
if one is intent on producing a new document anyway it would seem 
simpler to just obsolete the old one in the process. e.g.  1 implies 2 
is not imminent.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Dec 2012 08:13:41 +0000

On 30/12/2012 03:31, joel jaeggli wrote:
>>>> [WEG] The rest of the world (as in, those who don't regularly go for
>>>> a swim in the IETF process cistern) sees an RFC as an RFC. The
>>>> status or class of document matters very little as long as it is a
>>>> product of consensus and not obsolete. So changing 4890 just for the
>>>> sake of the status seems to me like busywork. Those who follow it
>>>> now will continue to do so, those who do not won't suddenly start
>>>> simply because we change the status. I would support a new BCP draft
>>>> if it provides updated guidance from what is already available and
>>>> therefore updates or obsoletes the existing document.
>>> I respectfully disagree:
>>> - I agree that changing status is not the most important move and
>>> maybe not change anything in some circles.
>>> - however, it is a good tool for a lot of people to better enforce
>>> good practice. BCP is sending a stronger signal.
>>>
>>> So I agree we should aim at BCP for this one, even if in some
>>> circles, it might not change anything; in some, it will.

Well, fair enough, and there might be procedural issues about option 1
anyway. I'd much appreciate an effort by the authors of 4890 to achieve 2 as
quickly as possible.

   Brian

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 30 Dec 2012 10:20:51 -0500

Le 2012-12-29 à 22:31, joel jaeggli a écrit :

> if one is intent on producing a new document anyway it would seem simpler to just obsolete the old one in the process. e.g.  1 implies 2 is not imminent.

I agree with Joel. Looks better to write new version of the document, target as BCP and obsolete the previous one. That way there is an incentive to move the new one forward and we accomplish all this with the "least" amount of efforts (procedurally).

Marc.