Subject: [mif] Comments on draft-ietf-mif-mpvd-id-01

From: Steven Barth <[email-masked]>
Date: Wed, 22 Jul 2015 09:11:34 +0200

Hello everyone,

below a few comments for the MPVD ID draft.

3 I'm unsure about the id-length field. It seems entirely redundant for e.g.
DHCP(v6) purposes and even considering e.g. RAs it is redundant for half of
the given id-types. Should this be type-specfic instead?

3 I'm unsure if cross references to the draft that in turn references this
one are wise, also wrt. informative / normative reference sections.

3 id-type
Encoding and / or allowed lengths are entirely unclear for most types you declare.
Are they supposed to be strings, BE integers, ...? How big are they supposed to be?
Shall I be able to use 16, 32 or maybe even 24bit numbers for representing the OID?

0x04: RFC 4282 specifies the assignment of NAI Realms to be tied to domain names,
so this type seems mostly redundant since you alreay have FQDN.

0x06: This looks overly specific to me. Why not have a generic (unicast) prefix type,
so people could also use their RIPE / ARIN / ... assigned UC addresses? E.g. prefix
length followed by arbitrary length ipv6 prefix.

4 What if I want to use this outside a configuration protocol?

4 Undefined reference to "PVD container option"

In general 4 seems awkward / misplaced here, since you are defining an abstract identifier.

Cheers,

Steven

---

From: Steven Barth <[email-masked]>
Date: Wed, 22 Jul 2015 09:44:58 +0200

> the given id-types. Should this be type-specfic instead?
Actually strike that, I should not review this early in the morning.
Anyway it makes sense to allow for future id-types to be
skippable, still may be debatable whether it should be depending on if
the configuration or whatever protocol actually requires it.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 22 Jul 2015 21:53:57 -0700

Steven,

Thanks for the review. See my initial comments inline.

> the given id-types. Should this be type-specfic instead?

We need the length information for NDP case where the option carrying 
the ID has the length expressed in the units of 8. I do not like the 
idea of having different encodings based on the type. The "optimization" 
would be not be big enough to justivy that imho.

> one are wise, also wrt. informative / normative reference sections.

Referencing will explain the context better. Informative reference 
ensures that the document won't be blocked if the two referenced 
documents are not ready yet..

> Shall I be able to use 16, 32 or maybe even 24bit numbers for representing the OID?

Will check the OID case. Most of the identifier formats have their 
"natural" encoding explained in their respective RFCs but having exact 
text here regarding coding would be good to avoid confussion. Thanks for 
pointing it.

> so this type seems mostly redundant since you alreay have FQDN.

NAIs are different to FQDNs. Tieing NAIs to DNS administration is an 
"easy" way to guarantee they come from a managed nameespace. This is 
typical for example with AAA protocols.

> length followed by arbitrary length ipv6 prefix.

Good point. Will consider that.

> 4 What if I want to use this outside a configuration protocol?

You just do it. The PVD-ID is not explicitly tied to MPVD configuration 
protocols (two of those at the moment).

> 4 Undefined reference to "PVD container option"

What do you mean?

> In general 4 seems awkward / misplaced here, since you are defining an abstract identifier.

4 meaning option type 0x04?

- Jouni

>
>
>
> Cheers,
>
> Steven
>
>
>
>
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Steven Barth <[email-masked]>
Date: Thu, 23 Jul 2015 09:43:27 +0200

> We need the length information for NDP case where the option carrying the ID has the length expressed in the units of 8. I do not like the idea of having different encodings based on the type. The "optimization" would be not be big enough to justivy that imho.
Yes, understood, makes sense.

> Referencing will explain the context better. Informative reference ensures that the document won't be blocked if the two referenced documents are not ready yet..
Okay, not that important I suppose, personal feelings is just that circular references are bit uncomfortable, but feel free to ignore.

> Will check the OID case. Most of the identifier formats have their "natural" encoding explained in their respective RFCs but having exact text here regarding coding would be good to avoid confussion. Thanks for pointing it.
Yeah, e.g. for UUID it wasn't clear to me if it refers to binary or string notation. FQDN basically the same and it didn't even reference any RFCs. I suppose RFC 1035 without "compression" was your intention here?

> NAIs are different to FQDNs. Tieing NAIs to DNS administration is an "easy" way to guarantee they come from a managed nameespace. This is typical for example with AAA protocols.
I was mostly basing this comment on the IANA Considerations Section in RFC 4282, but if there is legitimate reason I guess its fine.

> You just do it. The PVD-ID is not explicitly tied to MPVD configuration protocols (two of those at the moment).
>
>>

The 3 comments above were all intended to refer to Security Considerations (= Section 4).
Maybe to elaborate a bit more: You are only talking about Security Considerations in connection
with configuration protocols, therefore my first question. You also mention the "container option"
the first and only time in that section and it seems to be not really obvious what you are referring
to. All in all (comment 3) I think since this is just an abstract ID format that should be used in many
different usecases, maybe just mentioning that instead of a security considerations which applies
to some example usecases like NDP and DHCPv6.

Cheers,

Steven

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 Jul 2015 04:31:31 -0700

Hi Steven,

> Okay, not that important I suppose, personal feelings is just that circular references are bit uncomfortable, but feel free to ignore.

Point taken. Thanks.

> Yeah, e.g. for UUID it wasn't clear to me if it refers to binary or string notation. FQDN basically the same and it didn't even reference any RFCs. I suppose RFC 1035 without "compression" was your…

I'll take a stab on this and will clarify. Should be "easy" if we end up 
to a single ID to be supported ;)

> I was mostly basing this comment on the IANA Considerations Section in RFC 4282, but if there is legitimate reason I guess its fine.

Ok. NAIs and FQDNs are likely to be removed if we end up using only a 
single ID type.

> to some example usecases like NDP and DHCPv6.

Okay. Thanks. Will take a look into this.

- Jouni