Re: [EXP2STD] Remaining LCT and ALC issues

Rod,

Regarding SCT, I suggest we simply send mails to the groups we are involved in noting that this discussion is taking place and suggesting that people with concerns should raide them on the RMT list.

Regarding IPR, the original text was incorrect and really we should just use the boilerplate text which edes people to the declarations website unless we actually know of IPR.

...Mark
Sent from my BlackBerry wireless handheld.

-----Original Message-----
From: <[email protected]>
Date: Thu, 10 Nov 2005 10:06:56 
To:<[email protected]>, <[email protected]>, <[email protected]>
Subject: RE: [Rmt] [EXP2STD] Remaining LCT and ALC issues

Hi Mike

Thanks for the response, please see in-line 

>1)     We have discussed previously (and there is reference in the FEC

OK, LCT reserves, ALC defines.

>2)     It has been suggested that the present definition of Sender
>I like this idea. However, this is a significant change if SCT 
>has been used and the message needs propagating to current 
>FLUTE implementers, DVB-CBMS, OMA-BCAST and 3GPP-SA4 to give 
>them time to comment. Given the target for standards track 
>this year, that seems unlikely.
>*** I don't think 3GPP SA4 ever uses the SCT (should be 
>checked) and I'm pretty sure the same is true for DVB-CBMS 
>(should be checked).  I have no clue about OMA-BCAST, but it 
>is worth checking.  If none of these use SCT then it seems 
>like this is pretty easy to do now and should be done, 
>otherwise I agree with you Rod.

Use of SCT is allowed. There are various timers in CMBS, BCAST and SA4
which may be assumed to use SCT (hopefully not). It looks likely that
SCT in SA4 is going to become useless after next week's SA4 meeting (as
the level of synchnorisation will be proposed). However, it is correct
to make this clear in SA4 as all contributing companies may have begun
work assuming that SCT as currently specified is frozen since it's in
rel. 6. Likewise for BCAST and CMBS (though I an not up-to-date as to
whether SC is of use there).

My opinion is that SCT holding an NTP timestamp of the FLUTE sender's
clock is a good idea - and I think it will be fine - but those others
need checking against to be sure it won't break anything already doen
based on the FLUTE RFC. (Obviously there will be those with an interest
for specifying this for LCT and ALC sender too :)

BTW, the kind of clock needs describing. Obviously NTP format, but how
about the synchronisation. I guess we allow full NTP, but also lesser
SNTP-level sync as well as "anything else". Would it be wise to
recommend synchronisation across a system or just note to implementers
that they must take care of this and the drift/accuracy for their
deployment?

>3)     ALC includes a statement that the IETF had been notified of
>The ALC 
>Experimental RFC says that the IETF had been notified of IPR 
>with respect to ALC, and Mark is saying that there is no such 
>IPR declared against ALC in the IETF IPR pages, and thus the 
>statement that the IETF has been notified of IPR with respect 
>to ALC should be removed from ALC.

I thought the current declaration was along the lines of "the authors
have declared any IPR they know of" - since it's absolutely impossible
to be sure that there isn't something that none of us have heard of
lurking in the depths of some patent office in some far flung place. If
I'm mistaken then, OK let's change to the one that indicates that any
known IPRs have been declared (and if none have actually been declared
implies that none are known).

Cheers, Rod.

_______________________________________________
Rmt mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt