Opened 12 years ago

Closed 12 years ago

#31 closed defect (fixed)

Dave Thaler's Comments

Reported by: Bernard_Aboba@… Owned by: bernard_aboba@…
Priority: major Milestone: milestone1
Component: draft-iab-extension-recs Version: 1.0
Severity: Active WG Document Keywords:
Cc:

Description

Section 4:
The section is entitled considerations for the base protocol.
However bullets 3-6 are worded as considerations for a proposed
extension. This needs to be rationalized. Maybe split into
two lists.

Section 3.4:

Typically, profiles are
constructed by narrowing potential implementation choices or by
removing protocol features.

I'll add that the above is true, there are two types of profiles:
a) One that removes required functionality (thus generally breaking interop)
b) One that elevates requirement levels, generally from a MAY/SHOULD
to a MUST, in order to improve interoperability by narrowing potential
implementation choices.

Type (a) is what many (myself included) would consider harmful.
Type (b) is beneficial, but is often only necessary when the underlying
protocol itself is ill-defined so as to permit multiple non-interoperable
compliant implementations (this is the norm in some SDOs, and
probably a good thing to recommend against in section 4's considerations
for a base protocol).

Section 3.6:
This section appears to encourage site-specific/experimental
codepoints, whereas the last paragraph of section 3.2 can be read as
giving contradictory guidance, implying it is harmful. The two
paragraphs need to be rationalized so the message is the same.

Section 4.5:

negotiation against a bidding-down attack while retaining backward

I'm not sure all readers will be familiar with the term "bidding-down
attack". Is there an informative reference that could be added?
Or define it in context. Section 5 already contains the phrase
"allow negotiation down to an older, less secure algorithm"
which might be sufficient.

Nits

Section 3.2:

Internet Message Format standard when it was was updated in 2001

s/was was/was/

Section 4.1:

implementations need to be able to accept packets of known type

s/type/types/

Change History (1)

comment:1 Changed 12 years ago by bernard_aboba@…

  • Resolution set to fixed
  • Status changed from new to closed

I believe these comments are resolved in -06.

Note: See TracTickets for help on using tickets.