Subject: RE: 6man discussion on /127 document @ IETF78

From: Miya Kohno <[email-masked]>
Date: Mon, 2 Aug 2010 16:11:02 +0800

Hi Hemant,

> And the problem with eBGP is? If a BGP control message is initiated by
> one of the two routers and sent to the other router, no TTL is
> decremented when the other routers receives this message.  Only if the
> control is forwarded by the receiving router out any interface then
the
> router decrements the TTL.  

Sorry for catching up late, but, no...! If the eBGP peer uses loopback
address (/32(IPv4) | /128(IPv6)) for example, then TTL is decremented by
the receiving router before reaching to the peer address. So we need to
configure eBGP as "multihop" in this case. 

(Reference)
http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example
09186a0080093f25.shtml
---------------------------
router bgp 300
  neighbor 2.2.2.2 remote-as 400
  neighbor 2.2.2.2 ebgp-multihop 2
 
  !--- This command changes the ttl value in 
  !--- order to allow the packet to reach the 
  !--- external BGP peer which is not directly
  !--- connected or is using an interface other
  !--- than the directly connected interface.
---------------------------

Miya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 2 Aug 2010 13:47:19 -0500

>-----Original Message-----
>From: Miya Kohno [mailto:[email-masked]] 
>Sent: Monday, August 02, 2010 4:11 AM
>To: Hemant Singh (shemant)
>Cc: Matsuzaki Yoshinobu; [email-masked];
[email-masked]
>Subject: RE: 6man discussion on /127 document @ IETF78 

>configure eBGP as "multihop" in this case. 

You have one interpretation of Loopback with BGP described above.
Further, use of Loopback by BGP is an orthogonal discussion to the /127
issue.  So really, we do not understand the full scope of the problem
you are trying to address.

Hemant

---

From: Miya Kohno <[email-masked]>
Date: Tue, 3 Aug 2010 10:45:48 +0800

Hi Hemant,

> you are trying to address.

- As for the use of loopback, Jinmei and some others also suggested it. 

(From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] Sent: Friday, July 30, 2010 8:06 AM. please refer to the original email for the full text.)
-----------
it would be less controversial to use the so called "off-link" model, that is, the two routers assign two independent addresses to each end of the p2p link, e.g. 2001:db8:1111:2222::0/128 and 2001:db8:1111:2222::1/128, and ensure these addresses are reachable via the p2p link by some other method as mentioned above.
-----------

- You had asked what the problem with eBGP was, saying TTL would not be decremented. So I just wanted to clarify.

- Sorry if my communication skill is not good, but I'd really like to find a room for compromise, given a difference between backbone routers and cpes. (And for the scope of the problem, I'd appreciate if you could read the draft.)

Thanks,
Miya

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Aug 2010 10:46:19 +0200

> you are trying to address.

as you say, the loopback discussion is a 'red herring.'

the subject is really simple.  on p2p inter-router links many of us use
/31s and /127s.  they work well and meet our operational needs.  there
are some documents which muddy the use of /127s.  we want it made very
clear that /127s on inter-router p2p links are supported.

randy

---

From: [email-masked]
Date: Tue, 03 Aug 2010 10:53:24 +0200 (CEST)

> clear that /127s on inter-router p2p links are supported.

Also, the distinction between "on-link model" and "off-link model" is
unlikely to be understood by practitioners, IMHO. As seen from the 
viewpoint of a router jockey - if I have a /127 and the two routers 
on this link are using the only two available addresses in the /127,
it is obvious to me that the router at the other end of the link is
indeed on a directly connected link.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Aug 2010 10:58:09 +0200

> indeed on a directly connected link.

+1. and I would also expect address resolution to work on this link.
(I don't quite understand how the off-link model would apply in this case. on a router to router link, neither end would do router discovery and there wouldn't be any default router to send a packet to.)

cheers,
Ole

---

From: [email-masked]
Date: Tue, 03 Aug 2010 11:33:01 +0200 (CEST)

