[Rmt] AD followup for draft-ietf-rmt-flute-revised-12

["David Harrington" <[e-mail]>]

draft-ietf-rmt-flute-revised-12 AD Followup

*** WG take note ***
I am suggesting tightening some RFC2119 language; if you object to
specific changes please speak up. 

There are a few issues I found in my followup review, mostly about
RFC2119-like language.
I also had some questions that might just be my misunderstandings.
If you can get them addressed before the cutoff on 7-11, we might be
able to advance the draft in the process before ietf81.

1) in Introduction, it says version "may not be"
to avoid confusion, please use might not.
better yet, state whether it is or is not backwards compatible. I can
submit this as is, but I expect it will get pushback from other IESG
members for being unclear. If there is a lack of  WG consensus on this
point, then document that in the shepherd writeup.
2) in 3.1, s/MAY NOT/might not/
3)    "The TOI value of '0' MUST be reserved for delivery of FDT
Instances.  The use of other TOI values for FDT Instances is outside
the scope of this specification." Shouldn't this specification at
least define the range and type of values; are these integer values?
If it is not in scope for THIS specification, what specification is it
in scope for?
4) This document defines new extensions to LCT and ALC; should this be
declared as Updates LCT and ALC?
5) " In any case, both a sender and a receiver can determine to which
(136 year) epoch the FDT Instance expiration time value pertains to by
choosing the epoch for which the expiration time is closest in time to
the current time." Can you provide an example? I find this unclear. I
am especially unclear about edge cases, such as for when the
expiration time and current time are in different epochs.
6)    "The space of FDT Instance IDs is limited"; where is this space
limit specified?
7) "   *  The receiver SHOULD NOT use a received FDT Instance to
interpret" - SHOULD implies there are valid reasons nto to comply with
this rule. What are the valid exceptions? or should this be a MUST
NOT?
8) "should achieve" and "should be delivered"; are these RFC2119
shoulds? if so please capitalize; if not please change the wording.
9) "   Senders SHOULD NOT re-use an FDT Instance ID value that is
already in" why not MUST NOT?
"value that is currently used by a non expired FDT Instance SHOULD be
considered as an error case." why not MUST?
10) in 3.4, the field SHOULD be ignored. why not MUST?
11) 3.1 says compliant implementations MUST set the flute version to
2; 3.4.1 says something similar. 
section 6 says the information is optional. these seem contradictory.

Comment:
1) 1.1.4 missing period at end of sentence.
2) references are out of date, because I took so long to followup.
idnits tools can help identify the needed updates.
3) LCT needs expansion on first use
4) in 3.2, is unmapped TOI handlng described elsewhere, such as in LCT
or ALC?
I think the IESG could push back on why isn't this an error with a
defined response by the receiver. It would help if the text was
explicit about the handling, or explained why the situation could
occur in compliant implementations.
5) s/may be lost/might be lost/

David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)