[manet] Re: Gorry Fairhurst's Discuss on draft-ietf-manet- dlep-credit-flow-control-18: (with DISCUSS and COMMENT)

On 25/03/2025 14:49, Eric Kinzie wrote:
> Hi Gorry,
>
> On Mon Mar 24 12:01:28 -0700 2025, Gorry Fairhurst via Datatracker wrote:
>> Gorry Fairhurst has entered the following ballot position for
>> draft-ietf-manet-dlep-credit-flow-control-18: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-credit-flow-control/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I was unaware of this work in Manet, and thank you for making an interesting
>> and useful specification. I have two concerns I’d like to discuss:
>>
>> 1. The text says: “In the absence of a wildcard, a packet may not match any of
>> the data items and, in this case, SHOULD be dropped by the router.”.- Why is
>> this not a MUST? (If it needs to be a SHOULD, then please add text to explain
>> what happens whene there is no match and explain whether sending this pacekt
>> also consumens credit.)
> MUST seems appropriate.  I'll change this.
Thanks.
>> 2. If a packet is not matched and is dropped, ought it to be logged? (It would
>> be logged if there was no FID). Either way, the specification ought to explain
>> whether an entry in the log is to be expected.
> Currently, the cases where a log entry should be made are those where a
> flow control data item is received, by either side, that contains a FID
> not previously defined by the modem.  There is no logging based on what
> is seen in the dataplane.  Should this still be called out explicitly?
Understood. I do think it would help to just explain the logging 
entries. Knowing what is being logged can be very helpful when comparing 
implementations.
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I don’t think the security mechanisms are sufficiently defined to be useful.
>> Please can you explain what threats these updates are expected to counter. This
>> currently leads to two very ineffective security considerations:
> The Security Considerations give an example of the type of threat to
> which flow control might susceptible.  Other cases are given in DLEP
> (8175) and are applicable, but not specific to flow control.
>
> Your last sentence ends with a colon, so I'm not sure if your comment
> was truncated.

The truncated part was only the text: "The transport layer security 
mechanisms documented in [RFC8175] can, with some updates, be applied to 
this document." (There is a similar phrase related to Ethernet below 
this text also.)

I think the above current I-D text is likely just too terse for me to 
understand if there is a missing something or not, especially the phrase 
"with some updates", which made me wonder what sort of updates does this 
imply ?

Whereas, the text you wrote above is much clearer to me, and I think 
would help others if in the document.

Thanks for your prompt reply.

If you submit a new I-D with these changes I'd be happy to change my 
ballot position to "no objection" and not stand in the way of publication.

Best wishes,

Gorry

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]