Again cherry-picking in line, as I'm on vacation travel this week:
On 23/05/2017 13:25, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-anima-grasp-12: 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-anima-grasp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Substantive:
>
> -3.5.2.1: "Messages MUST be authenticated and encryption MUST be
> implemented."
> Should the latter be "... MUST be used"? It seems odd for authentication
> to be MUST use, but crypto to only be MTI.
This was a bit of a compromise between the authors. Personally I'd prefer
MUST be used, but we'd need to ask the WG.
>
> -3.5.4.3: "An exponential backoff SHOULD be used for subsequent
> repetitions, to limit the load during busy periods."
> Why not MUST? Also, is there a retry limit? (Comment applies to the
> other sections that mention retries with exponential backoff)
Personally I'm reluctant to specify this too tightly. I'd expect the
retry limit to be use-case dependent; there might be cases where trying
for ever is the right thing to do. Similarly for the strictly exponential
backoff; for example, backing off to one try per minute might be reasonable
for a given application, or to one try per hour for another.
>
> -3.5.6.2: "To ensure that flooding does not result in a loop, the
> originator of
> the Flood Synchronization message MUST set the loop count in the
> objectives to a suitable value "
> I assume this is true for discovery and negotiation as well? I don't
> think it was mentioned in those sections (although I think I saw a
> related mention in the message format sections.)
Discovery and flooding are multicast, so it really is about loop
prevention. I thought we did say the same for discovery, if not
that needs fixing. In negotiation it's a bit different - it's part
of the semantics of the application (how many rounds of negotiation
make sense) so there's not much to say from the protocol design
viewpoint.
More when I get home.
Brian
>
> - 3.10.5: "SHOULD NOT be used in
> unmanaged networks such as home networks."
> Why not MUST?
>
> -5, Privacy and Confidentiality: Did people consider IP Addresses and
> other potentially persistent identifiers as impacting privacy?
>
> -7, Grasp Message and Options table: Why "Standards Action"? Would you
> expect some harm to be done if this were only Spec Required?
>
> Editorial:
>
> - Is section 2 expected to be useful to implementers once this is
> published as an RFC? Unless there's a reason otherwise, I would suggest
> moving this to an appendix, or even removing it entirely. As it is, you
> have to wade through an unusual amount of front material before you get
> to the meat of the protocol.
>
> - Along the lines of the previous comment, I found the organization a bit
> hard to follow. I didn't find actual protocol details until around page
> 21. Procedures are split (and sometimes repeated) between the procedure
> sections and the message format sections. I think that will make this
> more difficult and error prone than necessary for implementors to read
> and reference. I fear readers will read one section and think they
> understand the procedures, and miss a requirement in the other.
>
> - 3.5.2.2: First bullet:
> Please consider a "MUST NOT construction. "MUST only" can be ambiguous.
> It would be helpful to explain why the loop count must not be more than
> one. I can infer that from the later sections on relays, but it was not
> obvious when reading this section. And unless I missed something, there's
> no text that puts the two ideas together.
>
> - 3.5.4.5: This section seems redundant to the similar sections under
> negotiation . Since those sections have more information, would it make
> sense to consolidate them there?
>
>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