> (I don't quite understand how the off-link model would apply in this case. on a router to router link, neither end would do router discovery and there wouldn't be any default router to send a packe…

If this is a true point-to-point link (SDH/SONET, serial) - isn't the
argument that you really don't *need* address resolution, since there
is no L2 address involved?

I wouldn't necessarily expect a /127 to work on an Ethernet point-to-
point link. But I *do* expect it work on a true point-to-point link
(which it does today, on the hardware that is relevant for me), and
it solves a real problem.

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Aug 2010 11:39:52 +0200

> point link.

we use 'em.  they do work.  it uses it as a p2p link, and does not
ecpect address resolution as it is hard configured.

randy

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 10:18:58 -0500

Ole,

Sorry, this email got buried in my Inbox - I did not see it till today.
See below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ole Troan
Sent: Tuesday, August 03, 2010 4:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

>(I don't quite understand how the off-link model would apply in this
case. on a router to router link, neither end would do router discovery
and there wouldn't be any default router to send a packet to.)

One manually configures a /127 and default gateway on each of the two
directly connected routers. Then when any of the two routers have to
send a packet, the ND off-link model is used to send data to the default
router/gateway.  Also, I know SPs are not crazy about using the ND RA in
such a backbone link, but another way is to have each router send an RA
to the other router where RA is advertised with no PIO - the IPv6 /127
address is still provisioned manually, but now the default router is
learnt from the RA.

Hemant

---

From: [email-masked]
Date: Tue, 24 Aug 2010 17:46:33 +0200 (CEST)

> directly connected routers.

If I have two SONET/SDH interfaces connected I configure the address
and /127 netmask at each end. No default gateway (or for that matter
address resolution) involved.

> Also, I know SPs are not crazy about using the ND RA in

Why on earth would you want to do this? My backbone router links have
nothing to do with RA, and aren't supposed to. They run protocols like
IS-IS and BGP to learn the necessary routing information.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 11:41:40 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 11:47 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked];
[email-masked]

>address resolution) involved.

That's not the point.  With such a /127 setup between two directly
connected routers, one does not want any router to invoke anycast
forwarding functionality because /127 is provisioned.   To prevent any
anycast processing on a router, the ND off-link model is proposed by
Dave Thaler and I.  The ND off-link model needs a default router and
that is where the manual configuration of the default gateway comes in.

Hemant

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 09:56:08 -0700

Why make things easy when we can make them complex...

   - Alain.

On Aug 24, 2010, at 12:41 PM, Hemant Singh (shemant) wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 24 Aug 2010 19:13:06 +0200 (CEST)

> Why make things easy when we can make them complex...

If the complexity can be *hidden* such that the operator configures
the /127 link "as usual", this might be okay. If the operator needs
to perform extra configuration to get the /127 link working, probably
not.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 24 Aug 2010 14:02:37 -0400

> Why make things easy when we can make them complex...

Good question.

I'm sort of baffled about where this thread has gone...

RAs are great for configuring hosts. repeat after me: hosts. They are
clearly of substantial utility in leaf and edge networks where hosts
connect.

This ID is targetted at inter-router links, i.e., core networks. There
will be few if any "hosts" attached to them. Indeed, we are talking
about exactly two nodes on the link, the two routers connected by the
point-to-point link.  They won't need to run RAs, etc. They won't need
stateless autoconfig.

I also don't like the "ND off-link model" term. I don't know what that
model refers to or what it means. It's also of no utility in a core
network, where the routers are presumably running routing protocols
and not using RAs to find default routers...

But maybe I'm just confused...

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 13:21:08 -0500

Steinar,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 1:13 PM
To: [email-masked]
Cc: Hemant Singh (shemant); [email-masked];

>to perform extra configuration to get the /127 link working, probably

Great thought. Indeed the off-link model functionality I and Dave Thaler
speak of for getting around the anycast issue with use of a /127 is
"hidden".  The functionality is an internal implementation of the
router.  The external user only sees the fact that when the user
configured a /127 on the router interface, the router does not jump to
invoking anycast data forwarding mode.  The SP's from Japan I spoke with
at the IETF 78 told me they want to future-proof their network.  They
are working fine right now with /127 on their Cisco and Juniper routers.
But they say, what if router vendors in future change their code to
start anycast processing with a /127 configured.  Also they were burnt
recently when Linux changed its /127 implementation to kick of anycast
processing - apparently some small router company was using this Linux
code.

Hemant

---

From: Shane Amante <[email-masked]>
Date: Tue, 24 Aug 2010 13:35:17 -0600

