Subject: [dhcwg] To wait for RA or not to wait?

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Dec 2011 17:41:21 +0000

> Ted, I read “we are not qualified to make architectural decisions about IPv6 transition technologies that don't directly involve DHCP”.  Good, however, the RFC6204 initially was putting a req in place to state that the CPE MUST wait for the RA prior of starting its DHCPv6 client.  This is linked to DHCP I’d say, no ?  I see too many times that links are being made between protocols or check for address or ….  It is OK to say that one should wait for it, so to leave it open as implementation choice or configuration possibility for the vendor.

If I had it to do over again, I'd do RA and DHCP a lot differently, but at this point I think in general we should assume that we will always have RAs, and DHCP clients should wait for them.   DHCP doesn't really work without the RA—even if you get an address, you have no default route.

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 2 Dec 2011 19:47:47 +0100

Well, you should wait, maybe, but you must wait: for sure no MUST!
You can perfectly add a default route statically in case you want to.  Different customers have different ideas about it, some prefer no RAs, so one has to be able to cope with it.  Moreover, there's no reason to "couple" RA to DHCP, they are independent protocols, so should be able to work independent.  It's fine to wait for it if you prefer, but one has to have the option to not do this.

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[email-masked]
tel.: +32 3 443 65 90

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: vrijdag 2 december 2011 18:41
To: dhc WG
Cc: Wuyts Carl
Subject: To wait for RA or not to wait?

> Ted, I read "we are not qualified to make architectural decisions about IPv6 transition technologies that don't directly involve DHCP".  Good, however, the RFC6204 initially was putting a req in place to state that the CPE MUST wait for the RA prior of starting its DHCPv6 client.  This is linked to DHCP I'd say, no ?  I see too many times that links are being made between protocols or check for address or ..  It is OK to say that one should wait for it, so to leave it open as implementation choice or configuration possibility for the vendor.

If I had it to do over again, I'd do RA and DHCP a lot differently, but at this point I think in general we should assume that we will always have RAs, and DHCP clients should wait for them.   DHCP doesn't really work without the RA-even if you get an address, you have no default route.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Dec 2011 19:35:45 +0000

On Dec 2, 2011, at 1:47 PM, Wuyts Carl wrote:
You can perfectly add a default route statically in case you want to.  Different customers have different ideas about it, some prefer no RAs, so one has to be able to cope with it.

This is equivalent to saying that different customers have different ideas about whether they want their network to work.   No they can't add a default route statically—that's absurd.   If they were going to statically configure the host, why bother with DHCP at all?

Moreover, there's no reason to "couple" RA to DHCP, they are independent protocols, so should be able to work independent.  It's fine to wait for it if you prefer, but one has to have the option to not do this.

They are coupled.   They do not work independently.   Whether that was the right architecture choice or not, the issue has been decided.

---

From: Ole Troan <[email-masked]>
Date: Fri, 2 Dec 2011 22:38:02 +0100

Ted,

> They are coupled.   They do not work independently.   Whether that was the right architecture choice or not, the issue has been decided.

that's not the case for DHCP PD. when DHCP is used to configure routers.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 02:46:29 +0000

> that's not the case for DHCP PD. when DHCP is used to configure routers.

It seems to me based on the conversations we've been having in other working groups that how DHCP with PD works is far from settled.

---

From: Ole Troan <[email-masked]>
Date: Sat, 3 Dec 2011 10:53:31 +0100

Ted,

> It seems to me based on the conversations we've been having in other working groups that how DHCP with PD works is far from settled.

we have had working interoperable implementations of DHCPv6 PD since 2003.
the "how PD should work with host configuration protocols" is a recent discussion. please don't rewrite history. if people want that changed now, fine. but you will find no basis in 3633 for that "unsettledness".

cheers,
Ole

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 03 Dec 2011 21:19:03 +0900

Ted Lemon wrote:

> If I had it to do over again, I'd do RA and DHCP a lot differently,
> but at this point I think in general we should assume that we will
> always have RAs, and DHCP clients should wait for them.

You may think so.

However, the reality is that, because of DAD latency forced by
RA, people are trying to avoid RA.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 16:49:28 +0000

On Dec 3, 2011, at 7:19 AM, Masataka Ohta wrote:
However, the reality is that, because of DAD latency forced by
RA, people are trying to avoid RA.

This is very interesting, but ought to be in an ops doc, not a rumor.   Or maybe it already is in an ops doc that I missed?   There's been some interesting discussion of various problems with RA in v6ops recently.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 3 Dec 2011 17:27:24 +0000

