Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt

From: Ron Bonica <[email-masked]>
Date: Wed, 12 Jul 2017 15:45:52 +0000

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://tools.ietf.org/html/draft-
> 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.
*******************************

---

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Jul 2017 08:00:28 +0000

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-masked]] On Behalf Of Ron Bonica
Sent: Wednesday, July 12, 2017 5:46 PM
To: [email-masked]; Carlos Pignataro (cpignata) <[email-masked]>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt

Hi Carlos,

                                        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.
> 
> 
> 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 ]

[RB ]

> 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
> 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 ]

                                                                                                                      Ron

_______________________________________________
Int-area mailing list
[email-masked]
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

---

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Jul 2017 08:03:16 +0000

BTW, RFC 7564 is being updated by
https://tools.ietf.org/html/draft-ietf-precis-7564bis-09 which is in IESG evaluation.

-----Original Message-----
From: Dave Thaler 
Sent: Thursday, July 20, 2017 10:01 AM
To: 'Ron Bonica' <[email-masked]>; [email-masked]
Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt

Dave

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Wednesday, July 12, 2017 5:46 PM
To: [email-masked]; Carlos Pignataro (cpignata) <[email-masked]>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt

Hi Carlos,

                                        Ron

[
[RB ]

[RB ]

[RB ]

                                                                                                                      Ron

---

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Jul 2017 08:11:50 +0000

Section 5.11 of https://tools.ietf.org/html/rfc7652
contains an example of the sort of things you have to say, but you can't just paste that
without analyzing whether your case wants the same semantics as that RFC uses.  In fact
you probably don't, since that one is more of a username than an interfacename.

-----Original Message-----
From: Dave Thaler
Sent: Thursday, July 20, 2017 10:01 AM
To: 'Ron Bonica' <[email-masked]>; [email-masked]
Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt

Dave

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Wednesday, July 12, 2017 5:46 PM
To: [email-masked]; Carlos Pignataro (cpignata) <[email-masked]>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-probe-00.txt

Hi Carlos,

                                        Ron

[
[RB ]

[RB ]

[RB ]

                                                                                                                      Ron