[manet] Re: Paul Wouters' No Objection on draft-ietf-manet -dlep-credit-flow-control-17: (with COMMENT)

Hi Paul,

Please see my responses below.

Thanks,
Eric

On Mon Feb 03 06:46:11 -0800 2025, Paul Wouters via Datatracker wrote:
> Paul Wouters has entered the following ballot position for
> draft-ietf-manet-dlep-credit-flow-control-17: No Objection
> 
> 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 to https://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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I suspect Deb's DISCUSS.
> 
> Note the figure in Section 2.3.1 shows 2 32 bit credit fields but the text
> describes it as one 64 bit credit field. Please fix the figure. Looking again,
> I see a ":" notation that I've never seen used before. I think the following is
> far cleaner:
> 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Credit Value                          |
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> This is also done in other sections, eg 2.3.3, 2.3.4, etc

I don't know how common it is, but the diagrams in RFC8175 (DLEP) use
this notation.  I have changed these to remove the colons.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Data Item Type                | Length (16)                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Flow Identifier (FID)         |            Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Credit Value                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Scale      |         Credit Window Max Size                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 
> In 2.3.2 the description of field "Data Item Type" should be "Data Item Type
> (TBA5)".

OK.

> 
> Flow Identifier (FID): should probably say it is a two octet value ?

OK.

> I would also use the more common ~ instead of : syntax in the diagrams
> to indicate variable length.

I've removed the colon notation, but I'm not sure where the tilde
should have been used.  The repeated Flow Identifiers in 2.3.5?

> 
> Section 4
> 
> Since this protocol has a window size of one (only one outstanding msg allowed),
> couldn't an enduser/malicious code somehow block this traffic flow from
> happening by sending bogus msgs that fill up the queue of size 1? How can an
> implementation protect itself against this?

A single outstanding message is a characteristic of DLEP and is not
specific to flow control.  If a third party injects such messages,
it's possible that there would already be an outstanding request and,
in this case, the DLEP session would be reset.  Packet injection is
covered in the Security Considerations.

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