On Dec 3, 2011, at 4:53 AM, Ole Troan wrote:
we have had working interoperable implementations of DHCPv6 PD since 2003.
the "how PD should work with host configuration protocols" is a recent discussion. please don't rewrite history. if people want that changed now, fine. but you will find no basis in 3633 for that "unsettledness".

Sorry, I expressed myself poorly (perhaps due to not having really thought carefully about what I intended to say... :)

What I mean is that as far as I understand it, the behavior that all these implementations are interoperating with is not explicitly described anywhere in an RFC.   The reason we have interoperating implementations is either the UNH testing lab, implementors using other implementations as references, or discussion amongst implementors.   The correct way for us to get interoperability is for the protocol spec to say what to do, not either of these three otherwise very good things.

---

From: Ole Troan <[email-masked]>
Date: Sat, 3 Dec 2011 18:44:56 +0100

Ted,

> What I mean is that as far as I understand it, the behavior that all these implementations are interoperating with is not explicitly described anywhere in an RFC.   The reason we have interoperatin…

fully with you on that.
let's describe the right things to do in DHC, and solve the interoperability issues within DHC, without depending on other protocols.

cheers,
Ole

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 04 Dec 2011 10:37:40 +0900

> This is very interesting, but ought to be in an ops doc, not
> a rumor.

The problem in the real world is that for mobile nodes
DAD latency means loss of communication during handover
between cells, if the nodes move quickly or the cells
are small.

Some people recognized it at the last 802.11 interim
meeting.

> Or maybe it already is in an ops doc that I missed?

I don't know. It is real pain to discuss against IPv6
people who do not understand operational issues at all.

> There's been some interesting discussion of various
> problems with RA in v6ops recently.

If RA is obsoleted entirely, it will make IPv6 a lot
less broken.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Dec 2011 03:18:27 +0000

On Dec 3, 2011, at 8:37 PM, Masataka Ohta wrote:
I don't know. It is real pain to discuss against IPv6
people who do not understand operational issues at all.

Margaret Wasserman gave a presentation at the recent IETF in Taipei about power consumption issues with RA, but I don't recall hearing a presentation about DAD latency during handoff.   I suspect the work Margaret is doing might help with this, though―you might want to look at it.   I saw a _lot_ more concrete discussion of operational issues in Taipei than I've seen in any previous IETF, which I took to be a hopeful sign, although I suspect it is going to create a lot of work for us.

I don't disagree with you, but if we could obsolete RA, DHCP would not currently be a full replacement at the moment, and I am _not_ referring to the route option.   DHCP doesn't currently support multihoming properly.   So we would have to do a bit of additional work.   And in any case, obsoleting RA is not a decision the DHC working group can take: it's something for 6man.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 04 Dec 2011 17:36:12 +0900

Ted Lemon wrote:

> but I don't
> recall hearing a presentation about DAD latency during handoff.

It was discussed in IEEE802.11.

> I suspect the work Margaret is doing might help with this,
> though―you might want to look at it.   I saw a _lot_ more
> concrete discussion of operational issues in Taipei than
> I've seen in any previous IETF, which I took to be a
> hopeful sign, although I suspect it is going to create a
> lot of work for us.

Their approach for the operational issues is to make ND
even more complex, I'm afraid, only to make the issues
more complicated.

> I don't disagree with you, but if we could obsolete RA, DHCP
> would not currently be a full replacement at the moment,
> and I am _not_ referring to the route option.

The only reasonable, or, end to end, way for an end system
connected to multiple routers obtain route information is
to snoop IGP.

In addition, the only reasonable way for an end system
connected to one or more routers to select proper source
address is to let IGP carry source prefix information
appropriate for each routing table entry.

> DHCP doesn't currently support multihoming properly.

Neither RA nor DHCP can, unless either is bloated to be
an IGP with source prefix information.

> So we would have to do a bit of additional work.

Yes, but not here.

> And in any case, obsoleting RA is not a decision the
> DHC working group can take: it's something for 6man.

Here, you can assume DHCPv6 used without RA. Let
someone else bother on route issues.

					Masataka Ohta

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 4 Dec 2011 10:15:47 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Masataka Ohta
Sent: Sunday, December 04, 2011 3:36 AM
To: Ted Lemon
Cc: <[email-masked]>
Subject: Re: [dhcwg] To wait for RA or not to wait?

>connected to multiple routers obtain route information is

If the end system is a host, it's a non-starter to have a host
participate in an IGP with a router in the network.  If the end system
is a router, in wireline broadband deployment the access concentrator
terminates over 100K end systems, the network does not prefer to run
routing from the end systems to the access concentrator.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 4 Dec 2011 13:34:17 -0600

