[pim] Re: draft-ietf-pim-gaap-11 early Rtgdir review

Sandy, I have submitted -12 to reflect your comments. Thanks very much for them. Mike is on board with them as well.

> > ZZ> Because the Group Name is variable-length, the message length may be
> > unpredictable based on the Record Count. Furthermore, if the Group Name length
> > isn't fixed, how do we determine the starting position of the next record? Is
> > it determined by the string terminator "\0"? If it's determined by the string
> > terminator, then the next record could start at any position, even a non-8-bit
> > aligned position. Is that acceptable?
> 
> The starting point of the next record is after th "\0" character/byte. Yes, the next record can start on any byte, short-word, or long-word boundary. This happens all the time (all over the place in OSI protocols since many fields are byte-granularity and variable length).
> 
> Sandy> Okay, this approach differs from that used for routing devices; as long as the API is acceptable, it's fine.

It works, I have a tested implementation and have used the approach in other protocol implementations.

> Its a one-way hash, so a given group name can only have one hash value. Low-probabilistically another group name could hash to the same value.
> 
> If any collision does not resolve quickly, the encryption key is unique so groups don't get joined together from the app level.
> 
> Sandy> Okay, it would be even better if this could be reflected in the draft, especially for people who are not very familiar with RFC6234.

I will indicate there are two ways collisions can occur, one from multiple group names choosing the same hash and for a hash truncation into the address which makes produces a duplicate group address.

> No, the collision occurs because there are not enough random bits to hold the hash in a group address. So there could be a many-hash to one group address conflict.
> 
> By definition, all apps that use the same group name, will probablistically use the SAME group address.
> 
> The answer to your last question is, absolutely no. Because the group address, per this specification, is always derived from the group name (and this algorithm allocation is with the GAAP IANA assigned block). And we have decdied to make that a /10 IANA request for IPv4.
> 
> Sandy> Thank you for your explanation. Based on these explanations, I understand clearly that as long as applications use the same Group Name, they will definitely get the same Group Address. However, in some cases, different Group Names might result in the same Group Address. This is the conflict that needs to be resolved.
> If possible, hope these detailed explanations can be further clarified in the draft.

Will do.

> Sandy> I think you mean that if the message is encrypted, it cannot be correctly parsed without the corresponding key, and the marker set to 0xAAAAAAAA cannot be seen. 

Correct. I will make this clearer in the draft.

> Therefore, in a plaintext scenario, it's only necessary to check if the marker is set to 0xAAAAAAAA; for a ciphertext scenario, the correct key is required to correctly parse the message and verify if the marker is set to 0xAAAAAAAA. 

Only after decryption. So if the receiver has the wrong key or no key, then it cannot see the 0xAAAAAAAA.

> If this understanding is correct, it would be even better if you could explain the plaintext and ciphertext scenarios separately in the draft.

Okay.

Thanks again,
Dino & Mike

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]