Subject: [Gen-art] GEN-ART LC review of draft-ietf-avtcore-clksrc-09

From: Scott Brim <[email-masked]>
Date: Mon, 13 Jan 2014 13:20:23 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-avtcore-clksrc-09
Reviewer: Scott Brim
Review Date: 2014-01-13
IETF LC End Date: 2014-01-16
IESG Telechat date: (if known)

Summary: Ready with a minor issue

Major issues:

Minor issues:

In 6.1.2 and 6.1.3: "If the answerer rejects the offer because the
available reference clocks are incompatible, the rejection MUST
contain at least one timestamp reference clock specification usable by
the answerer." If the answerer suggests a clock that is not among
those offered, what happens next?  The offerer could abort, but could
it start over and use what the answerer suggested? That's not
documented -- is it obvious to those more familiar with SDP?

Scott

---

From: Aidan Williams <[email-masked]>
Date: Thu, 16 Jan 2014 15:57:59 +1100 (EST)

Hi Scott, 

Thanks for the review. 

The model described in the draft is declarative and it is expected that the receiver will choose to adapt in the event that shared clocks are not available, or reject the offer. The SDP is expected to be used SIP offer/answer and also with protocols similar to SAP. The sender declares the set of reference and/or media clocks is using and the receiver signals back if there is an acceptable match. The receiver may choose to receive the stream even if some or all the clocks are not in fact shared (e.g. by receiving media without time synchronisation (section 6) or by using rate conversation for the media). 

If the senders' offer is rejected, that would mean that either the clocks are not shared, or the receiver is not prepared to adapt. In this case there is little prospect that the sender could usefully start over with a different set of reference and/or media clocks. 

I trust the above comments are clarifying. We kicked the offer/answer text around the WG a few times and I believe the text is comprehensible to those familiar with SDP. 

regards 
aidan 
____ 
:wq! 

----- Original Message -----

> From: "Scott Brim" <[email-masked]>
> To: "draft-ietf-avtcore-clksrc all"
> <[email-masked]>, "gen-art"
> <[email-masked]>
> Sent: Tuesday, 14 January, 2014 5:20:23 AM
> Subject: GEN-ART LC review of draft-ietf-avtcore-clksrc-09

---

From: Scott Brim <[email-masked]>
Date: Thu, 16 Jan 2014 15:22:33 -0500

> Hi Scott,

Hi Aidan. Let me try to be clearer. My problem is with the sentence:
"If the answerer rejects the offer because the available reference
clocks are incompatible, the rejection MUST
contain at least one timestamp reference clock specification usable by
the answerer."

"If the answerer rejects the offer because the available reference
clocks are incompatible, ..."

As you say, in this case there is little prospect that the sender
could usefully start over. Therefore why would the answerer include,
in the rejection, a clock that is usable by him (the answerer)?

"... the rejection MUST contain at least one timestamp reference clock
specification usable by the answerer."

Either there's no point in the rejection including a reference clock,
or there is.  If there is no point, why do you say a reference clock
MUST be included?  If there is a point, that means there is some
expectation that the sender might do something with the reference
clock in the rejection. What is that expectation? It would be good to
document it.

Is that clearer?

Thanks ... Scott

---

From: Aidan Williams <[email-masked]>
Date: Fri, 17 Jan 2014 10:16:25 +1100 (EST)

Hi Scott, 

Thanks for the clarification.. it helped. 

The inclusion of the receivers reference clock in a rejection is intended to allow useful information to be logged and provided to the system operator. An operator should be able to look at a log file (or a packet trace) and understand why the clksrc signaling failed. We did consider just rejecting with no extra information, but felt it would be more useful to offer information that was likely to be useful to the operator. We did not expect the information to be used to re-start negotiation. 

The motivational discussion didn't make it into the document.. I guess you feel a sentence describing the motivation/expectation would be helpful? What are the mechanics of making a change at this stage: would such a change involve a -10 of the draft or can we do it as a final editorial tweak? 

- aidan 

----- Original Message -----

> To: "Aidan Williams" <[email-masked]>
> Cc: "draft-ietf-avtcore-clksrc all"
> Sent: Friday, 17 January, 2014 7:22:33 AM
> Subject: Re: GEN-ART LC review of draft-ietf-avtcore-clksrc-09

---

From: Scott Brim <[email-masked]>
Date: Thu, 16 Jan 2014 18:45:03 -0500

Got it! Now that I understand, this is a simple editorial fix. How about
adding ", for information." or ", for logging."? Something like that.

I leave it to Jari whether you need a new version, but I would tell the WG
what you decide to do in any case. Since it's just editorial and doesn't
change anything substantial, imho you could even put it off until AUTH48
time.

Thanks!

Scott

---

From: "Roni Even" <[email-masked]>
Date: Fri, 17 Jan 2014 11:34:55 +0200

Hi Aidan,
You should look at all LC comments (I saw none and the LC finished
yesterday) and at the comments from the AD review (from Richard).
To me they look like editorial so you can put a new revision after
addressing Richard's comments
Roni Even

> -----Original Message-----
> From: Gen-art [mailto:[email-masked]] On Behalf Of Scott Brim
> Sent: 16 January, 2014 10:23 PM
> To: Aidan Williams
> Cc: draft-ietf-avtcore-clksrc all; gen-art
> Subject: Re: [Gen-art] GEN-ART LC review of draft-ietf-avtcore-clksrc-09
> 
> "If the answerer rejects the offer because the available reference clocks
are
> incompatible, the rejection MUST contain at least one timestamp reference
> clock specification usable by the answerer."
> 
> "If the answerer rejects the offer because the available reference clocks
are
> incompatible, ..."
> 
> As you say, in this case there is little prospect that the sender could
usefully
> start over. Therefore why would the answerer include, in the rejection, a
clock
> that is usable by him (the answerer)?
> 
> Either there's no point in the rejection including a reference clock, or
there is.
> If there is no point, why do you say a reference clock MUST be included?
If
> there is a point, that means there is some expectation that the sender
might do
> something with the reference clock in the rejection. What is that
expectation?
> It would be good to document it.
> 
> Is that clearer?
> 
> Thanks ... Scott
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art