Section 2.1:
> If the Interface Identification Object identifies the probed
> interface by name, the object payload contains the human-readable
> interface name. The interface name SHOULD be the full MIB-II ifName,
> if less than 255 octets, or the first 255 octets of the ifName, if
> the ifName is longer. The interface name MAY be some other human-
> meaningful name of the interface. The interface name MUST be
> represented in the UTF-8 charset [RFC3629] using the Default Language
> [RFC2277].
As I mentioned during the meeting today, the above text has a bunch of problems
as written:
1) Saying UTF-8 is not sufficient, you need to discuss normalization form, etc.
See RFC 7564.
You can't just copy a paragraph from some other spec, you have to
determine what
properties you actually want, but the Precis WG defined a number of
reusable classes.
There are precis experts that can help the WG determine what profile is
most appropriate.
2) You can't truncate a UTF-8 string at 255 octets and still have a valid UTF-8
string, since
characters can span multiple octets and you might truncate in the middle
and get a partial
character, which leaves you with an invalid string.
3) The length restriction is only part of the SHOULD. Does that mean that if
you follow the
MAY, there is no such length restriction?
Dave
-----Original Message-----
From: Int-area [mailto:[email protected]] On Behalf Of Ron Bonica
Sent: Wednesday, July 12, 2017 5:46 PM
To: [email protected]; Carlos Pignataro (cpignata) <[email protected]>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt
Hi Carlos,
Thanks for the review. Inline, below.
Ron
>
> Hi, Ron, Authors,
>
> As I was reading over draft-ietf-intarea-probe-00, and wanted to share
> a couple of observations for your consideration.
>
>
> * Have you considered the tradeoff of defining new ICMP Types versus
> extending existing ICMP Types? If using existing ICMPv6 Echo
> Request/Reply and extending them instead of defining brand new types,
> the backwards interoperability achieved is higher
[
[RB ]
I thought about extending the existing ICMP messages, but decided against it
for backward compatibility reasons. Both existing messages end with a variable
length data field. This field begins at a fixed position, but doesn't have a
length attribute of its own. Therefore, we can't add any more fields after it.
There may be ways to dance around the problem, but they all involve redefining
the existing field in the existing message.
> * Have you considered using other protocols as well in addition to ICMP
> for
> the PROBE message, which can elicit ICMP errors or responses with
> appropriate extensions? In particular UDP is a protocol much used and
> desired for probes.
>
[RB ]
ICMP and UDP would both work. I chose ICMP because ICMP already supports legacy
echo/echo reply. But I'm not feeling religious about this.
In the final analysis, I am willing to use whatever protocol the WG prefers.
> These two points actually reminded me of
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools
> .ietf.org%2Fhtml%2Fdraft-&data=02%7C01%7Cdthaler%40microsoft.com%7C4f6
> 74c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> C0%7C636354711627226706&sdata=G5vSnrYbaFBryTvzh5pn3AVaJz3hURtt1PJYLVah
> rnM%3D&reserved=0
> shen-traceroute-ping-ext-04 (and the ICMP-only predecessor draft-shen-
> udp-traceroute-ext-01) that defines a probe extension applied to ICMP
> Echo Request and UDP, and RFC 4884 extensions to responses. That
> approach seems somewhat more generic.
>
> Additionally, I was also reminded of the ICMP AUP at RFC 7279, it
> would be useful to map against that doc to show how this is (as it is
> the case) a really good use of ICMP.
[RB ]
Section 3 of 7279 suggests that ICMP can be used for diagnostics. It calls out
PING as being an acceptable use. But again, I don't feel religious about this.
The protocol works over UDP just as well as it works over ICMP.
Ron
>
> Thanks!
>
> ? Carlos.
>
>
*******************************
_______________________________________________
Int-area mailing list
[email protected]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=02%7C01%7Cdthaler%40microsoft.com%7C4f674c9180bf4a15581408d4c93d18ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636354711627226706&sdata=xSDwSJAGRkBNGO9IO9FfArdLkywAnaHf8AZ5OWcsDsk%3D&reserved=0
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
