Re: [Rift] Genart early review of draft-ietf-rift-rift-08

[Tony Przygienda <[e-mail]>]

On Mon, Oct 28, 2019 at 2:16 PM Robert Sparks <[e-mail]>; wrote:

>
>
>
>
>>
>> Some high-level points before going into a document-order set of comments:
>>
>> ** The IANA considerations section does not provide a clear set of
>> instructions
>> for IANA to follow.
>>
>
> Ok, could you be a little bit more specific
>
> You can get AD help here. See section 2.2 of
> https://datatracker.ietf.org/doc/rfc8126/.
>
> 9.2 is where I am concerned.
>
> Please add an explicit statement that you are asking IANA to create a new
> top-level registry named RIFT with the following subregistries under it.
>

yes, no problem.


>
>
>
>>
>> The nested numbered lists in section 5.2.3.9 are perhaps not the best
>> tool for
>> describing the algorithms you want to convey. On page 46, steps 4.3.3 and
>> 4.4
>> are comments, not actions. Numbering them as you number actions is
>> confusing.
>>
>
> any better suggestions? (I will move from numbering to number.latin.other
> and so on). This is
> an old technique in protocol specs to allow implementors to discuss very,
> very precise statement
> and their meaning (e.g. ISIS spec is all written like that). Otherwise
> people start to talk about
> "4th line in the algorithm X" which is far more confusing.
>
> number.latin.other will help.
>

ok, thanks

>
> rfc2txt does not have a mechanism to "skip numbering for this item" when
> genreeating
> lists unless I'm oblivious to it so I'm limited by the tools IETF provides
> to render documents.
>
> Do you mean xml2rfc when you say rfc2txt?
>

yes, correct. sorry.


>
>
>
>>
>> It's particularly unclear what you are trying to achive with the
>> "DirectionMaxValue" registry entry defined in 9.2.11.1 Are you trying to
>> say
>> the registry is not allowed any more values? If so, just say that in the
>> instructions to IANA. I don't see where the codepoint is used by the
>> protocol,
>> so I suggest it not be added to the registry.
>>
>
> implementation specific basically. Can be removed but allows in
> implementation to
> use the codepoint to scale arrays for example.
>
> If the registry takes
>
> DirectionMaxValue
>
>
> for e.g. version 3.0 schema this value could move. Alternately we could split a registry
> _per schema version_ but that seems a huge proliferation and replication.
>
>
> I'm agnostic either way and would like to hear an opinion here
>
> I'll punt this to the group/AD.
>

ack


>
>
>
>>
>> Also in Appendix A, I question the sentence "The >: relationship is
>> symmetric
>> but not transitive". Symmetric says "if A>:B then  B>:A".
>>
>
> yes, symmetric means "if A>:B then  B>:A" precisely what you say and the
> relation holds.
>
> non transitive means obviously that
>
> A>:B and B>:C does NOT imply A>:C
>
> Obvious example of the 3-bit arithmetic is
>
> 4 >: 2 & 2 >: 0 does NOT follow in 4 >: 0
>
> I will reread. 4 >: 2 and 2 >: 4 surprises me.
>

oh, sorry, that's the objection, I thought you objected to transitive and
focused on that. yes, you're correct, it's not symmetric, I was blind and
implied

4 >: 2  <=>  2 <: 4

which is not symmetry of course. I will correct.


>