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

[Roni Even]

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:gen-art-boun...@ietf.org] 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
> 
> On Wed, Jan 15, 2014 at 11:57 PM, Aidan Williams
>  wrote:
> >
> > 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
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Scott Brim]

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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Aidan Williams]

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 -

> From: "Scott Brim" 
> To: "Aidan Williams" 
> Cc: "draft-ietf-avtcore-clksrc all"
> , "gen-art"
> 
> Sent: Friday, 17 January, 2014 7:22:33 AM
> Subject: Re: GEN-ART LC review of draft-ietf-avtcore-clksrc-09

> On Wed, Jan 15, 2014 at 11:57 PM, Aidan Williams
>  wrote:
> >
> > 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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Scott Brim]

On Wed, Jan 15, 2014 at 11:57 PM, Aidan Williams
 wrote:
>
> 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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Aidan Williams]

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" 
> To: "draft-ietf-avtcore-clksrc all"
> , "gen-art"
> 
> Sent: Tuesday, 14 January, 2014 5:20:23 AM
> Subject: GEN-ART LC review of draft-ietf-avtcore-clksrc-09

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

> .

> 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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art