-----Original Message-----

To: Ted Lemon

Cc: <[email-masked]>

 

>>appropriate for each routing table entry.

I already replied today that the IGP is a non-starter.  For hosts that a
router supports, it's best that a SAS Policy Table is sent to the host
using DHCPv6.  See the IETF 6man WG documents that are revising rfc3484
and has related documents.  Please also see the email I sent recently to
v6ops below.

http://www.ietf.org/mail-archive/web/v6ops/current/msg11508.html

>an IGP with source prefix information.

Both DHCP and RA for basic behavior use IPv6 multicast - the RA is
multicast to the nodes on the link and the DHCPv6 SOLICIT is multicast
from a DHCPv6 client.  Thus we should not bother looking into either of
DHCPv6 or the IPv6 ND RA for multihoming.  Multihoming is better mapped
to router and host for behavior.  Routers are best served, if
multihomed, to use PBR where PBR works by keying off of the
source-address of the packets the router has to forward.  With hosts
being multihomed, the router could provide the SAS Policy Table to the
hosts via DHCPv6 or the SAS Policy table is manually configured on the
hosts.

There is still the fundamental problem open which is how does the host
get a default router if DHCPv6 provides only an IPv6 address to the host
and the host does not receive an RA that provided the default router to
the host.  Sticking the default router information in a DHCPv6 option is
nowhere close to consensus in the IETF community.  

Hemant

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 05 Dec 2011 05:38:52 +0900

> participate in an IGP with a router in the network.

That is an unfounded and wrong statement.

The fundamental problem is in source address selection, against
which default routers and longest matches are assured to be
"incomplete" and "incorrect" by the end to end argument:

	http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf
	The function in question can completely and correctly
	be implemented only with the knowledge and help of
	the application standing at the end points of the
	communication system. Therefore, providing that
	questioned function as a feature of the communication
	system itself is not possible.

Note that routers are in "the communication system".

> If the end system

You don't have to do so for (most?) users with only one source
address, which is the case where default routers will do.

Without involving dynamics of IGP, you may also add statically
distinguishable source addresses such as link local ones,
though it is an unnecessary complication.

Beyond that, approaches not heavily involving end systems is,
at most, "incomplete" and "incorrect".

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 05 Dec 2011 05:51:57 +0900

Hemant Singh (shemant) wrote:

> For hosts that a
> using DHCPv6.

The operational problem, then, is that the table reflecting
IGP dynamics can not be constructed automatically without
IGP carrying source prefix information with each routing
table entries.

> get a default router

Don't to that.

If you have a reasonable SAS policy table, each entry of the
table can and should have a router to use.

						Masataka Ohta

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 4 Dec 2011 18:09:03 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Masataka Ohta
Sent: Sunday, December 04, 2011 3:39 PM
To: [email-masked]
Subject: Re: [dhcwg] To wait for RA or not to wait?

>"incomplete" and "incorrect" by the end to end argument:

If a host has multiple default routers, then issue MSR from the routers
to the host as specified in RFC 4191.  Just does not make sense to run
routing between a router and a host.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 4 Dec 2011 21:20:05 -0600

-----Original Message-----

> It was discussed in IEEE802.11.

What is this DAD latency?  Is it the roughly two seconds a node waits
before the node deems DAD has passed for the node's IPv6 address?
Further, what had DAD latency got to do with waiting for the RA?   Soon
as a node is enabled for IPv6, the node creates an IPv6 link-local
address and then issues a DAD for the link-local.  But while the DAD
procedure is going on, the node is likely to receive an RA.   Certainly
the node can't initiate DHCPv6 until the DAD procedure completes (in up
to two secs) because the node sources the DHCPv6 messages with the IPv6
link-local.  Frankly the node can wait for the RA which gives the node a
default router until the node has to send a unicast packet out to the
network.  To reduce any two seconds DAD delay, one can use Optimistic
DAD - I am digressing here if there is no association found between DAD
latency and the issue of waiting for the RA.

I still belong to a camp that says don't wait for the RA to initiate
DHCPv6.  By the time DHCPv6 completes, the DHCPv6 client is expected to
see and RA.  If the node does not receive the RA by then, manual
intervention by a sys admin of the network is needed.

Hemant

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 05 Dec 2011 12:28:19 +0900

> If a host has multiple default routers,

I'm saying to have not multiple but *NO* default routers.

> then issue MSR from the routers
> to the host as specified in RFC 4191.

