Subject: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 22 May 2017 15:40:51 -0700

Adam Roach has entered the following ballot position for
draft-ietf-anima-grasp-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The document includes a couple of instances of "reasonable" in normative
statements (e.g., "reasonable timeout"). I would strongly recommend
having specific recommendations in the document where this happens.

The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but
no way to register additional values with IANA. This does not seem
future-proof.

Section 3.8.4 talks about behavior when a node has a "globally unique
address," but provides no guidance for detecting this. Are nodes expected
to check for link-local, zeroconf, RFC 1918, and RFC 6598 addresses? Any
others?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 May 2017 15:57:15 +1200

> no way to register additional values with IANA. This does not seem

This is a tricky point. The values are of course already IANA values from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
If we wanted to add, say, SCTP that would be straightforward enough, without
bothering IANA.

But what if we wanted to specify, say, HTTP or QUIC or anything else that
doesn't run directly over IP?

I think that's a much bigger problem than just GRASP. So I personally prefer
to leave it alone for now. If the Transport Area has an answer, that
would be great.

Regards
   Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 May 2017 10:06:38 +0100

Hi Brian,

> On 23 May 2017, at 04:57, Brian E Carpenter <[email-masked]> wrote:
> 

Can you at least establish an IANA registry?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 May 2017 21:20:18 +1200

> Can you at least establish an IANA registry?

My concern is that this may turn out to be a much broader problem: how
do we express that some upper layer protocol wants to run over a variety of
"transport" layers, some of which are traditional transport-over-IP
and some of which are transport-over-UDP or whatever. Yes, maybe there
should be a registry for that, but it would definitely not be specific
to GRASP. I'd really like to hear some Transport Area thinking on that.
(And meanwhile I'd like to get GRASP out the door too ;-)

    Brian

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 11:35:53 -0500

> If we wanted to add, say, SCTP that would be straightforward enough, without

The document doesn't actually say that the values are taken from that 
registry, though, does it? I mean, I noticed the parallel, but without 
any explicit mention, I assumed that the values were inspired by the 
registry rather than bound to it. For example, SIP has response codes 
like "200 OK", "300 Multiple Choices," "301 Moved Permanently," "400 Bad 
Request," "401 Unauthorized," and so on. These will all look very 
familiar to anyone who has worked with HTTP -- but that doesn't mean 
they use the same registry.

It sounds like the extensibility plan you had in mind here was something 
like "use the numbers from the protocol numbers registry until we need 
something new, at which time, panic."  Minimally, I'd like to see that 
plan written down in this document. Ideally, I'd like to see a different 
plan. But whatever is intended needs to be documented, and the 
relationship to existing registries (if any) needs to be crystal clear 
rather than implied. The fact that you wrote it to mean one thing and I 
read it to mean the other is a pretty compelling example of how doing 
this in an implicit fashion goes wrong.

> doesn't run directly over IP?

Well, if you don't have a registry at all, then it's going to be even 
harder, isn't it? ;)

In particular, one of the ways I've used registries in the past -- and I 
don't think this is uncommon -- is seeing a value in a protocol that I 
didn't recognize, going to the governing IANA registry, and looking up 
that codepoint to find the corresponding protocol definition.  Re-using 
the protocol numbers registry won't allow developers to do that (unless 
we start adding GRASP RFC numbers to the table, which I suspect would 
face some resistance).

My strong recommendation here would be to define a new GRASP protocol 
numbers registry, state that any values in the GRASP registry that 
correspond to a protocol in the 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 
registry SHOULD use the same number (which you imply by your current 
choices to be a Good Thing), and that any values that are appropriate 
for GRASP but not general protocol numbers SHOULD be assigned by IANA 
starting with 252, with each subsequent such registration using the next 
smaller number available.

> to GRASP.

That seems like an ocean-boiling exercise with no discernible benefit. 
It has the clear anti-benefit of lacking the code-point-to-RFC-mapping 
that I describe above. I would strongly desire that this never happen.

/a

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 May 2017 13:07:27 -0400

Adam Roach <[email-masked]> wrote:
    > starting with 252, with each subsequent such registration using the
    > next smaller number available.

Actually, we aren't limited to 1-octet.
It's a CBOR integer, and grows automatically.
So we could have >=256 for GRASP-only things.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 May 2017 12:35:22 -0500

> So we could have >=256 for GRASP-only things.

That's even better.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 May 2017 07:47:22 +1200

>> So we could have >=256 for GRASP-only things.

I'm still puzzled about doing this *specifically* for GRASP. Can this be
the only upper layer that would like to signal a choice of this kind?

   Brian

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 May 2017 15:38:44 -0500

> the only upper layer that would like to signal a choice of this kind?

You do take my point about being able to find the specification for a 
codepoint by way of the IANA registry, right? Can you take an explicit 
position on whether you think that's something we should ignore? I can't 
tell whether you missed the point or just believe it's unimportant.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 May 2017 13:23:53 +1200

> tell whether you missed the point or just believe it's unimportant.

Sorry, yes I do take the point. I now recall finding myself in a dilemma
many months ago when I realised that (a) to specify a foo-over-IP transport
layer there is already a well-defined registry and that (b) to specify a
foo-over-something-over IP transport layer, there is no registry. In the
draft we ducked this, as you noticed. Indeed we can add a registry, or
perhaps a note that a registry needs to be created for any transports
that are not directly over IP. But then I got to thinking: isn't this
a general problem, not a GRASP-specific problem? Which is something to
be discussed in the transport and ART areas, I guess.

Is it sufficient to state that the currently defined values are from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
and that the encoding of values for protocols that do not have IP protocol
numbers is for further study? Personally I'd rather do that than try to
resolve this question on the fly. As Michael pointed out, CBOR gives
us a lot of freedom on how to resolve this without any change to
the protocol syntax.

   Brian

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 May 2017 22:57:04 -0500

