Subject: [MMUSIC] ICE-18 Nominating pairs on controlled agents

From: "Adam Fisk" <[email-masked]>
Date: Mon, 8 Oct 2007 17:11:59 -0400

Apologies for the comments so late in the game on the ICE drafts, but there
appears to be a minor error in the nominating of pairs on controlled agents.

Section 7.1.2.2.4 on performing STUN client connectivity checks reads:

"If the agent is the controlled agent, the response may result in the valid
pair having its nominated flag set. See section 7.2.1.5 for the procedure."
    -- http://tools.ietf.org/html/draft-ietf-mmusic-ice-18#section-7.1.2.2.4

7.2.1.5 then reads:

"If the Binding Request received by the agent had the USE-CANDIDATE attribute
set, and the agent is in the controlled role, the agent looks at the state
of the pair computed in Section 7.2.1.4:"
    -- http://tools.ietf.org/html/draft-ietf-mmusic-ice-18#section-7.2.1.5

Shouldn't the last part of 7.2.1.5 at least read: "the agent looks at the
state of the pair computed in Section 7.2.1.4 or in Section 7.1.2.2.4:"?
Otherwise, you'd just immediately ignore then whole of section 7.2.1.5 when
processing pairs computed from section 7.1.2.2.4.

That's it for the "error" -- almost more a nit really.  Digging a little
deeper, though, it seems to me that the nomination decision for the
controlled agent in 7.1.2.2.4 should be really simple and should not have to
reference section 7.2.1.5 at all.  Basically, if the pair received
USE-CANDIDATE in the past, it should be nominated.  This is because the pair
has just reached the successful state when we get to section 7.1.2.2.4, so
all we need to know is whether or not we've received USE-CANDIDATE yet or
not.

Does that make sense?  I think referencing 7.2.1.5 makes it seem like a more
complicated decision than it is, is much harder to understand, and breaks up
the document flow.  Those issues aside, though, it seems like the opening of
7.2.1.5 should at the very least acknowledge that the pair could have also
come from 7.1.2.2.4.

Again, I hate to bring this up so late in the game, but I only just noticed
it.

Thanks.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 Oct 2007 18:36:35 -0400

Adam Fisk wrote:
> Apologies for the comments so late in the game on the ICE drafts, but 
> there appears to be a minor error in the nominating of pairs on 
> controlled agents.
> 
> "If the agent is the controlled agent, the response may result in the 
> valid pair having its nominated flag set. See section 7.2.1.5 
> <http://7.2.1.5> for the procedure."
> 7.2.1.5 <http://7.2.1.5> then reads:
> 
> "If the Binding Request received by the agent had the USE-CANDIDATE 
> attribute set, and the agent is in the controlled role, the agent looks 
> at the state of the pair computed in Section 7.2.1.4:" 
>     -- 
> http://tools.ietf.org/html/draft-ietf-mmusic-ice-18#section-7.2.1.5 
> <http://tools.ietf.org/html/draft-ietf-mmusic-ice-18#section-7.2.1.5>
> 
> Shouldn't the last part of 7.2.1.5 <http://7.2.1.5> at least read: "the 
> agent looks at the state of the pair computed in Section 7.2.1.4 
> <http://7.2.1.4> or in Section 7.1.2.2.4:"?  Otherwise, you'd just 
> immediately ignore then whole of section 7.2.1.5 <http://7.2.1.5> when 

I agree this is confusing, though it is correct. The case here is this. 
An agent is controlled. It gets a request with a USE-CANDIDATE. This 
causes the triggered check (7.2.1.4). That check produces a response. 
Once that response arrives, the pair from the *original request* now has 
its nominated flag set. So 7.1.2.2.4 is trying to say, "hey, this 
response might be for a triggered check that you sent as a result of the 
processing of 7.2.1.5, so you may need to follow its directions now". 
I'll make that more clear.

> controlled agent in 7.1.2.2.4 should be really simple and should not 
> have to reference section 7.2.1.5 <http://7.2.1.5> at all.  Basically, 
> if the pair received USE-CANDIDATE in the past, it should be nominated.  
> This is because the pair has just reached the successful state when we 
> get to section 7.1.2.2.4, so all we need to know is whether or not we've 
> received USE-CANDIDATE yet or not. 

And this is what the text is saying (or trying to at least). Hopefully 
this text is clearer now:

<t>
If the agent is the controlled agent, the response may be the result
of a triggered check which was sent in response to a request which 
itself had
the USE-CANDIDATE attribute. This case is described in
<xref target="sec-up-fav"/>, and may now result in setting the
nominated flag for the pair learned from the original request.
</t>

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com