Having multiple "incomplete" and "incorrect" entities
makes the matter worse.

> Just does not make sense to run routing between a router and a host.

What does not make sense is to have a default router even
though there are multiple source addresses, in which case
the only reasonable thing to do is to let an end system
maintain a routing table with an appropriate source address
and the next hop router for each routing table entry.

					Masataka Ohta

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 5 Dec 2011 07:50:05 +0100

So, what if I get my routes over DHCPv6 then ?  It'll be available at some time, no ??
There's no default route to inject, not manual, not by RA ??  Re-define the document again, and yet again ask the CPE vendors to changes their implementation ?

Carl Wuyts
Connect Division

[email-masked]<mailto:[email-masked]>
tel.: +32 3 443 65 90
<http://twitter.com/#!/TechnicolorIPv6>
<http://www.technicolor.com/>
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

From: Ted Lemon [mailto:[email-masked]]
Sent: vrijdag 2 december 2011 20:36
To: Wuyts Carl
Cc: dhc WG
Subject: Re: To wait for RA or not to wait?

This is equivalent to saying that different customers have different ideas about whether they want their network to work.   No they can't add a default route statically-that's absurd.   If they were going to statically configure the host, why bother with DHCP at all?

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 05 Dec 2011 18:24:18 +0900

> before the node deems DAD has passed for the node's IPv6 address?

Yes. But environment I'm assuming is a bit complicated, because
the purpose of 802.11ai is to minimize the number of 802.11
frames (which may carry multiple information) exchanged,
hopefully within short period of time, before establishing
connection. Note also that it is just my idea and
nothing is determined by 802.11ai.

It is possible to set up a link with all the necessary information
such as address, DNS server, security, route) with just a three
way handshake, one of which is a beacon frame.

> address and then issues a DAD for the link-local.

That's not applicable to 802.11, because the link is
not always enabled.

And, I don't think link-local address with DAD, which requires
delay which means separate frames, is acceptable. Instead,
some "addresses determined through other mechanisms", which
may actually be identical to link-local address, may be used
without DAD.

> But while the DAD
> procedure is going on, the node is likely to receive an RA.

There is no DAD expected, so far.

And, there is another delay caused by RA minimum interval
of 3 seconds (unless the router is supporting mobility
(RFC3775)), which is partly why RA-initiated DHCP is no good.

Note that RA may be piggy backed in 802.11 beacon, to reduce
frame exchanges. However, it will almost always violate the
minimum interval requirement unless a base station is a
mobility supporting router.

> Frankly the node can wait for the RA which gives the node a
> network.

I don't think default router useful with multiple source
addresses (save link local ones). For 802.11ai, it can
be assumed that there is only one source address and
default router information should be made available
through DHCPv6 or directly by a field of 802.11ai.

						Masataka Ohta

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 5 Dec 2011 08:04:19 -0600

Actually, I, Wes Beebee, and some other folks have commented in v6ops
for using DHCPv6 to carry the default route information.  What happens
when the RA and DHCPv6 have conflicting information and which
information wins?  That is why I said in my email from Sunday that the
DHCPv6 default route option is nowhere close to consensus.   I still
prefer the existing means IPv6 has to signal a default router to a host
in the IPv6 ND RA.  Further if I recall correctly, the reason the
question (wait for RA or not) came up is because a DHCPv6 server was
getting bogged down with one client sending too many SOLICITs when the
SP was not ready to serve DHCPv6.    To the server storm problem we said
use the Ralph Droms' new draft that changes the SOL_MAX_RT.   So do we
have to discuss the "To wait for RA or not to wait" to initiate DHCPv6?
There is one screw case when a DHC client initiates DHCPv6, completes
DHCPv6, but does not receive any RA, what does the client do for default
route or default router?  In such a case, I don't think we can do
anything but require manual intervention.   

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wuyts Carl
Sent: Monday, December 05, 2011 1:50 AM
To: Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] To wait for RA or not to wait?

So, what if I get my routes over DHCPv6 then ?  It'll be available at
some time, no ??

There's no default route to inject, not manual, not by RA ??  Re-define
the document again, and yet again ask the CPE vendors to changes their
implementation ?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Dec 2011 15:32:05 +0000

On Dec 4, 2011, at 10:28 PM, Masataka Ohta wrote:

Presumably you would still need what would effectively be a default route, though, right?   You'd just have more specific routes that were associated with various source addresses, and you'd want the host to use those routes and those source addresses for those prefixes.   Once the host is communicating off the provider network, any globally valid source address ought to work.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 06 Dec 2011 14:03:44 +0900

