Re: [manet] Ben Campbell's No Objection on draft-ietf-manet-rfc5444-usage-06: (with COMMENT)

[Abdussalam Baryun <[e-mail]>]

On Tue, Jul 4, 2017 at 6:36 PM, Ben Campbell <[e-mail]> wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-manet-rfc5444-usage-06: 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Substantive Comments:
>
> [The first comment is from my original DISCUSS position. I've cleared,
> because
> I think conversation is moving enough in the right direction that I expect
> people will "do the right thing". But I'm maintaining this as a comment
> because
> I still think it's awkward to use 2119 keywords to describe some future
> requirement, unless doing so as a direct "pre-quote". ]
>

I agree

>
> <old-discuss>
> -4.5, 2nd to last paragraph: The first sentence makes ambiguous use of 2119
> keywords. Saying that it is RECOMMENDED that something MAY be defined
> reduces
> to just MAY, which I don't think is what you want. Also, "only one" is
> ambiguous, in that it can mean "exactly one" or "at most one". Does the
> following capture the intent?
>
> OLD:
>    It is RECOMMENDED that a TLV Full Type MAY be defined so that there
>    MUST only be one TLV of that Full Type associated with the packet
>    (Packet TLV), message (Message TLV), or any value of any address
>    (Address Block TLV).
> NEW:
>   If a TLV Full Type is defined, it SHOULD be defined such that at most one
>   TLV of that Full Type can be associated with a given packet, message, or
>   address block TLV.
>

Ok

>
> </old-discuss>
>
> - General: I find it confusing that this document combines normative
> updates to
> RFC 5444 in the form of multiplexer rules with a bunch of rules for
> designing
> extension protocols. The former seems perfectly reasonable in a standards
> track
> document, but the latter really seems like BCP material. I don't expect
> this to
> change this late in the process, but I'd encourage people to consider
> separating that sort of thing in future work.
>

I agree with this


>
> - 4.2,
> -- 4th bullet: I don't agree that the requirement for the demuxer to remove
> TLVs added by the muxer is an implementation detail. -- 6th bullet: "...
> this
> processing will determine that the message MUST be ignored." That seems
> like a
> statement of fact.
>
> - Appendix B: The appendix contains 2119 keywords. If there are really
> normative requirements, please consider promoting it to the main body of
> the
> draft. Lots of readers will skip the appendixes.
>
> Nits:
>
> - General:
> -- The draft has quite a bit of text that summarized content from other
> drafts.
> A little of that can be useful but too much just adds unnecessary length.
> I
> suggest editing for conciseness. -- Please don't use "/" to substitute for
> conjunctions.
>
> -1, 2nd paragraph: I can't parse the first sentence. Does the following
> make
> sense:
>
> OLD:
>    [RFC5444] was designed following experiences with [RFC3626], which
>    attempted, but did not quite succeed in, providing a packet/message
>    format accommodating for diverse protocol extensions.
> NEW:
>    [RFC5444] was designed following experiences with [RFC3626], which
>    attempted, but did not quite succeed, in providing a packet and message
>    format that accommodates diverse protocol extensions.
>

I suggest we delete this word 'succeeded', because 5444 needs to be
flexible to be used and updated (it succeeded so far). So maybe we change
word 'succeed' to 'flexible',