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

[Jouni Korhonen <[e-mail]>]

Hi Steven,

7/23/2015, 12:43 AM, Steven Barth kirjoitti:
>
>> 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.
>
>>
>>> 3 I'm unsure if cross references to the draft that in turn references this
>>> 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..
> Okay, not that important I suppose, personal feelings is just that circular references are bit uncomfortable, but feel free to ignore.

Point taken. Thanks.

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

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

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

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

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

Okay. Thanks. Will take a look into this.

- Jouni

>
>
>
> Cheers,
>
> Steven
>
>
>