Hemant,

On Aug 24, 2010, at 12:21 MDT, Hemant Singh (shemant) wrote:
> invoking anycast data forwarding mode.

We don't statically configure, (nor would we even consider doing so), default routes or want "hidden" default routes in our Core routers.  If those default routes are installed into the FIB of the routers, (intentionally or accidentally during "implementation" of your proposal), it would have substantial negative repercussions on our operations, namely traffic forwarding loops (whee!) in our network that would likely cause congestion, etc.  Furthermore, there are way too many 'hidden' configurations/nuances inside every router vendor's implementation that I don't want to keep track of another one ...

Please, as an operator, I really just want IPv6 /127's to be as KISS as /31's are in IPv4.

-shane

> The SP's from Japan I spoke with

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 19:29:27 -0500

Shane,

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 3:35 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: 6man discussion on /127 document @ IETF78

>We don't statically configure, (nor would we even consider doing so),
default routes or want "hidden" default routes in our Core routers.  If
those default routes are installed into the FIB of the >routers,
(intentionally or accidentally during "implementation" of your
proposal), it would have substantial negative repercussions on our
operations, namely traffic forwarding loops (whee!) in our >network that
would likely cause congestion, etc.  Furthermore, there are way too many
'hidden' configurations/nuances inside every router vendor's
implementation that I don't want to keep track of >another one ...

>Please, as an operator, I really just want IPv6 /127's to be as KISS as
/31's are in IPv4.

I agree that simple is always desirable.  We are just discussing
internals of a router so that one gets around the genuine problems
raised with /127 which is to not have the router start anycast
forwarding on an interface configured with a /127.  As for the routing
loop, let's see the cases when routers are configured for a global /127
address.  Router A sends a packet destined to Router B in a p-p network
between the routers.  The packet gets sent out Router A and Router B
terminates/consumes this packet since the packet is destined to B.
Likewise for B sending to A.  The only other case is when A sends a
packet to B where the packet destination is not B but C, so the router B
looks up the routing table and finds a route to C and ships the packet
out the interface that the routing table found to egress on.  Only if
router B does not have a route to C and then the router has no choice
but to use the default route, then a loop situation arises, but then see
ICMPv6 in RFC 4443 that has defined Code 3 for such a point-to-point
link error.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 19:50:05 -0500

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 2:03 PM
To: Alain Durand
Cc: Hemant Singh (shemant); [email-masked];
[email-masked]

>This ID is targeted at inter-router links, i.e., core networks. There

Agreed.

>and not using RAs to find default routers...

I am configuring two such p-p routers in the Internet core for one
interface on each router.  When an IPv6 address is configured/acquired
by the interface, the interface acts as a host.  Once each of the
addresses have been manually configured on the interface, the interface
can also be configured for IPv6 ND to send an RA with no PIO.  From a
received RA, each interface learns the default router.  Then I configure
routing on each of the interfaces.  All these operations ran orthogonal.
RA with no PIO also signals to the receiving interface to send packets
to the default router.  

The only reason each router interface on this p-p network is signaled to
send data to default router (ND off-link model) is because then the
router interface does not initiate anycast data forwarding because a
/127 was configured on each interface.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 20:40:38 -0500

Thomas and Shane,

One clarification with my reply below to Thomas.  I am in agreement with
both you guys to not use ND and RA in a p-p network in the Internet core
between two routers.  I am merely replying to some folks who said ND or
IPv6 ND RA CANNOT be used in such a network. I am showing how one can
still use ND and RA. The RA also helps to explain RA with no PIO telling
a network interface to send traffic to the default router which is
"off-link".

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Tuesday, August 24, 2010 8:50 PM
To: Thomas Narten; Alain Durand
Cc: [email-masked]; [email-masked]
Subject: RE: 6man discussion on /127 document @ IETF78

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 2:03 PM
To: Alain Durand
Cc: Hemant Singh (shemant); [email-masked];
[email-masked]

Agreed.

Hemant

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 Aug 2010 11:21:58 +0900

> Why make things easy when we can make them complex...

because they work now and we need to fix that

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 Aug 2010 11:25:03 +0900

> The SP's from Japan I spoke with at the IETF 78 told me they want

please do not speak for operators

> to future-proof their network.