> be discussed in the transport and ART areas, I guess.

It's worth noting that, with relatively rare exception, 
application-layer protocols aren't really going to have a compelling 
reason to use numeric representation for transports. See, for example, 
<https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-transport> 
and 
<https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2>.

At best, even if you limit this to protocols that use numbers to 
represent transports [1] , you might end up with some kind of unified 
registry, similar to what we did with 
<https://www.iana.org/assignments/message-headers/message-headers.xhtml>, 
although I've never been able to ascertain the value of that approach 
over having four different tables.

In any case, I agree with you that halting the processing of GRASP to 
create some kind of pan-area unified numeric transport registry is going 
to take a lot of time; and I would make the further observation that 
doing so in the future, after we are done discussing GRASP, will *also* 
take a lot of time.

But why?

Why would we ever spend that time? I see absolutely no concrete benefits 
to doing so. You clearly do. Can you lay those benefits out so that we 
can discuss their merits relative to the extra work you're implying 
might be taken on to achieve them?

/a

____
[1] How many are there? Based on a skim through IANA, it looks like 
GRASP may be the second over the past 31 years.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 May 2017 11:36:46 +0200

Hi,

> On 25 May 2017, at 03:23, Brian E Carpenter <[email-masked]> wrote:
> 

I know that IANA registries can be peoples' favourite bike sheds, but from where I stand doing what you suggest above would be better than doing nothing.

I am happy for you and Adam to reach an alternative agreement on what should be done for GRASP, but the above looks sufficient for now.

Best Regards,
Alexey

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 May 2017 09:58:22 -0400

> over having four different tables.

Noting that we can in fact, omit the IANA indirection, and put something like
'rfc9123' in as the actual value.  I'm not sure that is a good idea for a
a number of real reasons.  At this point, we need to indicate *UDP*, or *TCP*
with flexibility to specify SCTP in the future.

There was a further locator that I tried to create, see:
      https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.2

which was to use an IPIP tunnel.  The use of '41' was disputed, and maybe
this is a case where it should have been a literal 'ipip' or some such.

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 May 2017 10:34:46 -0500

>        https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.2

Yes, the fact that we're already seeing this field extended tells me 
that this is crying out for a registry.

So we have an extension point, we have a need to ensure uniqueness, and 
the IETF as an institution have known way to handle situations like that.

With regards to this being a bikeshed -- I'm not keen to argue about the 
color of the bikeshed too much, but I think it's manifestly obvious that 
we *need* a bikeshed here. If we could get agreement on that fact -- 
that a registry is called for -- I'd be happy to let the WG and authors 
figure out the exact color. My advice? Do what's simple.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 May 2017 08:05:10 +1200

> figure out the exact color. My advice? Do what's simple.

Yes. Point taken

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 May 2017 14:34:22 +1200

...

Yes, will do.

> no way to register additional values with IANA. This does not seem

Separate message to follow.

> to check for link-local, zeroconf, RFC 1918, and RFC 6598 addresses? Any

Think IPv6, where this is quite well defined. The trouble is that it's
not well supported in the socket API. I think the best we can say in
the text is that it's implementation dependent.

(To find the code for this in the prototype, search for the comment
"This is a hack.")

We did want to write the text independent of the IP version as far
as possible, but trying to do this bit in IPv4 would be masochism.

Regards,

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 May 2017 14:51:06 +1200

> no way to register additional values with IANA. This does not seem

Adam is correct. The current values (6 and 17) are of course values from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
and the names are those used in the socket API. If we wanted to add, say,
SCTP it would be easy: IP_PROTO_SCTP = 132.

The problem comes if we want to add "transport" protocols that aren't
directly over IP: things like HTTP, COAP, QUIC... for example. There's
no registry for them.

We have considerable flexibility thanks to CBOR; for example, as Michael
Richardson noted, we could define values >255 for transport protocols that
are *not* directly over IP. However, that would need a new IANA registry.

Proposal: Note in the text that the current values are taken from the
existing Protocol Numbers registry. Also note that if values are required
in future that are not in that registry, a new registry for values >255
will be created. So IANA doesn't have to do anything now.

Opinions? Objections?

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 May 2017 08:46:48 +0200

Leaving the registry for later sounds fine to me, in particular if it isn’t clear yet what the registration policy should be.

If we ever add not-over-IP “transports”, there might be a need for experiments before we go registering.
So I would probably identify a range of numbers that are strictly reserved for use in experiments.
(This needn’t be very small; say, 65280 to 65535.)

Grüße, Carsten

> On May 29, 2017, at 04:51, Brian E Carpenter <[email-masked]> wrote:
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 May 2017 16:53:52 -0400

Carsten Bormann <[email-masked]> wrote:
    > If we ever add not-over-IP “transports”, there might be a need for
    > experiments before we go registering.  So I would probably identify a
    > range of numbers that are strictly reserved for use in experiments.

-1 to -32!

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 May 2017 08:56:16 +0200

Ah.  3.9.5.1 currently does not have a “.within” clause giving an expectation as to how the type "transport-proto” is going to grow as the protocol evolves.  Foolishly, my brain inserted “uint” as the most obvious envelope type.

Allowing negative values for transport-proto certainly would be possible.
As a design pattern, I try to reserve broad ranges like this for the indication of differences that a receiver can act upon without understanding the details, such as the difference between base attributes and other attributes in SenML.

So I still would favor sticking with uint for now and carving out a range of that for experimental.

Grüße, Carsten

> On May 30, 2017, at 22:53, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jun 2017 15:48:45 +1200

We can do that, when we need it. To get the draft out of the door, I'll do what

    Brian