Ted Lemon wrote:

> Presumably you would still need what would effectively
> be a default route, though, right?

No, not at all. Some people may be saying "multiple addresses"
purposelessly, but my objective to support multiple addresses
is to remove the default route, which, in turn, makes
multiple address support more efficient.

Default route may be desired if default free RT is too large,
because of excessive multihoming by routing. However, if
multihoming is properly architected with multiple addresses
to assign an address for each homing, RT can be aggregated
at ISP level or above that the default free RT can be
very small.

Moreover, the default free RT gives a useful hint for an
end system to choose the best (w.r.t. IGP metric)
destination address currently reachable among its peers
multiple addresses. That is, response of multihoming with
multiple addresses does not always rely on time out and
is at least as good as multihoming by routing.

> You'd just have more specific routes that were associated with
> various source addresses, and you'd want the host to use
> those routes and those source addresses for those prefixes.

No, as your peer has the right to select the destination
address of reply packets from your multiple addresses, there
is no point to have source address selection for that purpose.

> Once the host is communicating off the provider network, any
> globally valid source address ought to work.

Yes, as routing over the Internet is highly asymmetric, there
is no point to expect longest match means return routability.

The only valid reason to have source address selection is
to police source address spoofing.

Granted that some people may be saying "source address
selection" purposelessly.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Dec 2011 06:46:32 +0900

Hemant Singh (shemant) wrote:

> What happens
> information wins?

Wrong question.

The proper question to ask is:

	What if the RA and DHCPv6 have conflicting information?

and the answer is:

	That is an operational error, which can be solved only
	operationally.

	Implementations should report an error.

	There can not be such a thing as a fool proof protocol
	against all the foolish operations.

Then, more important question to ask is:

	What if ND is not used at all and some information is
	missing.

and the answer is:

	Operators will supply the missing information through
	DHCPv6 or some other protocol not necessarily under
	IETF control.

						Masataka Ohta

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 6 Dec 2011 16:25:20 -0600

-----Original Message-----
From: Masataka Ohta [mailto:[email-masked]] 
Sent: Tuesday, December 06, 2011 4:47 PM
To: Hemant Singh (shemant)
Cc: Wuyts Carl; Ted Lemon; dhc WG
Subject: Re: [dhcwg] To wait for RA or not to wait?

>	Implementations should report an error.

The implementation resides in a cable modem with no console.  The
implementation reports the error to who?

Hemant

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Dec 2011 12:18:57 +0900

> The implementation resides in a cable modem with no console.

Can't the cable modem send its own packet?

> The implementation reports the error to who?

Operators.

						Masataka Ohta

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 7 Dec 2011 11:22:13 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Masataka Ohta
Sent: Tuesday, December 06, 2011 10:19 PM
To: [email-masked]
Subject: Re: [dhcwg] To wait for RA or not to wait?

>Can't the cable modem send its own packet?

Send how and using what protocol?  New protocol would have to be
developed.

>Operators.

Using what protocol?

Hemant

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 08 Dec 2011 05:45:37 +0900

Hemant Singh (shemant) wrote:

> Send how and using what protocol?

It's like asking "what standard is used between a cable modem
monitoring PC and its console".

Let operators decide.

> New protocol would have to be
> developed.

Operators may or may not, though most will use existing ones
such as syslog.

					Masataka Ohta

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 8 Dec 2011 16:00:21 -0600

-----Original Message-----
From: Masataka Ohta [mailto:[email-masked]] 
Sent: Wednesday, December 07, 2011 3:46 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: [dhcwg] To wait for RA or not to wait?

>monitoring PC and its console".

No standards exist yet and that's a huge problem.

>Operators may or may not, though most will use existing ones

Several cable modems in the U.S. that I have used do not support syslog.
One has to assume there won't be any indication for an error like this
from consumer devices and design protocols robust enough to not have to
cause such conflicting errors between two sources of information
providing the same data. 

I have no further comment on this topic.

Hemant

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 09 Dec 2011 17:10:46 +0900

> No standards exist yet and that's a huge problem.

What? Can't you connect your PC and its console?

> Several cable modems in the U.S. that I have used do not support syslog.

It means there is no point for IETF to develop a new protocol
to make cable modems report errors, because they will not be
used by several cable modem makers.

So?

> cause such conflicting errors between two sources of information

I wrote:

not,

	Implementations MUST report an error.

Neither protocols nor implementations can be fool proof against
all the operational errors.

> I have no further comment on this topic.

Wise enough.

						Masataka Ohta