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

["Dearlove, Christopher (UK)" <[e-mail]>]

Ben

Thanks for that.

You will shortly see a -07. This does not address your discuss or other comments (except where the same point has been made by someone else). Those we will handle in a -08, which we will do as soon as possible. But the -07 was ready to go, to satisfy AD request to have it out by later this week, so we'll not delay that.

Christopher

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  [phone]  |  E: [e-mail]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP


-----Original Message-----
From: manet [mailto:[e-mail]] On Behalf Of Ben Campbell
Sent: 03 July 2017 22:49
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [manet] Ben Campbell's Discuss on draft-ietf-manet-rfc5444-usage-06: (with DISCUSS and COMMENT)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Ben Campbell has entered the following ballot position for
draft-ietf-manet-rfc5444-usage-06: 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 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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have one discuss point that I hope will be easy to fix.

-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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

- 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.

- 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.

-1, third paragraph, last sentence:
It's not clear to me whether this means protocol and port numbers that were allocated by 5498, allocated after 5498, or allocated following the rules in 5498.

-1.1, first paragraph: Why the scare quotes around "forward compatibility"?

-2: You include the 2119 boilerplate, but much of this draft uses those terms in ways that are different than intended by 2119.  For example, using MUST, SHOULD, etc to put requirements on how people design new protocols. I don't object to using the language that way, but it would be good to clarify the intent in section 2.

-3, first paragraph: s/"that are using"/"that use"

-4.3, 2nd paragraph: I'm a little confused by "MUST be recognized...". Does "recognized" in this context mean the same as "identified"? If so, I suggest using the latter. Also, that MUST seems like a statement of fact.

- 6.2: Does this mean to talk about attributes and addresses in the _same_ address block, rather than just attributes and addresses in an address block?

- 6.3
-- 3rd paragraph: s/"RFC7188] required" / RFC7188] requires"   ; unless it no
longer requires it. -- 5th paragraph: RFC7188] RECOMMENDS seems like a statement of fact. (Please don't use 2119 keywords to describe requirements that are defined elsewhere, unless in a direct quote.)


_______________________________________________
manet mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/manet


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************