Subject: [dhcwg] RFC 3315 ambiguity about MRC

From: Francis Dupont <[email-masked]>
Date: Mon, 03 Dec 2007 20:24:41 +0100

The RFC 3315 (DHCPv6) is ambiguous about the real meaning of MRC (in 14.):
 - the name means "Maximum retransmission count"
                           ^^

 - the text says:

   MRC specifies an upper bound on the number of times a client may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the client has transmitted the message MRC times.
                       ^^^^^^^^^^^

so does the MRC include the initial transmission?
A good case for an erratum...

Regards

[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 14:57:30 -0500

> so does the MRC include the initial transmission?

How would you interpret it other than that you must transmit no more  
than MRC messages?   Do you think it can legitimately be interpreted  
to say transmit MRC+1 messages?   And in any case, what's the downside  
if someone is off by one?

---

From: Francis Dupont <[email-masked]>
Date: Mon, 03 Dec 2007 22:14:24 +0100

In your previous mail you wrote:

   than MRC messages?

=> the choice is between transmit and retransmit: this is not the same.

   Do you think it can legitimately be interpreted  to say transmit
   MRC+1 messages?

=> of course yes: if there is a choice there is a 100% probability to see
two persons doing different choices.

   And in any case, what's the downside if someone is off by one?

=> nothing critical but requirements have to not be ambiguous if you'd
like to get compliant implementations...

Regards

PS: you seem to believe the intention is to have N (not N+1) packets
transmitted. I agree but the name MRC should be MTR.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Dec 2007 17:04:54 -0500

> => the choice is between transmit and retransmit: this is not the  

Ah, yes, I see your point.   I focused on the word "transmitted" and  
didn't notice that it had been used interchangeably with "retransmit"  
in the same paragraph.   So yes, this is probably worth an erratum.

---

From: Alain Durand <[email-masked]>
Date: Mon, 03 Dec 2007 17:05:31 -0800

I agree with Francis, the spec is a bit unclear...

We can either change the name of the variable from MRC to MTC or change the
following text in section 14:

old:

new:
   MRC specifies an upper bound on the number of times a client may
   retransmit a message.  Unless MRC is zero, the message exchange fails
   once the client has re-transmitted the message MRC times.

In practice, this doesn't change much, but this is not a reason not to clean
up the spec, either via an errata to RFC3315 or as part of RFC3315-bis

   - Alain

---

From: Hiroshi MIYATA <[email-masked]>
Date: Tue, 4 Dec 2007 10:51:17 +0900

Thanks for your clarification.
The clarification is very important for test provider like us, TAHI  
project.

If RFC modification required, the latter proposal seems to be easier  
to keep consistency,
since the RFC focuses on REtransmission when it states MRC.

Thanks,

...miyata