future-proof == adding crap we do not understand or need

> they say, what if router vendors in future change their code to start
> anycast processing with a /127 configured.

not quite.  what kawamucho, maz, i, ... said was that we did not want
vendors to break /127 on p2p links.  we did not enumerate how the
vendors might do that.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 25 Aug 2010 01:10:35 -0400

> but to use the default route, then a loop situation arises, but then see

shane, level3 has a default route in their core? since when?

Hemant, shane's point is that there is no default route in his
network, there are no default routes in lots of networks. having one
suddenly appear is a super extra bad thing, trust me, i've done it...
people get very angry when a few million packets per second arrive all
of a sudden...

Also, in the scenario, what makes routerA the 'default' ? what makes
routerB? who decides? how is that decision made? is it deterministic?
across all vendors and across all implementations inside a single
vendor? (I'm looking at you XR|IOS]CatOS|wifi-crap-os... and to be
fair: JunOS|E)

to echo 3 other people... this is a very  bad plan. If you put a /127
on a ptp link all it ever is is 2 addresses that are part of a very
small (2 host-addr) subnet. it doesn't need nor want anything like RA
or ND on it.

-chris

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Aug 2010 16:36:49 -0500

Randy,

Maz spoke to me at IETF 78 and told me they want to future proof since
they found one small router company's router having changed code
behavior between an old to new release.  All I was trying to bring out
is his comment to me to the mailer.  Thereafter since a discussion
started in 6man on how to take care of this anycast problem with /127 on
routers, we were discussing internals of a router. I understand that all
you care about is not break the /127 on p2p links.  It's fine by me to
stop discussing internals, especially since our Cisco routers work fine
for /127 and also for anycast.

Hemant

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 10:25 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked];

randy

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Aug 2010 17:04:14 -0500

-----Original Message-----
From: Christopher Morrow [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 1:11 AM
To: Hemant Singh (shemant)
Cc: Shane Amante; [email-masked];
[email-masked]

>people get very angry when a few million packets per second arrive all

I can believe you but such bad things also depend upon what else is
configured for routing on each of the two router in the p2p network that
can prevent the bad things. 

routerB? who decides? how is that decision made? is it deterministic?
across all vendors and across all implementations inside a >single
vendor? (I'm looking at you XR|IOS]CatOS|wifi-crap-os... and to befair:
JunOS|E)

Ah, such an implementation so does not exist anywhere in the industry.
We are just discussing a point brought up in 6man at IETF 78 related to
off-link that generated this new router internals discussion.  As for
your question, IPv6 ND RA from routerB telling routerA that router B is
its default router.  Conversely, routerA is routerB's default router via
IPv6 ND RA from routerA received by routerB. 

>small (2 host-addr) subnet. it doesn't need nor want anything like RA

We are in agreement.  See my email from last night where I was trying to
explain to some folks who had challenged that ND and RA cannot be used
in a p2p link. I am saying it can be, but as we all see it as not
necessary. I also said, the RA example was to explain IPv6 ND off-link
model which ends up sending data to the default router.  Anyway, the
IPv6 ND off-link model was for router internals.  The off-link model
internally in the router can still send traffic to the other router
without any default router configured because the other end is the /127
directly connected from A to B. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Aug 2010 18:08:43 -0500

Randy and others,

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 10:25 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked];

>vendors to break /127 on p2p links.  we did not enumerate how the

This discussion has totally derailed from its main perspective.  If I
may please focus the discussion back.  As the subject of the email says,
this was a discussion related to the /127 document
(http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-02) presented
at the IETF 78.  Well, did folks get a chance to read this draft which
proposes normative changes to an existing RFC as follows.  The text is
snipped from section 6 of draft-kohno...

[The [RFC4291]is to be revised to allow longer prefix than /64, and
state that Subnet-router anycast address MUST be disabled if the prefix
length of the link is /127.]

I, and I think Dave Thaler too, are saying that the above text is not
acceptable because existing IPv6 RFCs can deal with the situation of
/127 configured and not invoking anycast data forwarding.  Since we said
no RFCs need to change, we had to get into router internals to explain
how so.  This discussion therefore has two paths forward.  Either the
authors of draft-kohno... remove this text from their document or we
continue to discuss why and how existing IETF RFC's take care of the
issue at hand.  Or a third choice is that the community doesn't care how
router internals work and also agree no RFCs need to change and then we
have closure to discuss any more internals. 

Hemant

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 25 Aug 2010 19:09:26 -0500

Hemant Singh:

> Well, did folks get a chance to read this draft which
> how so.

On prefix length, RFC 4291 says:

"For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format."

So, longer than 64-bit prefixes are already possible. Is the objection the restriction that the first three bits must be set to zero for these longer prefixes?

As to subnet router anycast, in a /127 subnet, subnet router anycast will always identify one of the two routers, the one with host ID 0. I'm not sure what the issue is with this.

RFC 4291 would only need to change if there are problems with these two issues, seems to me.

Bert

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 2010 08:45:20 -0400

> "For all unicast addresses, except those that start with the binary
>  value 000, Interface IDs are required to be 64 bits long and to be
>  constructed in Modified EUI-64 format."

Correct. Note that the above only talks about what an address looks
like. It doesn't say anything about how it is used. Other documents
make clear that and address is just an address and a node need not
know anything about its internal syntax or how the address was formed.

Also, the above says nothing about subnet masks or on-link prefixes,
which are NOT restricted to being /64s or any other specific value.

Some folk may have made the assumption that the above implies that
subnet mask/on-link prefixes can be no longer than a /64 but I think
that is incorrect and do not believe any standards track document says
that.

Indeed, my clear recollection is that the /127 issue was known when
RFCs 2460-2462 were last revised, and the text intentionally allowed
longer prefixes than /64.

Unfortunately, some vendors apparently do not see the documents as
clearly requiring support for prefixes longer than /64, even though
some operators want them.  The purpose of this document is to fix
this. I don't believe this change will or needs to change previous
documents in any significant way. It really is more of a
clarification.

If others disagree, please quote text from relevant RFCs.

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Thu, 26 Aug 2010 09:04:42 -0400

> If others disagree, please quote text from relevant RFCs.

RFC 3627?

Brian

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 2010 09:13:30 -0400

> RFC 3627?

An informational document that carries no weight from a standards
perspective.

It was also not the product of an IETF WG, it was an independent
submission.

(But we all know how once something is an RFC, what it's actual IETF
status is is not always noticed or properly understood...)

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Thu, 26 Aug 2010 09:27:19 -0400

> status is is not always noticed or properly understood...)

That was my point.  So, at a minimum, this draft should
obsolete/supersede RFC 3627 so that we are not sending conflicting messages.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Aug 2010 09:59:20 +1200

Actually, I don't think an IETF document can formally update or
obsolete an Independent Submission, which even by its title is
only expressing an opinion. But we can certainly document the facts
that (a) RFC 3627 does not represent IETF consensus and that (b) the
IETF consensus is that /127 is not harmful, in specified circumstances.

   Brian Carpenter

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Aug 2010 08:35:46 +0300 (EEST)

> IETF consensus is that /127 is not harmful, in specified circumstances.

RFC 3627 was reviewed by IPv6 WG at the time even though it wasn't a 
product of a WG.

I don't see a procedural problem in practise in obsoleting an 
Independent Submission, as long as the new RFC represents consensus 
and the viewpoints of the previous document fairly.

Speaking as an author, I'd be more than happy to declare RFC 3627 
obsolete, historic and/or replace it with another RFC _provided that_ 
RFC 2526 is deprecated at the same time.  This would also require an 
Updates: 4291 (Section 2.6.1) and 3775 (Section 6.5; the ICMP-based 
dynamic HA discovery).

Otherwise the situation is more delicate but not necessarily 
unmanageable. There is danger that yet another document adds rather 
removes confusion unless a previous one is obsoleted or there is a lot 
of clear text on how these documents fit together.

-- 
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: Mark Smith <[email-masked]>
Date: Sat, 28 Aug 2010 23:05:16 +0930

On Fri, 27 Aug 2010 09:59:20 +1200

> IETF consensus is that /127 is not harmful, in specified circumstances.

So RFC3627 is Informational, which I think really just means its
providing more discussion behind the MUSTs, SHOULDs etc. the RFCs it is
referring to. I wouldn't think stating that RFC3627 doesn't represent
IETF consensus then invalidates the MUSTs etc. in the other RFCs.