Re: Gen-ART LC Review of draft-ietf-l2vpn-pbb-vpls-interop-05

[Ben Campbell]

Hi Ali,

Those changes would resolve my comments. 

Thanks!

Ben.

On Oct 8, 2013, at 5:13 PM, Ali Sajassi (sajassi)  wrote:

> 
> Ben,
> 
> Thanks for your comments. I have incorporated all your comments in rev06
> of this draft.
> 
> 
> On 9/23/13 1:29 PM, "Ben Campbell"  wrote:
> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document:  draft-ietf-l2vpn-pbb-vpls-interop-05
>> Reviewer: Ben Campbell
>> Review Date: 2013-09-23
>> IETF LC End Date: 2013-09-24
>> 
>> Summary: Ready for publication as an informational RFC.
>> 
>> Major issues:
>> 
>> None
>> 
>> Minor issues:
>> 
>> None
>> 
>> Nits/editorial comments:
>> 
>> -- Abstract:
>> 
>> Please expand H-VPLS on first mention
> 
> Done.
> 
>> 
>> -- section 1, 1st paragraph:
>> 
>> Please expand VPLS on first mention.
> 
> Done.
> 
>> 
>> -- section 4, 3rd to last paragraph: "Different PBB access networks..."
>> 
>> The previous and subsequent paragraphs say "PBBN access networks". Should
>> this instance also say PBBN?
> 
> Done.
> 
>> 
>> -- section 4.3:
>> 
>> 2nd paragraph says this scenario is applicable to "Loosely Coupled
>> Service Domains" and "Different Service Domains". The 4th paragraph
>> mentions "Tightly...". Does that mean the scenario also applies to
>> "Tightly Coupled Service Domains"? (i.e. should it be added to the 2nd
>> paragraph, or removed from the 4th?)
>> 
> 
> Removed "Tightly Š" from the 4th paragraph.
> 
> Cheers,
> Ali
> 

Gen-ART Telechat Review of draft-ietf-intarea-flow-label-balancing-02

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-intarea-flow-label-balancing-02
Reviewer: Ben Campbell
Review Date: 2013-10-08
IESG Telechat date: 2013-10-10

Summary: This version is ready for publication as an informational RFC. All of 
the comments from my previous last call review have been addressed either in 
this version or in email correspondence. 

Major issues: None

Minor issues: None

Nits/editorial comments: None

Gen-ART Telechat Review of draft-yusef-dispatch-ccmp-indication-06

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-yusef-dispatch-ccmp-indication-06
Reviewer: Ben Campbell
Review Date: 2013-10-08
IESG Telechat date: 2013-10-10

Summary: This draft is ready for publication as an informational RFC. This 
version addresses all the comments from my last call review of version 04. I do 
have a couple of new (or I missed the first time) editorial comments that might 
be worth addressing if there is a new version prior to approval.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- General:

idnits 2.12.18 reports some missing references--please check.

-- Abstract and Intro

Please expand UA and XCON on first mention (Both in Abstract and in Section 1).

Gen-ART LC Review of draft-ietf-intarea-flow-label-balancing-01

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-intarea-flow-label-balancing-01

Reviewer: Ben Campbell
Review Date: 2013-09-30
IETF LC End Date: 2013-09-30

Summary: This draft is essentially ready for publication as an informational 
RFC. I have some minor and editorial comments that may be worth considering 
prior to publication.

Major issues:

None.

Minor issues:

-- General: 

Is this draft intended only to apply to HTTP load balancers, or is it generic 
to any application protocol? I think you intend the 2nd, but there's quite a 
bit of HTTP specific text throughout. If that's correct, it might be helpful to 
explicitly mention it, or to make the HTTP specific parts more generic. (e.g. 
"application-layer proxy" vs "HTTP proxy".)

Nits/editorial comments:

-- general:

I personally find it easier to read and understand drafts that use the TCP/IP 
architecture layer names rather than OSI numbers. The names have more intrinsic 
meaning, and since we are talking about TCP/IP architecture stuff, that model 
seems to fit better.

-- section 1, 1st paragraph:

It might be helpful to actually define "load distribution" and/or "load 
balancing".

-- section 2, 1st paragraph:

I got a little confused by the reference locations. In particular, I expected 
the citation at the end of the first sentence to point to the flow label spec, 
not IPv6 in general. I think it would be more clear to add the 6437 reference 
immediately after the first occurrence of "IPv6 flow label", and remove  "... 
and it is defined in [RFC6437]" from the second sentence.

-- section 3, first bullet list item:

Is it worth mentioning SRV here?

-- section 3, 3rd bullet list item:

-- is "raw HTTP" the same as "plaintext HTTP"?

-- section 3, 4th bullet: 2nd sentence: 

Please expand ECMP. 

-- "According to the specific scenario, it will spread new sessions..."

I suggest "Depending on the specific scenario..."

The antecedent for "it" is slightly ambiguous.

The use of the term "spread" makes it sound like a given session might get 
spread across multiple destinations. Maybe something along the lines of "assign 
new sessions to specific destinations across..."

-- " 'Persistance' is defined as guaranteeing that..."

s/ guaranteeing/"the guarantee"

-- "... run to completion on a specific server"

Would it be more precise to say that all packets for a particular session are 
delivered to the same server?

-- section 3, bullet list nested in numbered list shortly before the diagram:

Please put blank lines between the list entries.

-- section 3, preamble to diagram:

What is a "maximum layout"?

-- section 3, last paragraph:

Can you elaborate on why usage by proxies is unlikely to be cost effective? I 
can guess why, but it would be better to say it explicitly rather than leaving 
the reader to draw the conclusion.

-- section 4, last item in bullet list:

You say that forwarding the flow label has no performance benefit. That may be 
true locally for the proxy, but if a load balancer exists between the proxy and 
the server, there may be an overall benefit.

-- section 4, first paragraph after bullet list:

You assert that logic for handling extension headers can be omitted. I assume 
you mean from the actual program flow for the specific case, not from the code 
altogether, right? You would still need that logic for the zero value flow 
label case, wouldn't you?

-- section 4, last paragraph, last sentence:

s/ "statistical assumption" / "assumption that label collisions will be 
statistically rare"

-- section 5, 2nd paragraph: "Specifically, the specification [ ] states..."

Is that an intentional Tom Swiftie? :-)

Re: Gen-ART LC Review of draft-ietf-karp-ops-model-07

[Ben Campbell]

Hi, thanks for the response. Comments inline. I've removed sections that do not 
appear to need further comment.

On Sep 17, 2013, at 1:29 PM, Sam Hartman  wrote:
> 
>genart> -- This abstract claims that this draft is a discussion of
>genart> issues. From that per spective, I don't think the use of
>genart> 2119 language is appropriate. There are some specific areas
>genart> (mentioned below) where 2119 language is used in imprecis
>genart> ways, and may do harm to the reader's understanding. There
>genart> are other uses that may be more reasonable. But I think the
>genart> draft would be better off dispensing with 2119 language
>genart> altogether.
> 
> We disagree.
> I think that the draft provides requirements that if followed will make
> management of the security aspects of routers easier to depend on.
> I believe 2119 language is useful in that.
> 

I think that would be true if the intent of this draft was to create a BCP, or 
something to that effect. That's not what the abstract and intro say. They 
characterize the draft as "discussing issues" and "begins to develop a model".

If you think 2119 language is appropriate, then it might be helpful to update 
the abstract and intro to make it more clear that the draft offers normative 
guidance, and make it clear when and to whom it applies. For example, section 3 
says "Implementations of this model MUST..." It's not clear to me what "this 
model" means when the abstract and intro make it sound like this draft is early 
work towards eventually developing such a model.

Bottom line is, I think the problem is not with 2119 language in general so 
much as it is a matter of the draft being inconsistent on whether it is 
discussing issues that may eventually lead to a model, or actually describing 
such a model.

> I think this is well within an area where there is no IETF-wide
> consessus and the judgment of the individual WGs and to a lesser extent
> editors should control.

Certainly. All I am doing is offering an opinion.

> 
>genart> -- Section 3, paragraph 4:
> 
>genart> This seems like a place where descriptive language would be
>genart> better than 2119 lan guage. In particular, "and so on"
>genart> leaves things too open ended and imprecise. Al so, the use
>genart> of 2119 language in an example seems a bit off.
> 
> So, the requirement is stated in the first clause using 2119 language:
> 
>   Operational Requirements: implementations of this model MUST support
>   configuration of keys at the most general scope for the underlying
>   protocol; 
> 
> The sentence goes on to apply that requirement to some common cases:
>   protocols supporting per-peer keys MUST permit
>   configuration of per-peer keys, protocols supporting per-interface
>   keys MUST support configuration of per-interface keys, and so on.
> 
> You might prefer different style rules; you might prefer  that the
> restatements of the general requirement to specific situations not use
> 2119 language.
> I think the right approach for that is to try and build community
> consensus on those style rules and not to apply those rules until such a
> consensus is achieved.
> I do agree that care should be used when using 2119 in a restatement,
> but in this instance believe it is OK.
> 
> I've removed the 2119 language from the example, although I think it was
> harmless.

Ok. 

My concern was that it is open ended. The words  "and so on" tells me that 
there may be more normative requirements that the reader is left to infer. That 
could make it hard to know if an implementation fully complies.

[snip]


> 
>genart> -- section 3.2, paragraph 2:
> 
>genart> What distinguishes SHOULD from "desirable" in this context?
>genart> That is, why use 211 9 language for one and not the other?
> 
> The sentences including desirable are giving motivation for the
> sentences including SHOULD.
> That is the SHOULDS are the take-aways, the desirables are
> expansions/explanations of why the SHOULDS make sense.

On re-reading that paragraph, I see your point and retract the comment.

> 
>genart> -- section 3.2, last paragraph: "Implementations SHOULD
>genart> permit a configuration i n which if no unexpired key is
>genart> available, existing security associations continu e using
>genart> the expired key with which they were established."
> 
>genart> This may need further guidance. For example, it seems risky
>genart> to do this silently.
> 
> I think this was explicitly discussed in the WG and is where we got in
> our discussions.
> There's discussion of alerts for security events elsewhere.
> However I think the current text represents a fairly informed WG
> consensus.

You are correct that there is separate text on notification of security events 
(section 6.2), and that even mentions certificate expiration. But it doesn't 
explicitly mention continuing to use an expired key. I think that's important 
enough that i

Re: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04

[Ben Campbell]

Hi Mary,

I similarly apologize for the delay in responding. It's been a busy week.

As I started to go over your responses one by one, I realized I had notated 
each one as WFM. So rather than send all that, I will summarize as "I agree 
with all of your responses, and updates to these effects will resolve all of my 
concerns."

Thanks!

Ben.

On Sep 16, 2013, at 2:59 PM, Mary Barnes  wrote:

> Hi Ben, 
> 
> I apologize for the delay in responding.  I had initially missed this review 
> - it either got cached directly with gen-art reviews or the tools alias 
> burped.  I'm not on the main IETF list with this email address.
> 
> Anyways, thank you very much for your thorough review.  Our responses are 
> below [MB].
> 
> We have an update underway that addresses your's and other's LC comments.  We 
> can forward that to you to preview if you would like.
> 
> Regards,
> Mary. 

[...]

Gen-ART LC Review of draft-ietf-l2vpn-pbb-vpls-interop-05

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-l2vpn-pbb-vpls-interop-05
Reviewer: Ben Campbell
Review Date: 2013-09-23
IETF LC End Date: 2013-09-24

Summary: Ready for publication as an informational RFC.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- Abstract:

Please expand H-VPLS on first mention

-- section 1, 1st paragraph:

Please expand VPLS on first mention.

-- section 4, 3rd to last paragraph: "Different PBB access networks..."

The previous and subsequent paragraphs say "PBBN access networks". Should this 
instance also say PBBN?

-- section 4.3:

2nd paragraph says this scenario is applicable to "Loosely Coupled Service 
Domains" and "Different Service Domains". The 4th paragraph mentions 
"Tightly...". Does that mean the scenario also applies to "Tightly Coupled 
Service Domains"? (i.e. should it be added to the 2nd paragraph, or removed 
from the 4th?)

Gen-ART LC Review of draft-kelsey-intarea-mesh-link-establishment-05

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-kelsey-intarea-mesh-link-establishment-05
Reviewer: Ben Campbell
Review Date: 2013-09-16
IETF LC End Date: 2013-09-16

Summary: This draft is almost ready to be published as a proposed standard. 
There are a few minor issues that should be considered prior to publication.

General: The draft is well written, and easier to read than many internet 
drafts.

Major issues:

none

Minor issues:

-- Applicability Statement

The applicability statement seems a bit lightweight.   I understand it is 
needed for some other IETF work; it might be nice to mention the specifics here 
(or in the introduction.) The assertion that this "extends 802.15.4" makes me 
wonder why this is an IETF effort rather than IEEE 802 effort--some IETF 
context would help.

-- section 5, 1st paragraph: "To avoid the cost and complexity of adding a 
second security suite, MLE reuses that of 802.15.4.  This document describes 
two security suites..."

The two sentences seem to contradict. Is this document describing security 
suites that are already in 802.15.4, or is it adding new ones?

-- section 7.8: Delay

Can you offer guidance on how to choose a delay value?

-- section 7.9,  paragraph starting with "Update messages SHOULD..."

What is the rational for SHOULDs instead of MUSTs? Can you offer guidance on 
when it might make sense to violate these? What might happen if one does?

-- section 8: "Outgoing link configuration and advertisement messages SHOULD be 
secured..."

Can you be more precise than "secured"? Does this mean "signed", "encrypted", 
or both? Also, what would be the consequences of violating the SHOULD?

-- section 8, paragraph 6: "... MUST be delayed by a random time between 0 and 
MAX_RESPONSE_DELAY_TIME seconds."

What's a reasonable resolution for that random time? I note that 
MAX_RESPONSE_DELAY_TIME is set to 1 second. I assume a random number between 
zero and one is not what you have in mind. :-)

-- section 8, paragraph 9: "Because MLE messages do not require complex 
processing and are not relayed, a simple timeout scheme is used for 
retransmitting."

You mention forwarding multiple hops two paragraphs back; do you mean something 
different here? There are other mentions of forwarding in the draft that makes 
me wonder about the assertion that messages "are not relayed".

-- section 8, last paragraph:

Can you offer guidance on an appropriate resolution for the random multiplier?

-- section 9, paragraph 3: "Unsecured incoming messages SHOULD be ignored."

Why not MUST? Also does this imply the requirement to secure messages in the 
first place should have been MUST?

-- section 9, paragraph 4: " A device SHOULD maintain a separate incoming MLE 
frame counter for each neighbor."

What happens if it doesn't?

-- Security Considerations:

I'd like to see a bit more on the consequences of accepting unsecured messages. 
The normative requirement says SHOULD NOT accept unprotected messages, instead 
of MUST NOT, so I assume that you contemplate that implementations may have 
reasons to accept unsecured messages. 

It's also worth some discussion of securing at the 802.15.4 layer vs at the MLE 
layer, since that's mentioned a few times in the draft


Nits/editorial comments:

-- section 4.1, 1st paragraph: " ... (addresses, node capabilities, frame 
counters)..."

Is that list exhaustive or exemplary? A "that is" or "for example" would help. 
Also, missing a conjunction before last element.

-- section 7.8, last line: "Values to be confirmed..."

Do you expect that to be removed prior to publication? If you think that IANA 
might not confirm the values, it might be better to use placeholders that refer 
back to the IANA Considerations section.  (Note that this occurs several times 
throughout the draft.)

Re: Gen-ART review of draft-ietf-dime-overload-reqs-11

[Ben Campbell]

Thanks, David!

On Aug 27, 2013, at 11:40 AM, "Black, David"  wrote:

> The -11 version of this draft addresses all of the nits and editorial comments
> noted in the Gen-ART review of the -10 version.  It's ready for publication as
> an Informational RFC.
> 
> Thanks,
> --David
> 
>> -Original Message-
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: Thursday, August 22, 2013 4:50 PM
>> To: Black, David
>> Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org;
>> d...@ietf.org; bcla...@cisco.com
>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
>> 
>> Hi David,
>> 
>> We agree on all your points, and will make the updates in the next version,
>> pending shepherd instructions.  
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> On Aug 22, 2013, at 2:50 PM, "Black, David"  wrote:
>> 
>>> Hi Eric,
>>> 
>>> This looks good - comments follow ...
>>> 
>>>>> a) I assume that overload control development work will derive more
>> specific
>>>>> security requirements - e.g., as REQ 27 is stated at a rather high level.
>>>>> The discussion in security considerations section seems reasonable.
>>>> 
>>>> We agree with this.  The thinking here was that we didn't want to specify 
>>>> this
>>>> in a way that would be specific to a particular type of mechanism.  It 
>>>> might
>>>> not hurt to state that assumption, either as a note on Req 27 or in the sec
>>>> considerations.
>>> 
>>> That would be good to add as a note on REQ 27.
>>> 
>>>> The intent was very much as you say, where requirements on individual node
>>>> capabilities are hoped to result in better overall system behaviors. There 
>>>> are
>>>> also some requirements that are stated more at the system level (e.g. 7 and
>>>> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
>>>> insufficient server capacity at a cluster of servers behind a Diameter 
>>>> agent
>>>> can be treated as if the agent itself was overloaded.
>>>> 
>>>> On the other hand, any mechanism we design will have to focus on actions of
>>>> individual nodes, so the numbered requirements tend to focus on that. I'm 
>>>> not
>>>> sure where to change the balance here--do you have specific suggestions?
>>> 
>>> I noted this as editorial rather than a minor issue, as I was mostly 
>>> concerned
>>> that the actual design work will be informed by a sufficient architectural 
>>> "clue"
>>> that the goal is "better overall system behaviors", which your response 
>>> indicates
>>> will definitely be the case ;-).
>>> 
>>> Rather than edit individual requirements, how about adding the following 
>>> sentence
>>> immediately following the introductory sentence in Section 7?:
>>> 
>>> These requirements are stated primarily in terms of individual node
>>> behavior to inform the design of the improved mechanism;
>>> that design effort should keep in mind that the overall goal is
>>> improved overall system behavior across all the nodes involved,
>>> not just improved behavior from specific individual nodes.
>>> 
>>>>> This inadequacy may, in turn, contribute to broader congestion collapse
>>>>> 
>>>>> "collapse" is not the right word here - I suggest "issues", "impacts",
>>>>> "effects" or "problems".
>>>> 
>>>> We are fine with any of those alternatives.  How about impacts.
>>> 
>>> That's fine.  FWIW, "congestion collapse" has a specific (rather severe)
>>> meaning over in the Transport Area, and that meaning was not intended here.
>>> 
>>>> 23.843 is the least stable reference.  I don't have any issue with pointing
>>>> that out.  The part of it we are referencing is historical front matter
>>>> though.
>>> 
>>> I'd note the reference as work in progress, and put the statement about 
>>> stable
>>> front matter (historical is a bad work to use here) in the body of the draft
>>> that cites the reference.
>>> 
>>>> I tried the web and downloaded versions of 2.12.17 and was not able to get 
>>>> the
>>&g

Re: Gen-ART review of draft-ietf-dime-overload-reqs-10

[Ben Campbell]

Hi David,

We agree on all your points, and will make the updates in the next version, 
pending shepherd instructions.

Thanks!

Ben.

On Aug 22, 2013, at 2:50 PM, "Black, David"  wrote:

> Hi Eric,
> 
> This looks good - comments follow ...
> 
>>> a) I assume that overload control development work will derive more specific
>>> security requirements - e.g., as REQ 27 is stated at a rather high level.
>>> The discussion in security considerations section seems reasonable.
>> 
>> We agree with this.  The thinking here was that we didn't want to specify 
>> this
>> in a way that would be specific to a particular type of mechanism.  It might
>> not hurt to state that assumption, either as a note on Req 27 or in the sec
>> considerations.
> 
> That would be good to add as a note on REQ 27.
> 
>> The intent was very much as you say, where requirements on individual node
>> capabilities are hoped to result in better overall system behaviors. There 
>> are
>> also some requirements that are stated more at the system level (e.g. 7 and
>> 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
>> insufficient server capacity at a cluster of servers behind a Diameter agent
>> can be treated as if the agent itself was overloaded.
>> 
>> On the other hand, any mechanism we design will have to focus on actions of
>> individual nodes, so the numbered requirements tend to focus on that. I'm not
>> sure where to change the balance here--do you have specific suggestions?
> 
> I noted this as editorial rather than a minor issue, as I was mostly concerned
> that the actual design work will be informed by a sufficient architectural 
> "clue"
> that the goal is "better overall system behaviors", which your response 
> indicates
> will definitely be the case ;-).
> 
> Rather than edit individual requirements, how about adding the following 
> sentence
> immediately following the introductory sentence in Section 7?:
> 
>   These requirements are stated primarily in terms of individual node
>   behavior to inform the design of the improved mechanism;
>   that design effort should keep in mind that the overall goal is
>   improved overall system behavior across all the nodes involved, 
>   not just improved behavior from specific individual nodes.
> 
>>> This inadequacy may, in turn, contribute to broader congestion collapse
>>> 
>>> "collapse" is not the right word here - I suggest "issues", "impacts",
>>> "effects" or "problems".
>> 
>> We are fine with any of those alternatives.  How about impacts.
> 
> That's fine.  FWIW, "congestion collapse" has a specific (rather severe)
> meaning over in the Transport Area, and that meaning was not intended here.
> 
>> 23.843 is the least stable reference.  I don't have any issue with pointing
>> that out.  The part of it we are referencing is historical front matter
>> though.
> 
> I'd note the reference as work in progress, and put the statement about stable
> front matter (historical is a bad work to use here) in the body of the draft
> that cites the reference.
> 
>> I tried the web and downloaded versions of 2.12.17 and was not able to get 
>> the
>> warnings you saw (about the references).  What did it say?
> 
> Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits 
> confusion
> manifested right at the top of the output, where everyone ignores it ...
> 
>   Attempted to download rfc272 state...
>   Failure fetching the file, proceeding without it.
> 
> You didn't reference RFC 272, so that output's apparently courtesy of idnits
> misinterpreting this reference:
> 
> 1195 [TS29.272]
> 11963GPP, "Evolved Packet System (EPS); Mobility Management
> 1197Entity (MME) and Serving GPRS Support Node (SGSN) related
> 1198interfaces based on Diameter protocol", TS 29.272 11.4.0,
> 1199September 2012.
> 
> I was amused :-).
> 
> Thanks,
> --David
> 
>> -Original Message-
>> From: Eric McMurry [mailto:emcmu...@computer.org]
>> Sent: Thursday, August 22, 2013 3:06 PM
>> To: Black, David
>> Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org);
>> ietf@ietf.org; d...@ietf.org; bcla...@cisco.com
>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
>> 
>> Hi David,
>> 
>> Thank you for the review.  Your time and comments are appreciated!
>> 
>> comments/questions inline.
>> 
>> 
>> Eric
>> 
>> 
>> 
>> On Aug 17, 2013, at 9:18 , "Black, David"  wrote:
>> 
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>> 
>>> .
>>> 
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>> 
>>> Document: draft-ietf-dime-overload-reqs-10
>>> Reviewer: David L. Black
>>> Review Date: August 17, 2013
>>> IETF LC End Date: August 16, 2013
>>> IESG Telechat date: (if known)
>>> 
>>> Summary:
>>> This draft

Gen-ART LC Review of draft-ietf-karp-ops-model-07

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-karp-ops-model-07.txt
Reviewer: Ben Campbell
Review Date: 2013-08-16
IETF LC End Date: 2013-08-18
IESG Telechat date: 

Summary: This draft is almost ready for publication as an informational RFC. I 
have a few clarity related comments that might be worth considering prior to 
publication.

Major issues:

None.


Minor issues:

-- This abstract claims that this draft is a discussion of issues. From that 
perspective, I don't think the use of 2119 language is appropriate. There are 
some specific areas (mentioned below) where 2119 language is used in imprecise 
ways, and may do harm to the reader's understanding. There are other uses that 
may be more reasonable. But I think the draft would be better off dispensing 
with 2119 language altogether.

-- Section 3, paragraph 4:

This seems like a place where descriptive language would be better than 2119 
language. In particular, "and so on" leaves things too open ended and 
imprecise. Also, the use of 2119 language in an example seems a bit off.

-- section 3.1, last paragraph:

I'm not sure what guidance is intended in this paragraph. It offers an example, 
then refutes it. Are there better examples to offer? Is the point that one 
shouldn't make such checks?

-- section 3.2, paragraph 2:

What distinguishes SHOULD from "desirable" in this context? That is, why use 
2119 language for one and not the other?

-- section 3.2, last paragraph: "Implementations SHOULD permit a configuration 
in which if no unexpired key is available, existing security associations 
continue using the expired key with which they were established."

This may need further guidance. For example, it seems risky to do this silently.

-- section 3.3, last paragraph: "... then there is complexity in key management 
protocols."

Can you elaborate? Too much complexity? Are there key management systems that 
are not complex?

-- section 4, 2nd to last paragraph:

Seems like other disadvantages are worth mentioning. For example, the potential 
impact of a compromised CA.

-- 4.1:

I understand why one might choose not to include a real-world example here, but 
is there something that can be referenced?

-- 4.4, 2nd paragraph: "... it will be critical to make sure that they are not 
required during routine operation or a cold-start of a network."

Can you elaborate on why?


Nits/editorial comments:

Abstract: Might be worth mentioning KARP and how this draft fits with others.

-- Section 1, paragraph 1: Please expand KARP on first mention.

-- Section 1, paragraph 3: Missing punctuation.

-- section 3: 
The text seems to rather abruptly start talking about key considered actions 
with little background. A quick summary of how these keys re used would be 
helpful.

-- section 3, paragraph 2: "Each OSPF link needs to use the same authentication 
configuration, ..."

Same configuration as what? The sentence appears to say keys must be the same 
among links but can be different.

-- section 3.2, first 2 paragraphs:

I'm not sure how a configuration management system and a configuration 
interface differ for the purposes of this discussion.

-- 4.1, paragraph 4: "Preshared keys that are used via automatic key management 
have not been specified for KARP."

I'm not sure what's intended here--if they are not specified why does the 
paragraph go on to talk about them?

-- 4.4, 1st paragraph: "... like RADIUS or directories."

Is there a word missing? 

-- 5, bullet list of management objects:

There may be management objects implied by the second and third bullets, but 
they are not mentioned as such. Can you explicitly state them? For example, in 
bullet 2 is the "peer" the object being discussed? Or is it the "name or key". 
In bullet 3, is "group" the managed object, rather than "routing protocol"?

-- 5, paragraphs 7 and 8:

s/what/which  (two occurrences)
 

Re: Gen-ART LC/Telechat Review of draft-ietf-jcardcal-jcard-04

[Ben Campbell]

Thanks for the response. A few comments inline. I removed sections that don't 
seem to need further comment.

On Jul 22, 2013, at 6:55 AM, Philipp Kewisch  wrote:

> 
> On 7/17/13 12:27 AM, Ben Campbell wrote:

[...]

>> -- 3.2.1.1:
>> 
>> What happens for future versions of vCard? Do you simply use the new version 
>> number, or would we need a new version of this spec? I suspect the latter. 
>> If true, it might be worth mentioning that, or somewhere early in the draft 
>> mention that this spec is for vCard 4.0 only.
>> 
> I'd love to hear from the WG here, but given vCard 5.0 can at least in theory 
> be completely different, I think the correct thing to do would be to restrict 
> this jCard document to 4.x and when 5.x comes around create a revision of the 
> document. Of course the text could be changed so that its "valid until 
> revised by another document", in case the changes in 5.x are minor enough 
> that no change in jCard is needed.
> 
> In any case, there should be a text change that any 4.x revision is allowed. 
> For example, I recently read a suggestion for signed vCards that might use a 
> version "4.0s".

Pending the opinions of the work group, I'm happy with that approach.

>> -- sections 3.4.3 and 3.4.4:
>> 
>> Is the included ABNF a quotation of that in the referenced RFCs, or is it 
>> new and authoritative? If the former, it would be helpful to mention that in 
>> the text. (I note you did say that about the ABNF in the appendix).
>> 
> The ISO specs don't provide a direct BNF for any of their constructs. Instead 
> they show examples in the form:
> Basic format: MMDD Example: 19850412
> Extended format: -MM-DD Example: 1985-04-12
> 
> The ABNF in jCard mimics this format, so it is not new, but given it matches 
> I guess we could say its authoritative. Unless someone tells me otherwise 
> (I'm still a bit uncertain when something can be called authoritative), I'll 
> change it by changing the hangText "ABNF Schema:" to "ABNF Schema 
> (authoritative):" in both sections.

By "authoritative", I don't mean anything particularly formal. It's really a 
matter of where the normative text lies. So, for someone implementing _this_ 
draft, would you expect them to look at the included ABNF only, or is it a case 
of the ABNF being here for convenience but a careful implementor should  also 
look at the ISO specs?


> 
>> -- 3.4.11:
>> 
>> If RFC6350 says that use of the timezone offset is NOT RECOMMENDED, can you 
>> elaborate on why it's included here? (I can guess it's because people may 
>> still use it in vCards since it was a "MUST NOT", but it would be good to 
>> say something to that effect in the text.)

oops, I think I meant to say "SHOULD NOT".

>> 
> There is no other vCard property that uses a utc-offset as a type, so this is 
> just for the sake of an example. RFC6350 Section 6.5.1 has the details, it 
> says utc-offset SHOULD NOT be used on a TZ property. The alternative would be 
> to use an x-property for the example, i.e
> 
> ["x-clock-offset", {}, "utc-offset", "-05:00"]
> 
> Do you think we should use this instead?

I don't have strong feelings either way, other than if you include a "NOT 
RECOMMENDED" example, it might be wise to put in a sentence or two giving the 
reasoning.

> 
>> 
>> Nits/editorial comments:
>> 
>> -- Section 1, paragraph 1:
>> 
>> Please expand JSON on first mention.
>> 
> Doing this in the introduction since you reference Section 1, paragraph 1. It 
> already appears in the abstract, should I expand it there instead/in addition?

I think the general approach is that the abstract doesn't "count" for this 
purpose. That is, if you separated the abstract and the body into two different 
documents, they should both still make sense.

> 
> As the first mention uses "JSON-based", I've reworded these two paragraphs:
> 
> OLD:
>As certain similarities exist between vCard and the iCalendar data
>format [RFC5545], there is also an effort to define a JSON-based data
>format for calendar information called jCal [I-D.ietf-jcardcal-jcal]
>that parallels the format defined in this specification.
>   
>The purpose of this specification is to define "jCard", a JSON format
>for vCard data.  One main advantage to using a JSON-based format as
>defined in [RFC4627] over the classic vCard format is easier
>processing for JavaScript based widgets and libraries, especially in
>the scope of web-based app

Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-yusef-dispatch-ccmp-indication-04
Reviewer: Ben Campbell  
Review Date: 2013-07-16
IETF LC End Date: 2013-07-16

Summary: This draft is almost ready for publication as a proposed standard, but 
I think there are some clarifications needed first.

Major issues:

-- None

Minor issues:

-- Abstract:

Is the abstract current? It says you will discuss pros and cons of a few 
options, and recommend two. I guess you did recommend two, but the others have 
been relegated to the appendix. There are no pros and cons listed for the two 
recommended choices, which seems rather odd. 

It also mentions that these are mechanisms to be used by SIP clients. That's 
not repeated in the introduction. Is this entire draft intended exclusively for 
SIP clients?

-- 2.

It would be helpful to give more guidance on when one would use one method over 
the other. 2.1 mentions that it might be an "easier way for a UA that is not 
interested in the URI". I'm not sure what it means for a UA to be interested or 
not interested in a URI--maybe you mean "A UA that does not otherwise need to 
parse the URI"?

-- 2.1: 

I assume this section is intended to be SIP specific. It would help to say that 
somewhere, and include a 3261 citation for Call-Info. There are hints that the 
entire draft is SIP specific in the abstract, but that doesn't get repeated 
elsewhere. (In fact, the only non-abstract citation to 3261 is in the IANA 
considerations.)

Also, the section seems underspecified. It says the ccmp value can go in any 
INVITE, INVITE response, or OPTIONS response. It would help to describe how UAs 
would actually use it. Simply naming the actors would help; as it is, they are 
obscured by the passive voice in "... can be used...", and the reader is left 
to infer the intent based on his knowledge of SIP.

--2.2:

I assume this section is _not_ necessarily SIP specific. If that's the intent, 
it would be helpful to say so.

-- Appendices:

There's more detail and discussion around the discarded methods than the 
recommended ones in sections 2.X. It would be helpful to have those sections 
have at least this much explanation.

-- section 3:

You say this draft introduces no additional security considerations. Statements 
like that turn out false more often than not. For example, is there no security 
consideration created by having a SIP UA identify itself as a conference focus 
in an INVITE? (Even if the answer is no, it's helpful to have text along the 
line of "we thought about this and decided it was not a consideration due 
"

Further, you say "... beyond those applicable to the mechanisms described 
within". The mechanisms in sections 2.X are "described within". I assume those 
aren't the ones you mean here.


Nits/editorial comments:

-- Abstract:

The abstract should not contain citations. It will be published in multiple 
places without the rest of the document, orphaning the citations.

Gen-ART LC/Telechat Review of draft-ietf-jcardcal-jcard-04

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-jcardcal-jcard-04
Reviewer:  Ben Campbell
Review Date:  2013-07-16
IETF LC End Date: 2013-07-18
IESG Telechat date: 2013-07-18

Note: This draft is on the IESG Telechat agenda on the same date as it 
completes IETF Last Call. Therefore, this review serves both purposes.

Summary: This draft is almost ready for publication as a proposed standard. 
There are a few minor issues and editorial nits that should be considered prior 
to publication.

Major issues:

-- None

Minor issues:

-- Section 1, design considerations:

You mention that the semantic results should survive round-tripping, but the 
order of fields might not. I gather there are other changes that might occur 
from the literal text, right? (e.g. Case changes, some optional parameter 
usage). If so, it might be worth clarifying that.

-- 3.1, 2nd paragraph:

I assume the removal of escaping means that one renders the escaped text, not 
simply removes it, right? Is that as simple as removing the escape characters 
in vCards? I assume this doesn't apply to any content-specific escaping inside 
vCard fields, e.g. URI escaping, right? If so, it might be worth mentioning.

-- 3.2.1.1:

What happens for future versions of vCard? Do you simply use the new version 
number, or would we need a new version of this spec? I suspect the latter. If 
true, it might be worth mentioning that, or somewhere early in the draft 
mention that this spec is for vCard 4.0 only.

-- sections 3.4.3 and 3.4.4:

Is the included ABNF a quotation of that in the referenced RFCs, or is it new 
and authoritative? If the former, it would be helpful to mention that in the 
text. (I note you did say that about the ABNF in the appendix).

-- 3.4.11:

If RFC6350 says that use of the timezone offset is NOT RECOMMENDED, can you 
elaborate on why it's included here? (I can guess it's because people may still 
use it in vCards since it was a "MUST NOT", but it would be good to say 
something to that effect in the text.)

Nits/editorial comments:

-- Section 1, paragraph 1:

Please expand JSON on first mention.

-- Section 1, paragraph 3:

This paragraph seems redundant to paragraph 1.

-- 1, paragraph 7: " Preserve the semantics of the vCard data."

Imperative form sentence is confusing in context, and inconsistent with 
surrounding text.

-- 1, paragraph 8:

Sentence Fragment.

-- 3.2, Last Paragraph: "... for a parser check the data type..."

Missing "to"?

-- 3.2.1.2, last paragraph before example:

Should the "iCalendar" reference be "vCard" instead?

-- 3.2.1.3, Last Paragraph:

RFCTODO? I gather in the IANA section, that may be a placeholder for "this 
RFC", but that doesn't seem to fit here.

-- 3.3.2: "Example 1:"

Other examples are not numbered.

-- 5:

More occurrences of RFCTODO

Re: Gen-ART Telechat Review of draft-thornburgh-adobe-rtmfp-09

[Ben Campbell]

Thanks Michael, that note would completely resolve my concern, and change my 
review summary to "ready for publication".

Ben.

On Jul 9, 2013, at 5:03 PM, Michael Thornburgh  wrote:

> hi Ben.
> 
> your "like to see" is entirely reasonable, and the following text will be in 
> the next revision once my AD or Document Shepherd directs me to post it:
> 
>   Note to implementers: at the time of writing, the Cryptography
>   Profile used by the above mentioned Adobe products is not publicly
>   described by Adobe.  Implementers should investigate the availability
>   of documentation of that Cryptography Profile prior to implementing
>   RTMFP for the purpose of interoperation with the above mentioned
>   Adobe products.
> 
> thank you.
> 
> -michael thornburgh
> 
> 
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: Tuesday, July 09, 2013 12:59 PM
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on 
>> Gen-ART, please see the FAQ at <
>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please wait for direction from your document shepherd or AD before posting a 
>> new version of the draft.
>> 
>> Document: draft-thornburgh-adobe-rtmfp-09
>> Reviewer: Ben Campbell
>> Review Date: 2013-07-09
>> IESG Telechat date: 2013-07-11
>> 
>> Summary: This draft is essentially ready for publication as an informational 
>> RFC. There is one issue
>> from my previous review and related discussion that I think is almost, but 
>> not completely handled. All
>> other concerns from my previous review have been addressed in this version.
>> 
>> Major issues:
>> 
>> There has been a fair amount of discussion about how this protocol requires 
>> a crypto profile to
>> interoperate, and no such profiles are included, or otherwise widely 
>> published. If this were a
>> standards track draft, I would argue for at least one mandatory-to-implement 
>> profile to be included or
>> referenced. But since this is intended as an informational RFC that simply 
>> describes what certain
>> products are doing, that's probably okay.  Furthermore, the author added a 
>> paragraph to the
>> introduction specifically calling out the issue, which I applaud.
>> 
>> But I'd like to see that paragraph go a bit further, and explicitly mention 
>> any such profile needed to
>> interoperate with the commercial products mentioned in the 2nd paragraph of 
>> section 1 has not been
>> made available at the time of RFC publication, and that implementors should 
>> investigate the
>> availability of such a profile prior to implementing this protocol for the 
>> purposes of interoperating
>> with those products.
>> 
>> Minor issues:
>> 
>> None.
>> 
>> Nits/editorial comments:
>> 
>> None.

Gen-ART Telechat Review of draft-thornburgh-adobe-rtmfp-09

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at < 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 
Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.
 
Document: draft-thornburgh-adobe-rtmfp-09
Reviewer: Ben Campbell
Review Date: 2013-07-09
IESG Telechat date: 2013-07-11
 
Summary: This draft is essentially ready for publication as an informational 
RFC. There is one issue from my previous review and related discussion that I 
think is almost, but not completely handled. All other concerns from my 
previous review have been addressed in this version.
 
Major issues:
 
There has been a fair amount of discussion about how this protocol requires a 
crypto profile to interoperate, and no such profiles are included, or otherwise 
widely published. If this were a standards track draft, I would argue for at 
least one mandatory-to-implement profile to be included or referenced. But 
since this is intended as an informational RFC that simply describes what 
certain products are doing, that's probably okay.  Furthermore, the author 
added a paragraph to the introduction specifically calling out the issue, which 
I applaud. 

But I'd like to see that paragraph go a bit further, and explicitly mention any 
such profile needed to interoperate with the commercial products mentioned in 
the 2nd paragraph of section 1 has not been made available at the time of RFC 
publication, and that implementors should investigate the availability of such 
a profile prior to implementing this protocol for the purposes of 
interoperating with those products.

Minor issues:

None.

Nits/editorial comments:

None.

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

Hi Michael,

Thanks for the continued responses. A few more comments inline. I deleted 
sections that did not seem to need further comment. In summary, all of my 
concerns are resolved except for the crypto profile question.

Thanks!

Ben.

On Jun 26, 2013, at 2:00 PM, Michael Thornburgh  wrote:

[...]

>>> with regard to comments in later messages in this thread, i'd be happy to 
>>> include some (IESG-
>> supplied) boilerplate in the document to clarify that it is not the product 
>> of an IETF WG.  however,
>> note that both the title and first sentence of the Introduction indicate 
>> that this is "Adobe's
>> blahblahblah", consistent with other vendor-protocol RFCs and consistent 
>> with IESG editorial
>> insistence (as told to me by a former TSV AD).  see RFC 4332 and RFC 6802 
>> for two examples of vendor-
>> specific/supplied protocols.  see also the IESG note in RFC 4332 as an 
>> example disclaimer that could
>> be added.
>> 
>> Some additional text (whether IESG boilerplate or otherwise) that clarifies 
>> the purpose of the draft
>> would help a lot.
> 
> the sponsoring AD has proposed an additional statement that will be inserted 
> by the RFC Editor on publication.  note that draft -08 has additional 
> clarification that this is an Adobe protocol and is not the product of an 
> IETF activity.

The additional statement in 08 resolves my concern in the context of this 
specific document. (I have mixed feelings about the idea of documenting 
proprietary protocols in IETF stream drafts at all, but it's not reasonable to 
hold any particular draft hostage over a larger policy question.)

>> At the time of writing yes. My concern is how a future implementor can be 
>> confident that this doc
>> describes RTMFP as used by Adobe at points in the future. When you say this 
>> is the authoritative
>> specification, does that mean that Adobe does not plan to modify the 
>> protocol without timely
>> publication of an update to this document?
> 
> this is a problem for *any* published protocol.
>  RTMFP (as documented in this memo) hasn't changed substantially in many 
> years.  i have every expectation that, should a change be made to the 
> protocol, we would publish an updated specification.
> 

(Let me preface this comment: This is also an issue with the general idea of 
publishing proprietary protocols in IETF stream documents. I'm not picking on 
this draft in particular, and we can consider this issue closed for the 
purposes of my Gen-ART review.)

I disagree that this is an issue for any published protocol. In the case of an 
IETF produced protocol, an RFC is the definitive specification. If the IETF 
chooses to revise the protocol in the future, it does so by publishing a new 
RFC that updates or obsoletes the original. 

You indicate Adobe plans to do the same, and that this protocol is pretty 
stable. You mentioned previously that this document would be the authoritative 
specification. So, then maybe there's not an issue.  But if Adobe maintains 
internal documentation that an Adobe engineer would consult to understand and 
implement the protocol, and you revise that documentation internally, it's 
going to be pretty tricky keeping the IETF -published specification in sync.



>>> 
>>> yes, endpoints need a common cryptography profile to interoperate.  there 
>>> is no repository for
>> crypto profile documentation at this time. currently, there is one defined 
>> cryptography profile (the
>> one used for Flash communication) that is not publicly documented, because i 
>> do not yet have
>> permission to publish it.  i (meaning me personally) hope that a memo 
>> documenting the
>> crypto/application profile for Flash communication (as being a widely 
>> deployed and used profile for
>> RTMFP) would also be published someday as an I-D and hopefully an 
>> Informational RFC.
>> 
>> I understand the issue about permission to publish, but does this document 
>> serve its purpose until you
>> are ready to publish the crypto profile? Ideally they would be published 
>> together and this document
>> would reference that one. Do I infer correctly that there is no way someone 
>> could create an
>> implementation that interops with Adobe products based on the documents 
>> available at this time?
> 
> additional documentation is needed to interoperate (at the application layer) 
> with the Adobe products that implement RTMFP. i hope that the successful 
> publication of this memo will help me in getting the necessary approval to 
> publish the higher layer details of Adobe's RTMFP ecosystem.
> 
> the situation is analogous to having published TCP, but there's a lot more 
> you need to know to talk to a web server with HTTPS (like TLS and HTTP).  
> it's still useful to know how TCP works, and plenty more to do with it than 
> talk to web servers.

I don't think that's a fair analogy. I can use TCP for many purposes other than 
talking to web servers. It can even be useful all itself. But if I und

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

Thanks for the response! Comments inline:

Thanks!

Ben.


On Jun 21, 2013, at 4:35 PM, Michael Thornburgh  wrote:

> hi Ben. thanks for your review. comments/replies inline.
> 
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: Thursday, June 20, 2013 4:07 PM
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document:  draft-thornburgh-adobe-rtmfp-07
>> Reviewer: Ben Campbell
>> Review Date:  2013-06-20
>> IETF LC End Date: 2013-06-25
>> 
>> Summary: This draft is almost ready for publication as an informational RFC. 
>> However, I have some
>> concerns about the purpose and intended status of the document that I think 
>> should be considered prior
>> to publication.
>> 
>> 
>> Note: This is an informational draft that describes what I understand to be 
>> an existing protocol as
>> implemented by commercial products. Therefore, this review does not attempt 
>> to evaluate the protocol
>> itself. I assume the protocol is what it is, and it is not up to the IETF to 
>> agree or disagree with
>> it.
>> 
>> *** Major issues:
>> 
>> -- Why does this need to be published as an IETF stream RFC?  If I 
>> understand correctly, this
>> documents an existing protocol as implemented by commercial products. I 
>> agree with Martin's comment
>> that there is value in publishing this sort of thing, but I applaud the 
>> Adobe and the author for
>> publishing it so other implementations can interoperate with their products. 
>> But that could have done
>> that in an independent stream document, or even in an Adobe published 
>> document. (Perhaps even in a
>> prettier format ;-)  )  If we publish this as an IETF stream document, then 
>> I think it needs stronger
>> clarification that it is not an IETF consensus doc than just its 
>> informational status.
> 
> this memo documents an existing network transport protocol that is widely 
> deployed and in widespread use in the Internet.  we felt that the IETF 
> community (and in particular the participants in the Transport and Services 
> Area) is the most appropriate community with which to share this work: 1) 
> members of this community have the necessary and relevant expertise not only 
> to understand the protocol, but to make use of it potentially in new 
> applications beyond Flash; 2) it is a transport protocol similar in many ways 
> to TCP and SCTP and widely deployed and used; 3) Adobe is interested in 
> pursuing standardization of this protocol (with all that entails) if there is 
> community interest, and the IETF is definitely the right place for that.
> 
> we are very grateful that Martin Stiemerling chose to sponsor this document.
> 
> with regard to comments in later messages in this thread, i'd be happy to 
> include some (IESG-supplied) boilerplate in the document to clarify that it 
> is not the product of an IETF WG.  however, note that both the title and 
> first sentence of the Introduction indicate that this is "Adobe's 
> blahblahblah", consistent with other vendor-protocol RFCs and consistent with 
> IESG editorial insistence (as told to me by a former TSV AD).  see RFC 4332 
> and RFC 6802 for two examples of vendor-specific/supplied protocols.  see 
> also the IESG note in RFC 4332 as an example disclaimer that could be added.

Some additional text (whether IESG boilerplate or otherwise) that clarifies the 
purpose of the draft would help a lot.


> 
>> Along those lines:
>> 
>>  -- Is this document the authoritative specification? (I suspect not.) 
>> Who owns change control? I
>> assume that to be Adobe and/or the authors. What expectation do readers of 
>> this draft have that it
>> represents the current version of RTMFP at any point in time?
> 
> this memo is the authoritative specification for Adobe's RTMFP.  Adobe owns 
> change control.  i believe the second and third paragraphs of the 
> Introduction indicate to a reader that this draft represents RTMFP as 
> deployed in the named Adobe products at the time of writing.

At the time of writing yes. My concern is how a future implementor can be 
confident that this doc describes RTMFP as used by Adobe at points in the 
future. When you say this is the authoritative specification, does that mean 
that Adobe does not plan to modify the protocol without timely publication of 
an update to this document?

> 

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

On Jun 20, 2013, at 10:12 PM, John C Klensin  wrote:

> p.s. I started a much more detailed response to Ben, but I think
> the essence of it is above.  IMO, a discussion that amounts to
> whether or not an AD used bad judgment by choosing to sponsor an
> individual Informational submission (or whether ADs should have
> that power at all) should not become part of evaluating a
> particular document's appropriateness.

I certainly didn't mean this to be a discussion of AD judgement. I suspect this 
would not be the first time the IETF has published an informational RFC that 
describes a non-IETF protocol, so there's probably precedent for doing so. It 
might be worth discussing whether that's a good precedent.

I also recognize that the authors have done a _lot_ of work on this draft, so 
this entire discussion is probably a bit unfair to them. I actually do hope it 
gets published somewhere.

Thanks!

Ben.

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

On Jun 20, 2013, at 9:14 PM, Barry Leiba  wrote:

> -- Why does this need to be published as an IETF stream RFC?  If I understand 
> correctly, this documents an existing protocol as implemented by commercial 
> products. I agree with Martin's comment that there is value in publishing 
> this sort of thing, but I applaud the Adobe and the author for publishing it 
> so other implementations can interoperate with their products. But that could 
> have done that in an independent stream document, or even in an Adobe 
> published document. (Perhaps even in a prettier format ;-)  )  If we publish 
> this as an IETF stream document, then I think it needs stronger clarification 
> that it is not an IETF consensus doc than just its informational status.
> 
>  FWIW, the IESG has discussed this in the context of other documents, and is 
> looking at boilerplate that does not say that the document is a "product of 
> the IETF", and makes it clear that the content is not a matter of IETF 
> consensus.  If that sort of boilerplate was used, do you think that would be 
> sufficient?
> 

I think that would help, depending on the specific language. My concerns about 
change control, authoritative specs, etc might still apply depending on the 
boilerplate details.

Thanks!

Ben.

Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-thornburgh-adobe-rtmfp-07
Reviewer: Ben Campbell
Review Date:  2013-06-20
IETF LC End Date: 2013-06-25

Summary: This draft is almost ready for publication as an informational RFC. 
However, I have some concerns about the purpose and intended status of the 
document that I think should be considered prior to publication.


Note: This is an informational draft that describes what I understand to be an 
existing protocol as implemented by commercial products. Therefore, this review 
does not attempt to evaluate the protocol itself. I assume the protocol is what 
it is, and it is not up to the IETF to agree or disagree with it.

*** Major issues:

-- Why does this need to be published as an IETF stream RFC?  If I understand 
correctly, this documents an existing protocol as implemented by commercial 
products. I agree with Martin's comment that there is value in publishing this 
sort of thing, but I applaud the Adobe and the author for publishing it so 
other implementations can interoperate with their products. But that could have 
done that in an independent stream document, or even in an Adobe published 
document. (Perhaps even in a prettier format ;-)  )  If we publish this as an 
IETF stream document, then I think it needs stronger clarification that it is 
not an IETF consensus doc than just its informational status.

Along those lines:

-- Is this document the authoritative specification? (I suspect not.) 
Who owns change control? I assume that to be Adobe and/or the authors. What 
expectation do readers of this draft have that it represents the current 
version of RTMFP at any point in time?

-- Under what circumstances would one desire to implement this? I can 
infer that from the introduction, but it would be nice to see some sort of 
applicability statement making it explicitly clear that this is not an IETF 
protocol, and that one would implement it in order to interoperate with certain 
Adobe products. I know that some of this may be implied by the fact that this 
is informational rather than standards track. But I don't expect readers who 
are not IETF insiders to understand that subtlety without some explicit words 
to that effect. In particular, it would be good to clarify the difference 
between this and the many "not quite accepted as standards track by some 
working group" nature of a number of our informational RFCs that describe 
protocols.

That all being said, this is overall a well written document. The rest of my 
comments are mostly pedantic nits.

*** Minor issues:

-- section 1.2: 

I find the use of "MUST ONLY" confusing. I gather it means "you are _allowed_ 
to do X only under certain conditions" rather than "you are _required_ to do X 
under certain conditions." If correct, I think the words "MAY ONLY" would be 
more clear. If not, then I think the construct would be better handled using 
existing 2119 language.

-- section 3.2:

Do I understand correctly that all endpoints are expected to be able to present 
certificates? Do you find that common in the field? I realize the nature of the 
certs will depend on the security profiles.

-- sections 3.2 and 5

Do I assume correctly that endpoints need a common crypto profile to 
communicate? Is there a repository where one might find crypto profile 
documentation? Is there a commonly implemented one to which this draft could 
refer?

-- section 3.2: "Multiple endpoints SHOULD NOT have the same identity."

Why not MUST? Will things not break if two endpoints do have the same identity?

-- "Authenticity MAY comprise verifying an issuer signature chain in a public 
key infrastructure"

Is that really normative, or just an observation of fact?

-- " Canonical Endpoint Discriminators for distinct identities SHOULD be 
distinct."

What if they are not? Do things break? It might be worth making this a MUST, or 
adding some additional guidance about what might happen if the SHOULD is 
violated.

-- "A comparison function MAY comprise performing a lexicographic ordering..."

Is that really normative, or just an example of something one might do?

-- "A test SHOULD comprise testing whether the certificates are identical."

What if it doesn't? Also, what constitutes "identical"? All fields match 
values? Bitwise match?  Is it simply including the same identity or identities? 
Maybe an identity function provided by the crypto profile?

-- 3.5, last paragraph:

Can you offer guidance on reasonable buffer size and number ranges?

-- 3.5.1.1.1, 3rd paragraph:

What are the consequences of having a tag with less than 8 bytes of leng

Gen-ART Telechat Review of draft-ietf-forces-interop-08

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-forces-interop-08
Reviewer: Ben Campbell
Review Date: 2013-05-29
IETF LC End Date: 2013-05-30
IESG Telechat date: (if known)

Summary: This draft is mostly ready for publication as an informational RFC. 
All of the substantive comments from my earlier review have been addressed.  
Some editorial issues remain. These are of the sort that the RFC editor can 
probably fix, but if there are further iterations of the draft prior to 
approval it might be worth addressing them.

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

-- I previously mentioned that the draft used inconsistent verb tenses to the 
point of being confusing. The authors improved this by changing occurances most 
to past tense. However, there were some places where the change was incorrect ( 
section 1 paragraph 1: "This document captures" was changed to "... 
captured".). Also in at least one section (3.3), the previously past tense 
verbs were changed to future tense.

-- There are a lot of missing articles, especially in text that is new to this 
version.

-- section 1, new paragraph 5: Up to date, the 'ForCES..."

I suggest changing "Up to date..." to "As of now..." or "As of the time of this 
writing...". Or even better, remove it completely.

Re: Gen-ART LC Review of draft-ietf-forces-interop-07

[Ben Campbell]

Thanks for the response. Comments inline. I removed sections for which I have 
no further comment.

Thanks!

Ben.

On May 16, 2013, at 10:19 PM, "Wang,Weiming"  wrote:
> 

[...]

> -- The draft mentions a couple of instances of tests that failed because of 
> an incorrect implementation or differing encapsulation formats. Does this 
> suggest that the specifications should be clarified? In particular, in the 
> case of encapsulation format mismatch, should the specs include stronger 
> requirements to be able to receive all encapsulation formats? Or should the 
> number of options be reduced?
> [Re. by ΕΗ] The protocol provides a number of different approaches 
> [Re. by Weiming] The key issue is still from the deep understanding of the 
> protocol from implementations. I still have not seen need for any urgent 
> change for the protocol. 

I don't have enough knowledge of the protocol to form a specific opinion, but 
it's been my experience in other areas that when implementors interpret things 
differently, there's often room for clarification, even if the text is formally 
correct. I agree it doesn't imply an urgent need, but would it be worth one or 
more errata?

[...]


> -- section 4.4, last paragraph:
> 
> The text says that since the mentioned failures were likely the result of 
> bugs, it doesn't indicate an interoperability problem in the specs. I have to 
> point out that, it also doesn't prove interoperability in both directions for 
> the particular test. It would also be worth commenting on whether the 
> probably bugs were programming errors rather than misunderstandings of the 
> specification.
> [Re. by Weiming] to change the whole paragraph to:
>   The two test items failed. Note that Test #7 and #8 were identical to 
> the tests, only with CE and FE implementers were exchanged. Moreover, test 
> #12 and #13 showed that the redirect channel worked well. Therefore, it can 
> be reasonably inferred that the problem caused the failure was from the 
> implementations, rather than from the ForCES protocol itself or from 
> misunderstanding of implementations on the protocol specification. Although 
> the failure made the OSPF interoperability test incomplete, it did not show 
> interoperability problem. More test work is needed to verify the OSPF 
> interoperability.

Works for me, thanks!

[...]


[Re. by Weiming] The section 3.2 para.3 has been changed to: 
> ... Because there came unfortunately a problem with the test system in 
> Greece to deploy IPSec over TML during the test process, this test only took 
> place between test systems in China and Japan.

The sentence is still hard to parse. Do you mean the following?

"Because an unfortunate problem with the test system in Greece prevented the 
deployment of IPSec over TML, this test only took place between the test 
systems in China and Japan."

[...]

Gen-ART LC Review of draft-ietf-forces-interop-07

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-forces-interop-07
Reviewer: Ben Campbell
Review Date: 2013-05-13
IETF LC End Date: 2013-05-13
IESG Telechat date: 

Summary: This draft is almost ready for publication as an informational RFC. I 
have a few minor questions and editorial comments that may be worth considering 
prior to publication.

*** Major issues:

None.

*** Minor issues:

-- The draft mentions a couple of instances of tests that failed because of an 
incorrect implementation or differing encapsulation formats. Does this suggest 
that the specifications should be clarified? In particular, in the case of 
encapsulation format mismatch, should the specs include stronger requirements 
to be able to receive all encapsulation formats? Or should the number of 
options be reduced?

-- I have a mild concern that the use of origin country names for each 
implementation could confuse readers into thinking that the countries 
themselves officially participated, rather than organizations from each country.


-- section 4.4, last paragraph:

The text says that since the mentioned failures were likely the result of bugs, 
it doesn't indicate an interoperability problem in the specs. I have to point 
out that, it also doesn't prove interoperability in both directions for the 
particular test. It would also be worth commenting on whether the probably bugs 
were programming errors rather than misunderstandings of the specification.


*** Nits/editorial comments:

-- The draft uses inconsistent verb tense throughout. I found this a bit 
confusing, as I assume the draft talks entirely about tests that have already 
occurred.

-- IDNits points out that you have several references without explicit 
citations. I see that you called the references out by name in the text, but it 
would be better to include the citations.

-- Section 1, paragraph 6:

Please expand abbreviations on first mention.

-- Section 1.1:

Please expand FE on first mention.

-- section 2.2.2, paragraph 1: "... from China and Japan implementations..."

Missing "the".

Is it possible to add a reference for details on the Smartbits testing machine?

-- Figure 2:

Do you really want to publish the IP addresses used in an RFC? RFCs live 
forever...

-- Section 2.2.2, paragraph after figure 2: 

First sentence does not parse.


-- Figure 3:

The figure has some formatting issues, at least in the PDF version. Also, is it 
possible to avoid splitting the figure across the page break?

-- section 3.2, paragraph 3: "Because of system deficiency to deploy IPSec over 
TML in Greece,..."

Phrase doesn't parse.

-- section 3.2, paragraph 4: "... over IPSec channel."

Missing "the".

"...to have established..."

to establish.

-- section 4 and subsections:

It seems like some of the test descriptions in 4.X may be redundant to the 
previous scenario descriptions.

-- section 4.1, notes on 28 and 29:

Sentence does not parse.

... notes on 30 and 31:

Missing articles.

-- section 5.1, last paragraph in list item "2.": "The interoperability test 
witnessed that..."

The test _showed_...   [or the _testers_ witnessed...]

-- section 9:

It would be worth mentioning that you explicitly tested for IPSec support.


 

Re: Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

[Ben Campbell]

Hi, deleting sections that seem resolved:

On Apr 25, 2013, at 8:12 PM, Fernando Gont  wrote:

[...]

> 
> 
 -- 1, paragraph 11: "This document does not update..."
 
 How is adding an alternative algorithm _not_ an update?
>>> 
>>> Well, you still send an RS, receive an RA, and generate an IID.
>>> 
>>> Me, I'd probably update RFC 4862, so that we make sure that folks 
>>> implementing SLAAC take a look at this document, but
>> 
>> ...?
>> 
>> (The reason you mention is one of the best reasons I can think of to 
>> call it an update--but if the working group consciously chose not to 
>> make it an update, I can live with it.)
> 
> I'm not sure whether this was "consciously chosen" -- I will check with
> a few folks about their thoughts (for the most part, I wouldn't want to
> trigger a controversy just because of this).
> 
> 

Point taken.

[...]

> 
> 
 -- references: RFC1948 is obsoleted by 6528. Is there a reason to
 reference the obsolete version?
>>> 
>>> Yes: RFC1948 is only referenced in the Acks section, where I note 
>>> that this document was inspired by Bellovin's work on RFC1948. 
>>> While RFC6528 obsoletes RFC1948, the algorithm in that RFC is the 
>>> same as that in RFC1948.
>> 
>> So 6528 equally illustrates Steve Bellovin's  work, and is also more 
>> current, right? 
> 
> Yes. But I'm a co-author of RFC 6528 -- so it'd be a bit arrogant (and
> incorrect) to say that I was inspired by RFC 6528 :-) -- I was inspired
> by Bellovin, rather than myself. :-)
> 

Ah, I see your point :-)

Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

[Ben Campbell]

On Apr 25, 2013, at 7:44 PM, Ben Campbell  wrote:

> So 6528 equally illustrates Steve Bellovin's  work, and is also more current, 
> right? If someone decided to follow up to better understand your inspiration, 
> which draft would you prefer them to read?

oops, s/draft/version.

Re: Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

[Ben Campbell]

On Apr 25, 2013, at 5:32 PM, Fernando Gont  wrote:

> Hi, Ben,
> 
> Thanks so much for your feedback! Please find my comments in-line...
> 
> On 04/25/2013 03:39 PM, Ben Campbell wrote:
>> Minor issues:
>> 
>> -- section 3, third paragraph from end:
>> 
>> The paragraph suggests that changing the number of network interfaces
>> should be rare. I think it's quite common in practice for the sorts
>> of hosts likely to move between subnets regularly. For example, my
>> Macbook Pro uses an external (Thunderbolt attached) ethernet
>> interface which regularly gets disconnected and reconnected. Same
>> might hold true for a USB attached wireless modem. And I have any
>> number of VPNs which may be active or not at any given time.
> 
> I will tweak the text a bit -- as noted in other threads, I will replace
> "Interface Index" with a generic "Interface_ID", and will comment on the
> desired properties, and note that two possible options for it are the
> Interface Index and the Interface name -- with the interface name
> probably being more constant in the scenarios that you describe.
> 

Works for me.

> 
> 
>> -- section 3, 2nd paragraph from end:
>> 
>> You describe the affects of including Network_ID in some detail. It
>> would be helpful to note the consequences of _not_ including it.
> 
> Well, should we really do it? -- after all, you MUST include it.

Hmm. Section 3 says Network_ID is optional.


> 
>> 
>> Nits/editorial comments:
>> 
>> -- section 1, 4th paragraph: "Therefore, it is vital..."
>> 
>> That seems a bit overstated. We're not talking about breaking the
>> Internet here, are we?
> 
> Well, that depends... there are scenarios in which privacy is really vital.

It's not a big deal, really, but it might be worth mentioning the context in 
which it's "vital". Or maybe tone it down to merely "important" :-)

[...]

> 
> 
> 
>> -- 1, paragraph 11: "This document does not update..."
>> 
>> How is adding an alternative algorithm _not_ an update?
> 
> Well, you still send an RS, receive an RA, and generate an IID.
> 
> Me, I'd probably update RFC 4862, so that we make sure that folks
> implementing SLAAC take a look at this document, but
> 

...?

(The reason you mention is one of the best reasons I can think of to call it an 
update--but if the working group consciously chose not to make it an update, I 
can live with it.)


> 
>> --1, paragraph 12: "... may already address"
>> 
>> Is the "already addressing" part in question? Or is it a matter of
>> addressing it in some circumstances, but not others? If the latter,
>> it would help to elaborate.
> 
> Not sure what you mean. The idea is that, in many scenarios,
> draft-ietf-stable-privacy-addresses may be good enough to address your
> privacy concerns.

The way it's worded, it looks like you think it might address the concerns, but 
aren't sure. I doubt that's the intent. Simply saying "may address certain 
privacy concerns", or "in some circumstances, will address...". OTOH, 
elaborating on the specific concerns addressed would be even better. Do you 
mean to say it addresses the concerns already mentioned in this draft? If so, 
you could use language stronger than "may".

Your answer to my next comment is instructive for this as well.


> 
> 
> 
>> -- 6, last paragraph: "... may mitigate..."
>> 
>> Not sure? Or only under some circumstances?
> 
> The idea is that the only privacy implication that this doesn't mitigate
> is correlation of node activities within the same network.
> However, that really depends on the number of active nodes within the
> same subnet. For example, if you have only one active node in the
> subnet, then no matter whether its changes its addresses, its activities
> can be easily correlated.
> 

Saying that would be helpful.

> 
> 
>> -- references: RFC1948 is obsoleted by 6528. Is there a reason to
>> reference the obsolete version?
> 
> Yes: RFC1948 is only referenced in the Acks section, where I note that
> this document was inspired by Bellovin's work on RFC1948. While RFC6528
> obsoletes RFC1948, the algorithm in that RFC is the same as that in RFC1948.

So 6528 equally illustrates Steve Bellovin's  work, and is also more current, 
right? If someone decided to follow up to better understand your inspiration, 
which draft would you prefer them to read?

Thanks!

Ben.

Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-6man-stable-privacy-addresses-06

Reviewer: Ben Campbell
Review Date: 2013-04-25
IETF LC End Date: 2013-04-16

Summary: This draft is almost ready for publication as a proposed standard. 
There are a few minor issues which should be considered first, described in the 
review.


Major issues:

None.

Minor issues:

-- section 3, third paragraph from end:

The paragraph suggests that changing the number of network interfaces should be 
rare. I think it's quite common in practice for the sorts of hosts likely to 
move between subnets regularly. For example, my Macbook Pro uses an external 
(Thunderbolt attached) ethernet interface which regularly gets disconnected and 
reconnected. Same might hold true for a USB attached wireless modem. And I have 
any number of VPNs which may be active or not at any given time.

-- section 3, 2nd paragraph from end:

You describe the affects of including Network_ID in some detail. It would be 
helpful to note the consequences of _not_ including it.

Nits/editorial comments:

-- section 1, 4th paragraph: "Therefore, it is vital..."

That seems a bit overstated. We're not talking about breaking the Internet 
here, are we?

-- 1, 6th paragraph: "Also, they result in increased complexity..."

What sort of complexity? Implementation complexity? It's a bit confusion 
because the previous sentences already talk about increased complexity of 
specific sorts. It would help to mention what sort of additional complexity is 
referred to here.

-- 1, paragraph 11: "This document does not update..."

How is adding an alternative algorithm _not_ an update?

--1, paragraph 12: "... may already address"

Is the "already addressing" part in question? Or is it a matter of addressing 
it in some circumstances, but not others? If the latter, it would help to 
elaborate.

-- 6, last paragraph: "... may mitigate..."

Not sure? Or only under some circumstances?

-- references:
 RFC1948 is obsoleted by 6528. Is there a reason to reference the obsolete 
version?

Gen-ART Telechat Review of draft-ietf-ospf-ospfv3-iid-registry-update-03

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-ospf-ospfv3-iid-registry-update-03
Reviewer: Ben Campbell
Review Date: 2013-04-19
IESG Telechat date: 2013-04-25

Summary: This draft is ready for publication as a proposed standard. All of the 
comments from my review of 00 at last call have been addressed.

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

-- The abstract should mention that this draft now updates RFC 5838.

-- IDNits has a comment about the lack of pre-5378 work boilerplate that I do 
not think is valid in this case--but it might be worth checking.

Gen-ART Telechat Review of draft-ietf-ospf-ipv4-embedded-ipv6-routing-11

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ospf-ipv4-embedded-ipv6-routing-11 
Reviewer: Ben Campbell
Review Date: 2013-04-19
IESG Telechat date: 2013-04-25

Summary: Ready for publication as an informational RFC. All of the comments 
from my previous review of version 07 have been addressed. However, there 

Major issues:

None

Minor issues:

None

Nits/editorial comments:

Note: The online IDNits tool appears to be broken today, so I was unable to 
recheck this version.

There is a new section 12 added since version 07. If there is another revision 
prior to approval, I suggest the authors make another pass at proofreading it. 
If not, the errors are all of the sort that can be reasonably fixed by the RFC 
editor. Some specifics:

-- paragraph 3, 1st sentence: "If one approach is to be deployed, it is the 
operator's decision for the choice."

-- paragraph 4, 1st sentence: "... there requires some configurations."

Gen-ART Last Call Review of draft-ietf-ospf-ipv4-embedded-ipv6-routing-07

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-ospf-ipv4-embedded-ipv6-routing-07
Reviewer:  Ben Campbell
Review Date: 2013-03-26
IETF LC End Date: 2013-03-29

Summary: The draft is mostly ready for publication as an informational RFC, but 
I have some editorial comments that might be worth considering prior to 
publication.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- Please expand the "P" in "P Router" in the first mention. 

-- section 3.1, paragraph 2: "... and also at least some of their network core 
facing interfaces along with some P routers in the IPv6 network."

This seems vague. Do you mean to say that each must have one or more of their 
core facing interfaces in the topology? Can "some P routers" be stated more 
precisely in terms of the requirements for a particular AFXLBR? 

-- 3.1, paragraph 3, 2nd sentence:

The sentence is hard to parse. Comma usage seems off, and the antecedent of 
"it" is unclear. I suggest breaking it into multiple simpler sentences.

-- 3.2: "... following sub-sections"

Explicit references would be helpful, if this text is ever quoted outside the 
draft. 

-- 3.4:

inconsistent hyphenation of "MTID" vs "MT-ID"

"In addition, the MT bit in the OSPFv3 Option field must be set."

Did you mean that to be an all-caps MUST? I'm neutral on whether it is 
required, but you did use MUST for similar text in the previous section.

-- 4.1, last 2 paragraphs:

Is the 2119 language in these paragraphs new normative language, or 
restatements of normative text in the referenced RFC? If the latter, it would 
be better use descriptive rather than normative language here.

-- 5, 2nd paragraph : " ... the IPv4 networks and IPv6 networks belong to 
separate and independent Autonomous Systems"

The draft has other assertions that appear to say that they are all assumed to 
be in the same autonomous system. (E.g. Section 3.3)

-- 8:

Which is the backdoor? The direct ipv4 route, or the imbedded route? I can 
infer the answer to that, but not until the last sentence.

-- 11, 4th paragraph:

What's the antecedent of "this engineering practice"? This draft? The use of 
the the same SA?

-- 11, last paragraph:

Again, what is the antecedent of "this engineering practice"? Aren't the 
security details of that what this section is about in general? 

-- references:

draft-ietf-ospf-mt-ospfv3-03 has been updated to 04.

Re: Mentoring

[Ben Campbell]

On Mar 20, 2013, at 3:09 AM, Brian E Carpenter  
wrote:

> However, I think an important part of that is ensuring that people
> do *not* focus exclusively on a specific target, even if they are
> busy people as Ben said.

Change the sense of "ensuring" to "encouraging", and I agree. But as worded, 
that sounds a lot like making it harder for someone to focus on the work they 
are interested in. I think that's more likely to make people stop coming than 
making them generalize their work.

Re: Mentoring

[Ben Campbell]

On Mar 18, 2013, at 7:42 AM, Jari Arkko  wrote:

> Seriously though, I am roughly in the same camp as Seiichi. The real 
> introduction of someone into the IETF is mostly about finding discussion 
> partners around the reason why the person came to the IETF to begin with. 
> Most of the time these would be peers within a working group. Like-minded 
> vendors, customers or researchers. Not everyone who comes to the IETF for the 
> first time is a beginner, they may for instance be established engineers on 
> their fields, and just coming to the IETF to accomplish a goal. We discuss 
> very interesting topics at the IESG and IAB, but I think the more direct way 
> to introduce someone to the IETF "network" is to connect the person with 
> others who work in the same topic. And maybe create some real co-operation 
> between those people, building additional reasons for the person to continue 
> to join our meetings.

I quoted Jari's entire paragraph for context, but my comment is in reference to 
"Not everyone who comes to the IETF for the first time is a beginner, they may 
for instance be established engineers on their fields, and just coming to the 
IETF to accomplish a goal. "

This is important. We tend to think of the IETF as a thing. I'm not sure it is, 
anymore. It's a collection of somewhat related working groups. 

A lot of new attendees I have known, or talked to enough to understand why they 
are here, came here to get something specific done. They are not newbies in 
their field, and they don't come here to work in the IETF in general.  
Typically this means they are interested in one or two working groups, unless 
the thing they want to get done spans multiple interdependent groups. (If 
that's the case, then they've got their work cut out for them unless they are 
exceptionally good at organizing strangers.) And they have very busy real-world 
jobs, and are sparing all the time they can just to make it to a couple of 
working groups. I expect they are quite bemused when (and if) they sit through 
a plenary open mike session, when we all go on about the IETF in general.

A few of these people will stay around and become leaders in their area of 
interest, and maybe the IETF in general. Most won't. And that's probably 
okay--or at least the best we can expect.

I think this means we should closely consider the goals of a mentoring effort. 
Is it to help them navigate the IETF structure, personalities, and immune 
system to get something done? Is it to help them become the next generation of 
IETF leaders? I suspect those two goals do not lend themselves to the same 
approach.

Re: Mentoring

[Ben Campbell]

On Mar 19, 2013, at 6:07 PM, Ben Campbell  wrote:

> 
> On Mar 14, 2013, at 9:13 AM, Mary Barnes  wrote:
> 
>> That's a really good idea!
>> 
>> Mary.
>> 
>> On Thu, Mar 14, 2013 at 9:03 AM, Ted Lemon  wrote:
>>> I think it might also be worth encouraging working group chairs to have 
>>> working group breakfast or lunch meetings (RSVP required) where newcomers 
>>> are invited to come meet the chairs and chairs can strategically invite a 
>>> few return attendees (but fewer than newcomers so they don't get crowded 
>>> out) to establish a connection with the newcomers.   If this became common 
>>> it would probably require tool work, but what do folks think of the idea in 
>>> principle?
>>> 
> 
> Hmm. Last I checked there were 10 combined breakfasts and lunches during the 
> week. How many working groups are there?

[Okay, I should learn not to read a long IETF thread in chronological order.]

Re: Mentoring

[Ben Campbell]

On Mar 14, 2013, at 9:13 AM, Mary Barnes  wrote:

> That's a really good idea!
> 
> Mary.
> 
> On Thu, Mar 14, 2013 at 9:03 AM, Ted Lemon  wrote:
>> I think it might also be worth encouraging working group chairs to have 
>> working group breakfast or lunch meetings (RSVP required) where newcomers 
>> are invited to come meet the chairs and chairs can strategically invite a 
>> few return attendees (but fewer than newcomers so they don't get crowded 
>> out) to establish a connection with the newcomers.   If this became common 
>> it would probably require tool work, but what do folks think of the idea in 
>> principle?
>> 

Hmm. Last I checked there were 10 combined breakfasts and lunches during the 
week. How many working groups are there?

Gen-ART LC/Telechat review of draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04
Reviewer: Ben Campbell
Review Date: 2013-02-25
IETF LC End Date: 2013-02-28
IESG Telechat date: 2013-02-28

Summary: Ready for publication as a proposed standard

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- Header:

I ca't help but enjoy the fact that the file name is longer than the draft 
title :-)  (No change needed)

-- section 2, last paragraph:

s/"For e.g."/"For example,"   

Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-ospf-ospfv3-iid-registry-update-00
Reviewer: Ben Campbell
Review Date: 2013-01-16
IETF LC End Date: 2013-01-24

Summary: This draft is not ready for publication as a proposed standard. There 
is a significant IANA registration issue described in the review body.

Major issues:

This draft carves out a significant part of a registry with an assignment 
policy of "standards action" for "private use". It offers very little 
motivation for the change. In my opinion, this sort of change should come with 
a clear justification.

Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry 
to carve out half of the unassigned space for "private use". The justification 
for this is a single sentence saying that some networks need to use IIDs to 
identify specific applications. I think that needs significant elaboration in 
order to motivate the change in a way that the reader can evaluate.

My understanding from the OFPS list is that this is in support of 
draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I 
have to wonder why the draft under review was not simply the IANA 
considerations for that draft.

I suggest one of two paths forward:

1) If this change is in support of that draft in particular, then this draft 
should say that, and include a _normative_ reference. I recognize the normative 
downref would complicate things--but I think that complication is reasonable 
under the circumstances.

2) If this change is to support a general need that goes beyond 
draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe 
that need in enough detail for people to think about it, perhaps with an 
informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an 
_example_.


Minor issues:

-- section 3:

I don't think it's appropriate to use normative language for IANA requests. 
Especially not "MUST". (I think the strongest thing we can do here is a polite 
request :-)  )   I suggest recasting that to descriptive language, and removing 
section 2 and the RFC 2119 reference.

Nits/editorial comments:

None.

Re: I'm struggling with 2219 language again

[Ben Campbell]

I generally take (what I infer to be) Richard's view on the matter.  If not 
doing something will break interoperability or security, then make it 
normative. (I realize that's a gross oversimplification).

But that still doesn't mean you have to have a MUST for every step an 
implementation has to take. To take Dean's original example, I think it makes 
sense to say the implementation "... MUST send a response according to the 
following procedures..." then describe the procedure without peppering it with 
2119 language,  except for special cases when needed for emphasis or clarity. 
This seems to cover the risk of people not implementing stuff, but still avoids 
an explosion of MUSTs (and the resulting requirements matrix).

Sticking with Dean's example, the use of TLS might qualify as one of the 
special cases needing additional normative emphasis, but you can always say 
something like "... MUST send all message over TLS" once, rather than restate 
it for every message.


On Jan 4, 2013, at 1:04 PM, Richard Barnes  wrote:

> Anecdotal data point number N+1...
> 
> As an occasional implementor of IETF specs, I have to say it's much easier to 
> check my conformance if I can just grep for "MUST" and "SHOULD".  It's also 
> easy for developers to get in the bad habit of ONLY doing those things that 
> are clearly marked in that way.  So ISTM that if you're not tagging things 
> you want done with RFC 2119 language, then you're risking people not 
> implementing them.
> 
> 
> 
> On Jan 4, 2013, at 1:15 PM, Peter Saint-Andre  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> Wonderful perennial topic. :)
>> 
>> As I always say when this comes up, when writing drafts I've settled
>> on using the 2119 keywords only in their uppercase form, and otherwise
>> using "need to", "ought to", "might" (etc.) to avoid all possible
>> confusion. Sure, it's a bit stilted, but we're not writing gorgeous
>> prose here, we're writing technical specifications that need to be
>> completely clear.
>> 
>> Peter
>> 
>> - --
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>> 
>> iEYEARECAAYFAlDnHCQACgkQNL8k5A2w/vxKmwCfXKjDtMqQiPp4a0udOB8Q9IbA
>> q9QAoNiXj2r/q4yRLp0B/13m6Xxg5YN4
>> =3PER
>> -END PGP SIGNATURE-
> 

Gen-ART Telechat review of draft-ietf-dhc-relay-id-suboption-11

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dhc-relay-id-suboption-11
Reviewer: Ben Campbell
Review Date: 2013-01-03
IESG Telechat date: 2013-01-10

Summary:  Ready for publication as a proposed standard.

Note: This review is incremental to my previous Gen-ART review at IETF last 
call. The only substantive comment from that review has been addressed in 
discussion. There are two remaining trivial editorial comments that the authors 
have agreed to address. Since there has not been an update since that previous 
review, I am including them for the sake of documentation. ** Nothing there is 
important enough to delay publication. **

Major issues:

Minor issues:

Nits/editorial comments:

[section copied from previous review]

> -- section 5, last paragraph:
> 
> I suggest removing the scare quotes around "stability". If there are concerns 
> about whether such stability is real, it would be better to say that directly.
> 
> -- informative references:
> 
> draft-ietf-dhc-dhcpv4-bulk-leasequery-06 is now 07

Re: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

[Ben Campbell]

On Dec 21, 2012, at 10:06 AM, Ted Lemon  wrote:

> On Dec 21, 2012, at 10:45 AM, Ben Campbell  wrote:
>> As I responded separately to Ramakrishna, is the SHOULD use 4030 language a 
>> new requirement specific to this draft? Or is it just describing 
>> requirements in 3046 or elsewhere?
> 
> I suppose the authors should really answer this, but I was curious as well, 
> and went looking.   I think RFC4030 should have updated RFC3046 to add this 
> as a security consideration, but it did not.   However, e.g. RFC4243, RFC5010 
> and RFC5107 do add a similar requirement to their security considerations 
> section, so it's probably fair to say that this has been informally adopted 
> as appropriate practice for security considerations sections.   
> 
> Perhaps we should adopt the practice more formally... :)

Pending the authors' comments, it sounds like it's good as is. (Assuming that 
"adopt[ing] the practice more formally" isn't _this_ draft's problem :-)  )

> 

Re: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

[Ben Campbell]

On Dec 21, 2012, at 8:27 AM, Ted Lemon  wrote:

> On Dec 21, 2012, at 7:48 AM, RAMAKRISHNADTV  
> wrote:
>> As Ted mentioned, our draft only proposes a new sub-option for relay-agent 
>> option which was originally created as part of RFC3046. So, the security 
>> considerations for RFC3046 apply to our draft as well. RFC3046 deployments 
>> may
>> use RFC4030 as explained above. So, we indicated in our draft to refer to 
>> both RFC3046 and RFC4030. But there are no specific security issues in the 
>> new relay-id sub-op
>> tion itself to make RFC4030 a MUST.
> 
> To put it a bit differently, changing the security considerations for RFC3046 
> is out of scope for this document.   It could certainly be argued that the 
> security considerations for RFC3046 are too weak, but if that is an argument 
> that someone wants to make, the argument should be made in the context of 
> updating RFC3046, not in the context of adding a new DHCP relay option.
> 

Thanks Ted, that makes perfect sense. 

As I responded separately to Ramakrishna, is the SHOULD use 4030 language a new 
requirement specific to this draft? Or is it just describing requirements in 
3046 or elsewhere?

Thanks!

Ben.

Re: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

[Ben Campbell]

Thanks for the timely response, and the background for the security language. 

This brings up one question, however. See inline: 

Thanks!

Ben.

On Dec 21, 2012, at 6:48 AM, RAMAKRISHNADTV  wrote:

> Hi Ben,
> 
> Thank you for your review comments.
> Please find my responses inline below.
> 
> Regards,
> Ramakrishna DTV.
> 
>> -Original Message-
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: Thursday, December 20, 2012 2:45 AM
>> To: draft-ietf-dhc-relay-id-suboption@tools.ietf.org
>> Cc: gen-...@ietf.org Review Team; ietf@ietf.org List
>> Subject: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-dhc-relay-id-suboption-11
>> Reviewer: Ben Campbell
>> Review Date: 2012-12-19
>> IETF LC End Date: 2013-01-07
>> 
>> Summary: This draft is basically ready for publication as a proposed
>> standard. However, there is one comment from a prior review that I am
>> not sure whether is resolved.
>> 
>> Major issues:
>> 
>> None
>> 
>> Minor issues:
>> 
>> -- In Sean Turner's 2009 review of version 07 of the document [
>> http://www.ietf.org/mail-archive/web/gen-art/current/msg04614.html ], he
>> made the following comment:
>> 
>>> In the security considerations it says look to RFC 3046 and
>>> RFC 4030 for security considerations and then says SHOULD use the
>> relay
>>> agent authentication option from RFC 4030.  RFC 3046 is targeted at
>>> network infrastructures that are "trusted and secure" and RFC 4030
>>> allows the relay agent to be part of this trusted and secure network.
>>> If an implementation doesn't use the relay agent authentication
>> option,
>>> then the relay agent can't be part of the "trusted and secure"
>> network.
> 
> RFC3046 created the relay agent information option.
> Relay agent information option exists only in the messages between
> relay agents and DHCP servers. RFC3046 is targeted at network infrastructures
> that are "trusted and secure" as far as the paths among relay agents and DHCP
> servers is concerned. In many deployments, relay agents and DHCP servers
> are under a single administrative control. By careful design and engineering
> of the network, it is possible to ensure that the network infrastructure
> comprising relay agents and DHCP server is trusted and secure. To achieve 
> that,
> RFC4030 may be used but is not a MUST. If not, RFC4030 would already be a MUST
> for RFC3046 deployment. But that is not currently the case.

Is the SHOULD use 4030 language a new normative requirement, or is it simply 
describing existing requirements from 3046 or elsewhere?  If it's a new 
normative requirement, then I am fine with your answer and withdraw the 
concern. If not, then it would be better to use descriptive rather than 
normative language in this draft.


> 
>>> This makes me think that the relay agent authentication option from
>>> RFC 4030 ought to be a MUST not a SHOULD?
>> 
>> I can't tell from the resulting conversation if that comment is
>> addressed in the current text. Additional text has been added, but the
>> SHOULD remains. I'm willing to accept it has been addressed if the
>> author's say so--I only mention it to make sure it didn't fall through a
>> crack.
>> 
> 
> We have indeed discussed about this comment and addressed it.
> 
> The following was a related comment from DHC WG Chair (Ted Lemon)
> (http://www.ietf.org/mail-archive/web/gen-art/current/msg04615.html):
> 
>   "This document makes no changes to practice that require more or less 
> security
>   than is provided by existing relay agent options in RFC3046. Thus, the
>   security considerations in RFC3046 should be adequate."
> 
> As Ted mentioned, our draft only proposes a new sub-option for relay-agent
> option which was originally created as part of RFC3046. So, the security
> considerations for RFC3046 apply to our draft as well. RFC3046 deployments may
> use RFC4030 as explained above. So, we indicated in our draft to refer to
> both RFC3046 and RFC4030. But there are no specific security issues in the
> new relay-id sub-option itself to make RFC4030 a MUST.
> 
> 
>> Nits/editorial comments:
>> 
>> -- sect

Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-relay-id-suboption-11
Reviewer: Ben Campbell
Review Date: 2012-12-19
IETF LC End Date: 2013-01-07

Summary: This draft is basically ready for publication as a proposed standard. 
However, there is one comment from a prior review that I am not sure whether is 
resolved.

Major issues:

None

Minor issues:

-- In Sean Turner's 2009 review of version 07 of the document [ 
http://www.ietf.org/mail-archive/web/gen-art/current/msg04614.html ], he made 
the following comment:

> In the security considerations it says look to RFC 3046 and
> RFC 4030 for security considerations and then says SHOULD use the relay
> agent authentication option from RFC 4030.  RFC 3046 is targeted at
> network infrastructures that are "trusted and secure" and RFC 4030
> allows the relay agent to be part of this trusted and secure network.
> If an implementation doesn't use the relay agent authentication option,
> then the relay agent can't be part of the "trusted and secure" network.
>  This makes me think that the relay agent authentication option from
> RFC 4030 ought to be a MUST not a SHOULD?

I can't tell from the resulting conversation if that comment is addressed in 
the current text. Additional text has been added, but the SHOULD remains. I'm 
willing to accept it has been addressed if the author's say so--I only mention 
it to make sure it didn't fall through a crack.

Nits/editorial comments:

-- section 5, last paragraph:

I suggest removing the scare quotes around "stability". If there are concerns 
about whether such stability is real, it would be better to say that directly.

-- informative references:

draft-ietf-dhc-dhcpv4-bulk-leasequery-06 is now 07

Re: Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06

[Ben Campbell]

I think Nick's email was a review of the document in general, rather than 
commentary on my review in particular. But since it was addressed to me, I do 
have one comment in response:

On Dec 18, 2012, at 4:12 PM, Nick Hilliard  wrote:

> On 18/12/2012 20:14, Ben Campbell wrote:
>> ** Nits/editorial comments:
>> 
>> -- The 2119 paragraph was removed, but there's still an orphaned 2119 entry 
>> in the informational reference section.
> 
> I'm not sure that this was a good idea.  There are a lot of "has to"s in
> this text, and it's not clear to me whether they are phrased like that as a
> way of getting around 2119, or what's going on.  Whatever the reason, "has
> to" sounds very informal and probably not suitable for a document like
> this.  Could we have some clarification as to why "has to" doesn't mean
> "MUST" (or even "SHOULD").

I don't think so. This draft does not establish a standard, or define a 
protocol. While I don't speak for the authors, I don't think it's intended to 
make normative statements about anything. The language is descriptive, not 
prescriptive.

(I agree "has to" is an awkward substitute for the non-normative "must". I 
agree that "must" should generally be avoided when there can be confusion about 
the normativeness of a statement. I'm not sure that's the case here, since the 
whole doc is non-normative. And I think we could find better language even when 
the confusion is possible.)

Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-karp-routing-tcp-analysis-07
Reviewer: Ben Campbell
Review Date: 2012-12-18
IESG Telechat date: 2012-12-20

Summary: Ready for publication as an informational RFC. There are still a 
couple of nits that might be worth consideration prior to final publication.

Note: This review is incremental to my review of version 05 at last call. All 
of my comments in that review have been resolved except as described in this 
message.

** Major issues:

None

** Minor issues:

None

** Nits/editorial comments:

-- The 2119 paragraph was removed, but there's still an orphaned 2119 entry in 
the informational reference section.

-- There's a new IANA considerations section. However, I suggest it contain a 
full sentence to the effect of "This document makes no requests of IANA" rather 
than simply "None".  (OTOH, this may get removed before final publication 
anyway...)

Re: [Gen-art] Gen-ART LC Review of draft-ietf-karp-routing-tcp-analysis-05.txt

[Ben Campbell]

Hi Mahesh,

The proposed changes work for me.

Thanks!

Ben.

On Nov 30, 2012, at 11:03 AM, Mahesh Jethanandani  
wrote:

> Ben,
> 
> See inline. If you are ok with these changes, I will go ahead and submit an 
> updated version of the draft.
> 
> On Nov 25, 2012, at 5:56 PM, Mahesh Jethanandani wrote:
> 
>> Further trimming it to sections that require a response.
>> 
>> On Nov 21, 2012, at 3:12 PM, Ben Campbell wrote:
>> 
>>> 
>>>>> 
>>>>> *** Minor issues *** :
>>>>> 
>>>>> -- section 2.2, last paragraph:
>>>>> 
>>>>> The IKE mention lacks context. Do you mean to suggest IKE with IPSec? I 
>>>>> assume so, but there's been no mention of IPSec so far.
>>>> 
>>>> No. It implies the use of IKEv2 protocol for performing mutual 
>>>> authentication and establishing SA. There is no suggestion of using IKE 
>>>> with IPSec.
>>>> 
>>>> How about this?
>>>> 
>>>> For point-to-point key management IKEv2[RFC5996] protocol provides ...
>>> 
>>> 5996 describes IKEv2 as a component of IPSec, and a key-management 
>>> mechanism for ESP and AH SAs. Now, I won't claim to be an IKE expert by any 
>>> extent, but I think that if you mean to use IKE _without_ IPSec it would be 
>>> good to add a sentence or two pointing that out. Or is there some other 
>>> reference that could be used that describes using IKEv2 for non-IPSec SAs?
>> 
>> Added this sentence.
>> 
>> Although IKEv2 is discussed as a component of IPsec, KMP can use just the 
>> mutual authentication and SA establishment portion of IKEv2.
> 
> This statement has been further modified to:
> 
> For point-to-point key management IKEv2 [RFC5996] provides for
>  automated key exchange under a SA and can be used for a comprehensive
>  Key Management Protocol (KMP) solution for routers.  IKEv2 can be used
>  for both IPsec SAs [RFC4301] and other types of SAs. For example, 
>  Fibre Channel SAs  [RFC4595] are currently negotiated with IKEv2. Using
>  IKEv2 to negotiate TCP-AO is a possible option.
> 
> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> *** Nits/editorial comments ***:
>>>>> 
>>>>> -- IDNits indicates some unused and obsoleted references. Please check.
>>>> 
>>>> Found one unused reference and have removed it.
>>> 
>>> Seems like there were more than one. From IDNits:
>>> 
>>>  == Missing Reference: 'IRR' is mentioned on line 92, but not defined
>>> 
>>>  == Unused Reference: 'RFC2409' is defined on line 585, but no explicit
>>> reference was found in the text
>>> 
>>>  == Unused Reference: 'RFC3547' is defined on line 588, but no explicit
>>> reference was found in the text
>>> 
>>>  ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)
>>> 
>>>  -- Obsolete informational reference (is this intentional?): RFC 2409
>>> (Obsoleted by RFC 4306)
>>> 
>>>  -- Obsolete informational reference (is this intentional?): RFC 3547
>>> (Obsoleted by RFC 6407)
>> 
>> I have removed these unused references.
>> 
>>> 
>>>>> 
>>>>> -- section 4, 2nd paragraph: "In addition Improving TCP’s Robustness to 
>>>>> Blind In-Window Attacks."
>>>>> 
>>>>> sentence fragment.
>>>> 
>>>> Changed it to say:
>>>> 
>>>> In addition, the recommendations in Improving TCP's Robustness to Blind 
>>>> In-Window Attacks
>>>> 
>>> 
>>> Am I correct in assuming this merges with the following sentence? 
>>> Otherwise, it's still a fragment.
>>> 
>> 
>> Changed it to:
>> 
>> In addition, the recommendations in RFC 5961 should also be followed ...
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Re: Gen-ART LC Review of draft-ietf-karp-routing-tcp-analysis-05.txt

[Ben Campbell]

Hi, thanks for the response. I removed sections that didn't seem to need 
further comment:

On Nov 19, 2012, at 1:58 AM, Mahesh Jethanandani  
wrote:

[...]

>> 
>> *** Minor issues *** :
>> 
>> -- section 2.2, last paragraph:
>> 
>> The IKE mention lacks context. Do you mean to suggest IKE with IPSec? I 
>> assume so, but there's been no mention of IPSec so far.
> 
> No. It implies the use of IKEv2 protocol for performing mutual authentication 
> and establishing SA. There is no suggestion of using IKE with IPSec.
> 
> How about this?
> 
> For point-to-point key management IKEv2[RFC5996] protocol provides ...

5996 describes IKEv2 as a component of IPSec, and a key-management mechanism 
for ESP and AH SAs. Now, I won't claim to be an IKE expert by any extent, but I 
think that if you mean to use IKE _without_ IPSec it would be good to add a 
sentence or two pointing that out. Or is there some other reference that could 
be used that describes using IKEv2 for non-IPSec SAs?

> 
> 
>> 
>> -- section 2.3.2:
>> 
>> It would be helpful for this section to describe whether privacy issues 
>> actually matter or not, rather than just stating the issues to be similar to 
>> those for other routing protocols.
> 
> Changed it to:
> 
> Labels, like routing information are distributed in the clear. There is 
> currently no requirement for labels to be encrypted and that work is outside 
> the scope of the KARP working group.

WFM

> 
>> 
>> -- section 3.1, 2nd paragraph:
>> 
>> Does this mean that privacy is really not needed, or just that LDP does not 
>> state a requirement for privacy?
> 
> Further clarified it in this section.
> 
> Labels are similar to routing information which is distributed in the clear. 
> It is important to ensure that routers exchaning labels are mutually 
> authenticated and that there are no rogue peers or unauthenticated peers that 
> can compromise the stability of the network. However, there is currently no 
> requirement that the labels be encrypted.

Okay

> 
>> 
>> -- Section 6 (Security Considerations), 4th paragraph:
>> 
>> If replay protection is required, shouldn't the draft discuss the details 
>> somewhere? I see only one mention in passing outside of this section.
> 
> I have moved the replay protection requirement to the gap analysis section. 
> 
> However, this document is a analysis draft, and it is my understanding that 
> details on what replay protection methods should be adopted, is best left to 
> the routing protocols in question. 

That's fine, pointing out the gap is sufficient.

> 
>> 
>> *** Nits/editorial comments ***:
>> 
>> -- IDNits indicates some unused and obsoleted references. Please check.
> 
> Found one unused reference and have removed it.

Seems like there were more than one. From IDNits:

  == Missing Reference: 'IRR' is mentioned on line 92, but not defined

  == Unused Reference: 'RFC2409' is defined on line 585, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC3547' is defined on line 588, but no explicit
 reference was found in the text

  ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)

  -- Obsolete informational reference (is this intentional?): RFC 2409
 (Obsoleted by RFC 4306)

  -- Obsolete informational reference (is this intentional?): RFC 3547
 (Obsoleted by RFC 6407)

[...]
> 
>> 
>> -- section 2.1,  5th paragraph:
>> 
>> A mention of SHA1 seems needed here. Section 2.3.1.2 states the concerns 
>> about TCP-md5 more clearly.
> 
> The 6th paragraph states the concern and mentions SHA-1. Did you want 
> something more to be included?

No, sorry, on a re-read I think it's okay.

[...]

>> 
>> -- section 4, 2nd paragraph: "In addition Improving TCP’s Robustness to 
>> Blind In-Window Attacks."
>> 
>> sentence fragment.
> 
> Changed it to say:
> 
> In addition, the recommendations in Improving TCP's Robustness to Blind 
> In-Window Attacks
> 

Am I correct in assuming this merges with the following sentence? Otherwise, 
it's still a fragment.

[...]

Thanks!

Ben.

Gen-ART LC Review of draft-ietf-karp-routing-tcp-analysis-05.txt

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-karp-routing-tcp-analysis-05.txt
Reviewer: Ben Campbell
Review Date: 2012-11-14
IETF LC End Date: 2012-11-19

Summary: This draft is almost ready for publication as an informational RFC. 
There are a few minor issues and a number of editorial issues that should be 
considered prior to publication.

*** Major issues ***:

None

*** Minor issues *** :

-- section 2.2, last paragraph:

The IKE mention lacks context. Do you mean to suggest IKE with IPSec? I assume 
so, but there's been no mention of IPSec so far.

-- section 2.3.2:

It would be helpful for this section to describe whether privacy issues 
actually matter or not, rather than just stating the issues to be similar to 
those for other routing protocols.

-- section 3.1, 2nd paragraph:

Does this mean that privacy is really not needed, or just that LDP does not 
state a requirement for privacy?

-- Section 6 (Security Considerations), 4th paragraph:

If replay protection is required, shouldn't the draft discuss the details 
somewhere? I see only one mention in passing outside of this section.

*** Nits/editorial comments ***:

-- IDNits indicates some unused and obsoleted references. Please check.

-- The IANA considerations section is missing. If the draft makes requests of 
IANA, it should include the section and state that.

-- the short title is "The IANA considerations section is missing. If the draft 
makes requests of IANA, it should include the section and say that

-- The short title is "draft-ietf-karp-routing-tcp-analysis-05.txt". Is this 
draft in any way specific to TCP? If so, it would be helpful to mention that in 
the abstract and introduction.

-- Punctuation errors are pervasive, particularly in the early and late 
sections. These make it harder to read than it needs to be. In particular, I 
suggest the draft be proofread for missing commas and missing quotes (or other 
marks) around document titles.

-- Section 1, paragraph 1:

The cited doc name should be quoted, or otherwise marked. Also, it's not 
necessary to put the full reference here, since you are citing the references 
section.

-- Section 1, paragraph 1: "Four main steps were identified for that 
tightening:"

For what tightening? This is the first mention. Perhaps the previous sentence 
should have gone on to say "... and suggests steps to tighten the 
infrastructure against the attack"?

-- section 1, 1st paragraph after numbered list:

The end of the paragraph does not seem related to the beginning. I suggest a 
paragraph split before the sentence starting with "The OPSEC working group..." 

-- section 1, 2nd to last paragraph: "current state of security method"

Missing article before "security method".

-- section 1.1:

Why is 2119 language needed? I see two potentially normative statements--but 
both of those merely describe the existing MAC requirements in TCP-AO. It would 
be better to state those in descriptive language (e.g. TCP-AO requires…) and to 
drop the 2119 section entirely. 

-- section 2.1,  5th paragraph:

A mention of SHA1 seems needed here. Section 2.3.1.2 states the concerns about 
TCP-md5 more clearly.

-- section 2.3.1.2, 1st paragraph: "As stated above..."

A section reference would be helpful.

-- section 4, 2nd paragraph: "In addition Improving TCP’s Robustness to Blind 
In-Window Attacks."

sentence fragment.

-- section 4, 3rd paragraph:

It would have been helpful to mention the MKT manual config issue back in the 
"state of the security method" sections.

Gen-ART Telechat Review of draft-leiba-extended-doc-shepherd-06

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-leiba-extended-doc-shepherd-01
Reviewer: Ben Campbell  
Review Date: 2012-11-12
IESG Telechat date: 2012-11-15

Summary: I have mixed feelings about this draft being published as an IETF 
stream RFC in it's current form.

Major issues:

This draft is not substantially changed since my Gen-ART review of version 00 
at last call. I've copied that review in it's entirety below. There is a new 
section indicating that the ideas herein should be adapted to the 
circumstances. This helps, but I think my original comments still stand.

I am sympathetic to Adrian Farrel's DISCUSS position as updated on 2012-11-05. 
OTOH, it seems like there should be a place to capture this sort of opinion 
document, and it's a bit large and involved to simply send to a mailing list 
for discussion.

On Oct 23, 2012, at 5:07 PM, Ben Campbell  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document:  draft-leiba-extended-doc-shepherd-00
> 
> Reviewer: Ben Campbell
> Review Date: 2012-10-23
> IETF LC End Date: 2012-10-23
> 
> Summary: I'm not sure what to make of this draft. I think the opinions herein 
> are worth capturing, but have mixed feelings about it belong in an 
> informational RFC.
> 
> Major issues:
> 
> -- Process: I share some of the concerns that have been mentioned by others, 
> namely that I'm not sure whether an individual opinion paper should be 
> published as an informational RFC. OTOH, I'm not sure that it shouldn't. The 
> operative words here are "I'm not sure." The opinions contained in the 
> document are interesting, and likely of use to the community. I just wonder 
> if another publication form might not be more appropriate.
> 
> -- Content: It's hard to disagree with most of the activities in general, but 
> it seems to me that much of the pre pubreq processes here are just things 
> that Chairs should be doing anyway. I guess it doesn't hurt to call all of 
> that "shepherding", but I don't think it's the same thing as "having a 
> shepherd" in the PROTO sense.  I see the potential value of having continuity 
> of responsibility throughout the entire process, but I also see value in the 
> flexibility of deferring the shepherd selection until time for the proto 
> writeup. (I recognize that you don't necessarily expect the same person to 
> shepherd all phases--but if I read correctly you also seem to indicate a 
> preference that they do so.)
> 
> Minor issues:
> 
> -- section 1, 4th paragraph: "It adds to what’s in RFC 4858, intending to 
> extend it, not replace it."
> 
> Do you intend this to formally update 4858? It doesn't seem like it from the 
> rest of the text, but one might infer otherwise from this sentence.
> 
> -- section 4, 2nd paragraph: "... What it all boils down to is setting up one 
> person who takes responsibility for following the progress of a document from 
> Call for Adoption through Publication ..."
> 
> The text offers examples of changing the responsible person during the 
> process, but also mentions the advantages of continuity. If continuity is the 
> real goal, then are the examples that show the role changing over the life of 
> the draft are counterproductive?
> 
> 
> Nits/editorial comments:
> 
> None.

Gen-ART Telechat Review of draft-ietf-mptcp-api-06

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mptcp-api-06
Reviewer: Ben Campbell  
Review Date: 2012-11-12
IESG Telechat date: 2012-11-15

Summary: This draft is basically ready for publication as an informational RFC. 
All of the comments from my Gen-ART review of version 05 at IETF last call have 
been dealt with to my satisfaction in the draft or in email, save the one minor 
issue below.

Major issues:

Minor issues:

I made the following comment at last call. It's not a show stopper, but I think 
it should be considered:

> -- It seems like at least passing knowledge of the sockets API is needed to 
> understand this document. I'm curious why the POSIX reference is 
> informational rather than normative?

The authors indicated they believed the reference at the end of paragraph 3 of 
section 1 to be truly informational. However, I called out an mention at the 
beginning of the same paragraph that should have included a citation, and that 
I thought that citation would justify a normative reference. The authors added 
the citation in version 06, but the reference is still informational.


Nits/editorial comments:

IDNits reports that "A later version (-12) exists of
 draft-ietf-mptcp-multiaddressed-09"

Gen-ART LC Review of draft-leiba-extended-doc-shepherd-00

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-leiba-extended-doc-shepherd-00

Reviewer: Ben Campbell
Review Date: 2012-10-23
IETF LC End Date: 2012-10-23

Summary: I'm not sure what to make of this draft. I think the opinions herein 
are worth capturing, but have mixed feelings about it belong in an 
informational RFC.

Major issues:

-- Process: I share some of the concerns that have been mentioned by others, 
namely that I'm not sure whether an individual opinion paper should be 
published as an informational RFC. OTOH, I'm not sure that it shouldn't. The 
operative words here are "I'm not sure." The opinions contained in the document 
are interesting, and likely of use to the community. I just wonder if another 
publication form might not be more appropriate.

-- Content: It's hard to disagree with most of the activities in general, but 
it seems to me that much of the pre pubreq processes here are just things that 
Chairs should be doing anyway. I guess it doesn't hurt to call all of that 
"shepherding", but I don't think it's the same thing as "having a shepherd" in 
the PROTO sense.  I see the potential value of having continuity of 
responsibility throughout the entire process, but I also see value in the 
flexibility of deferring the shepherd selection until time for the proto 
writeup. (I recognize that you don't necessarily expect the same person to 
shepherd all phases--but if I read correctly you also seem to indicate a 
preference that they do so.)

Minor issues:

-- section 1, 4th paragraph: "It adds to what’s in RFC 4858, intending to 
extend it, not replace it."

Do you intend this to formally update 4858? It doesn't seem like it from the 
rest of the text, but one might infer otherwise from this sentence.

-- section 4, 2nd paragraph: "... What it all boils down to is setting up one 
person who takes responsibility for following the progress of a document from 
Call for Adoption through Publication ..."

The text offers examples of changing the responsible person during the process, 
but also mentions the advantages of continuity. If continuity is the real goal, 
then are the examples that show the role changing over the life of the draft 
are counterproductive?


Nits/editorial comments:

None.

Gen-ART LC Review of draft-leiba-extended-doc-shepherd-00

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-leiba-extended-doc-shepherd-00

Reviewer: Ben Campbell
Review Date: 2012-10-23
IETF LC End Date: 2012-10-23

Summary: I'm not sure what to make of this draft. I think the opinions herein 
are worth capturing, but have mixed feelings about it belong in an 
informational RFC.

Major issues:

-- Process: I share some of the concerns that have been mentioned by others, 
namely that I'm not sure whether an individual opinion paper should be 
published as an informational RFC. OTOH, I'm not sure that it shouldn't. The 
operative words here are "I'm not sure." The opinions contained in the document 
are interesting, and likely of use to the community. I just wonder if another 
publication form might not be more appropriate.

-- Content: It's hard to disagree with most of the activities in general, but 
it seems to me that much of the pre pubreq processes here are just things that 
Chairs should be doing anyway. I guess it doesn't hurt to call all of that 
"shepherding", but I don't think it's the same thing as "having a shepherd" in 
the PROTO sense.  I see the potential value of having continuity of 
responsibility throughout the entire process, but I also see value in the 
flexibility of deferring the shepherd selection until time for the proto 
writeup. (I recognize that you don't necessarily expect the same person to 
shepherd all phases--but if I read correctly you also seem to indicate a 
preference that they do so.)

Minor issues:

-- section 1, 4th paragraph: "It adds to what’s in RFC 4858, intending to 
extend it, not replace it."

Do you intend this to formally update 4858? It doesn't seem like it from the 
rest of the text, but one might infer otherwise from this sentence.

-- section 4, 2nd paragraph: "... What it all boils down to is setting up one 
person who takes responsibility for following the progress of a document from 
Call for Adoption through Publication ..."

The text offers examples of changing the responsible person during the process, 
but also mentions the advantages of continuity. If continuity is the real goal, 
then are the examples that show the role changing over the life of the draft 
are counterproductive?


Nits/editorial comments:

None.

Gen-ART Telechat review of draft-ietf-websec-strict-transport-sec-13

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-websec-strict-transport-sec-13
Reviewer: Ben Campbell
Review Date: 2012-09-25
IESG Telechat date: 2012-09-27

Note: This review is incremental to my Gen-ART review of version 11 at IETF LC.


Summary: This version is ready for publication as a proposed standard.  All of 
my concerns from the previous review have been addressed in the draft or 
through conversation.

Major issues: None

Minor issues: None

Nits/editorial comments: None.

Re: Obsoletes/Updates in the abstract (Was: Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07)

[Ben Campbell]

On Sep 21, 2012, at 11:14 AM, Pete Resnick  wrote:

> [Changing the subject and removing GenArt and the document authors/chairs]
> 
> On 9/21/12 10:52 AM, Glen Zorn wrote:
> 
 -- The abstract should mention that this obsoletes 5721
>> 
>> Why?  There is a statement in the header, 10 lines above the abstract, that 
>> says "Obsoletes: 5721 (if approved)".
> 
> The IESG put this into the nits check before my time. The Last Call and 
> publication announcements normally contain only the abstract, not the 
> metadata above, and I believe the thinking was that if you are a person who 
> scans through those announcements, you probably would (and would want to) 
> take notice of documents that purport to obsolete or update document that you 
> recognize. We could probably change the tool to add the metadata to the 
> announcements, but apparently quite a few people read "abstracting" services 
> that grab the abstracts of newly published documents. Not much we can do for 
> them.
> 
> It's certainly useful to some folks. Necessary? (*Shrug*) Not enough wasted 
> bits for me to care one way or the other.
> 

As a Gen-ART reviewer, I called it out for exactly the reasons Pete mentions, 
and care about the same amount :-) But putting it there seems to hurt nothing, 
and maybe help just a little bit in some cases.

Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

[Ben Campbell]

Thanks for the response!

On Sep 21, 2012, at 10:23 AM, Pete Resnick  wrote:
> 

[...]

>> -- same paragraph : "The UTF8 command MAY fail."
>> 
>> Under what circumstances? (this seems sort of tacked onto the 
>> paragraph--does it belong there?)
>>   
> 
> AFAICT, it is simply a warning to client writers that the server may (for 
> whatever reasons under whatever circumstances) send back an -ERR response to 
> the command, even if it advertises the capability. Seems appropriate.
> 
>> -- 2.1, 4th paragraph: "...need not be accurate, but it is preferable if 
>> they were."
>> 
>> Not preferable enough for a SHOULD? (Note that the previous sentence used 
>> SHOULD for reporting actual message size counts)
>>   
> 
> There is no interoperability impact regarding sizes in STAT and free-form 
> text (unlike LIST), so SHOULD is inappropriate.
> 

Okay.


>> -- section 7, 3rd paragraph: "It is possible for a man-in-the-middle 
>> attacker to insert a LANG command in the command stream, thus making 
>> protocol-level diagnostic responses unintelligible to the user."
>> 
>> This seems a bit unnecessary to call out, given that a MiTM could just 
>> change the diagnostic responses into Klingon even in the absence of the LANG 
>> command. It's at least worth mentioning that the LANG command really doesn't 
>> make this issue worse than it already was.
>>   
> 
> Taken under advisement.
> 
> pr
> 
> -- 
> Pete Resnick
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

[Ben Campbell]

On Sep 21, 2012, at 10:52 AM, Glen Zorn  wrote:

> 
> On 09/21/2012 10:44 PM, Pete Resnick wrote:
>> On 9/21/12 10:23 AM, Pete Resnick wrote:
 -- The abstract should mention that this obsoletes 5721
> 
> Why?  There is a statement in the header, 10 lines above the abstract, that 
> says "Obsoletes: 5721 (if approved)".

The abstract is sometimes displayed without the rest of the document, for 
example, in new RFC announcements.

> 
>>> 
>>> It does.
>> 
>> Sorry. You said abstract, not intro. Got it.
>> 
>> pr
>> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Re: Gen-ART LC Review of draft-ietf-eai-popimap-downgrade-07

[Ben Campbell]

Hi,

Email discussion about the simple downgrade draft made me think of a concern 
that I think I failed to mention in my review. In particular, the "tunneling" 
mechanism allows the creation of several new "Downgraded-*" header fields 
containing encoded content from the original message. Given that downgraded 
messages are primarily to be consumed by legacy clients, which we can assume do 
not know anything about this draft, why would we expect the clients to present 
those headers to the user, or otherwise notify the user of their existence?

Thanks!

Ben.


On Sep 18, 2012, at 9:15 PM, Ben Campbell  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-eai-popimap-downgrade-07
> Reviewer: Ben Campbell
> Review Date: 2012-09-18
> IETF LC End Date: 2012-09-20
> 
> Summary: This draft is mostly on the right track, but has open issues
> 
> Major issues:
> 
> -- I'm concerned about the security considerations related to having a mail 
> drop modify a potentially signed message. The draft mentions that this is an 
> issue. I think more discussion is warranted. In particular. What client 
> behavior is expected when a signature is invalidated due to downgrading? I 
> suspect the answer is "warn the user, who will most likely just click through 
> without understanding the issue." I'm concerned about adding yet another 
> reason to train end users to ignore security warnings. OTOH, should the mail 
> drop strip out signatures? That has it's own issues. I'm not saying that I 
> know the answer--merely that it's not clear to me that it has been 
> sufficiently explored.
> 
> [Note: The same issue is there for draft-ietf-eai-simpledowngrade]
> 
> Minor issues:
> 
> -- It's not clear to me why this is standards track rather than 
> informational. As far as I can tell, it's mainly used by the IMAP UTF8 
> capability draft. But that draft seems to list this as an example of 
> something you can do, and lists it as an informational reference.
> 
> --  draft-ietf-eai-simpledowngrade proposes to register a "DOWNGRADED" 
> response code. It seems like that should be used by both or neither downgrade 
> draft. (This is mentioned as an open issue in draft-ietf-eai-simpledowngrade).
> 
> Nits/editorial comments:
> 
> -- General: 
> 
> As far as I can tell, this draft and draft-ietf-eai-simpledowngrade offer two 
> alternatives to solve the same problem. Unfortunately they are very different 
> in structure and terminology. It would make life easier for the reader if 
> they were more consistent with one-another.
> 
> I found the structure hard to read in places. In particular, the mixing of 
> imperative sentences  in paragraph form with complicated conditions made it 
> easy to get lost. Either a more descriptive vs imperative style, or breaking 
> things down more into (numbered or bulleted) steps might make it easier to 
> read. 
> 
> -- 1.1:
> 
> It would be helpful to be more explicit about what is meant by "legacy 
> clients". Am I correct to assume it means clients that do not support the 
> UTF8 capabilities in the relevant drafts from this workgroup?
> 
> -- 1.3, 2nd paragraph
> 
> s/ "unknown/broken" / "unknown or broken"
> 
> -- 3.1.8, 1st paragraph: " If the  of the  element does 
> not contain non-ASCII characters, the  element contains non-ASCII 
> characters."
> 
> This appears to say that if the local part has no non-ASCII characters, then 
> the domain part does. Is that the intent? I.e. there is no possibility that 
> neither has non-ASCII chars?
> 
> -- 3.1.8, 2nd paragraph: "... the model above."
> 
> Please reference the section number.
> 
> -- 3.2.1:
> 
> Jumping right into the header field list without any preamble is rather 
> abrubt.
> 
> --3.2.1: First paragraph after the header field list: " Optionally add those 
> words where appropriate to the next paragraph, but I think once will make it 
> clear."
> 
> I assume this was an internal comment meant to be deleted?
> 
> -- 3.2.9: 2nd paragraph: "Perform  downgrading."
> 
> Is there a condition missing here? (The structure of 3.2.9 is confusing in 
> general--the paragraphs feel out of order.)
> 
> -- 5: 
> 
> Nothing for content-type?
> 
> -- 6, 1st paragraph: "But they still contain MIME-encapsulated header fields 
> that contain non-ASCII strings.&

Re: Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

[Ben Campbell]

Thanks for the response--comments inline:

On Sep 19, 2012, at 10:18 AM, Arnt Gulbrandsen  wrote:

> On 09/19/2012 04:24 AM, Ben Campbell wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>  .
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document:  draft-ietf-eai-simpledowngrade-07
>> Reviewer: Ben Campbell
>> Review Date: 2012-09-18
>> IETF LC End Date: 2012-09-20
>> 
>> Summary: This draft is mostly on the right track, but has open issues
>> 
>> Major issues:
>> 
>> -- I'm concerned about the security considerations related to having a mail 
>> drop modify a potentially signed message.
> ...
> 
> Hm, sounds like a misunderstanding. Did you understand that the modification 
> happens in RAM, and that the message stored unmodified and has the valid 
> signature? If not I suppose extra verbiage is needed.

I make no assumptions about whether the modification is persistent in the mail 
drop. The message as delivered to the client, which is where the end user 
actually reads it, is modified.

> 
> The signature issue has been discussed. The answer is more or less: The WG 
> expects EAI users to use EAI-capable software, and to accept partial failure 
> when using software that cannot be updated.

My point is that I believe the potential issues caused by the modification of 
signed content should be covered in more depth. You mention the problem, which 
is good.  I'm not proposing normative guidance, but there's a lot an 
implementor and deployer should think before breaking signed content. 

For example, could they strip signatures? Put in warnings that explain the 
reason a signature cannot be verified? Verify locally and resign the modified 
version (along with a statement about what happened)? Ignore the problem 
because their users never do S/MIME anyway? Even if the draft offers no 
answers, I think it needs to offer more guidance about issues that the reader 
needs to think about and draw conclusions from.

> 
> This entire draft is draft is about damage limitation when an EAI user uses 
> EAI-ignorant software (e.g. your phone, if you do your main mail handling on 
> a computer but occasionally look using the phone). That there will be damage 
> is expected and accepted. IMO it's unavoidable. The WG tries to ensure that 
> the damage is not permanent (in the same example: so you can still read the 
> mail, properly signed and addressed, on your computer).
> 
> FWIW, I mangled a message by hand to see what happened to a signature, and 
> got an angry-looking complaint above the body text. Or maybe it was above the 
> headers. Whatever.
> 
>> Minor Issues:
>> 
>> -- It's not clear to me why this is standards track rather than 
>> informational.
> 
> I don't remember. Perhaps because it needs to update 3501.

Ah, that's a better explanation than I've seen so far :-)

> 
>> -- section 3, 2nd paragraph:
>> 
>> Are there any limits on how much the size can differ from the actual 
>> delivered message? Can it be larger? Smaller? It's worth commenting on 
>> whether this could cause errors in the client. (e.g. Improper memory 
>> allocation)
> 
> An input message can be constructed to make the difference arbitrarily large. 
> For instance, just add an attachment with a suggested filename of a million 
> unicode snowmen, and the surrogate message will be several megabyte smaller 
> than the original. Or if you know that the target server uses a long 
> surrogate address format, add a million short Cc addresses and the surrogate 
> will be blown up by a million long CC addresses.
> 
> I doubt that this is exploitable. You can confuse or irritate the user by 
> making the client say "downloading 1.2MB" when the size before download was 
> reported as 42kb, that's all. I wish all my problems were as small.
> 
> I'll add a comment and a reminder that the actual size is supplied along with 
> the literal during download.
> 

Thanks--It's been a while since I worried about IMAP protocol details. The fact 
that the actual downloaded content size is expressed elsewhere makes this less 
of a concern. (And adding the proposed reminder would help other's avoid the 
same mistake :-)  )

>> -- "Open Issues" section: "Should Kazunori Fujiwara’s downgrade document 
>> also mention DOWNGRADED?"
>> 
>> Good question. It seems like they should be consistent on things like this. 
>> (This is really more a comment on that draft tha

Re: Gen-ART LC Review of draft-ietf-eai-5738bis-09

[Ben Campbell]

On Sep 19, 2012, at 6:53 AM, John C Klensin  wrote:

> Following up on my earlier note about a comment from you that
> really applies to the strategy on which all four documents are
> really based...
> 
> --On Tuesday, September 18, 2012 20:44 -0500 Ben Campbell
>  wrote:
> 
>> ...
>> Along the same lines, section 7 seems to go to lengths to
>> illustrate why downgrading is somewhere between hard and
>> problematic. Do we really believe that downgrading will ever
>> be the "least bad"?
> 
> As compared to what, Ben?  

(I assume that to be rhetorical :-) )

> One alternative is to not support delivery of SMTPUTF8 messages
> at all except in environments in which it can be guaranteed that
> all IMAP and POP clients that might contact the servers are
> already upgraded.  It is operationally possible to make that
> guarantee in a few scenarios, but they are rare.   In those
> scenarios, many people in the WG would say "do that" (easily
> managed by not having the delivery servers accept SMTPUTF8
> messages until the POP/IMAP client upgrades are complete).
> But, for all of the more usual cases in which the IMAP/POP
> server operator cannot control exactly what clients might be
> used, the only alternate is to not allow such messages, ever.
> We don't think that is a desirable choice (or we wouldn't have
> done the work in the WG) but nothing in these protocols require
> that anyone deploy i18n mail.
> 
> For the other alternatives, yes, downgrading --by one of these
> scenarios or some other one-- is, indeed, likely to be "less
> bad" than others in some operational scenarios.   In particular,
> one alternate is for the server to silently delete all messages
> requiring SMTPUTF8 (EAI) capability if a client connects that
> doesn't support the needed capability.  If only because the user
> might later come back with a more capable client (or a message
> access mechanism that doesn't use a POP or IMAP client at all),
> that messaging-deleting alternative is almost certainly the
> worst option of all, making almost anything else "less bad".
> 
> And, again, yes the WG discussed these issues at length, perhaps
> even ad nauseam.

I'm willing to accept that the work group decided this was the best that could 
be done. My concern is that the current situation (5721bis normatively [with a 
MUST] references 5738 bis, which informatively references the downgrade drafts 
(as examples), which are themselves standards track) seems internally 
inconsistent. 

> 
>john
> 
> 

Re: Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

[Ben Campbell]

Hi John, thanks for the response. Comments inline:

On Sep 19, 2012, at 3:45 AM, John C Klensin  wrote:

> 
> 
> --On Tuesday, September 18, 2012 21:24 -0500 Ben Campbell
>  wrote:
> 
>> I am the assigned Gen-ART reviewer for this draft. For
>> background on Gen-ART, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .
>> 
>> Please resolve these comments along with any other Last Call
>> comments you may receive.
>> 
>> Document:  draft-ietf-eai-simpledowngrade-07
>> Reviewer: Ben Campbell
>> Review Date: 2012-09-18
>> IETF LC End Date: 2012-09-20
>> 
>> Summary: This draft is mostly on the right track, but has open
>> issues
>> 
>> Major issues:
>> 
>> -- I'm concerned about the security considerations related to
>> having a mail drop modify a potentially signed message. The
>> draft mentions that this is an issue. I think more discussion
>> is warranted. In particular. What client behavior is expected
>> when a signature is invalidated due to downgrading? I suspect
>> the answer is "warn the user, who will most likely just click
>> through without understanding the issue." I'm concerned about
>> adding yet another reason to train end users to ignore
>> security warnings. OTOH, should the mail drop strip out
>> signatures? That has it's own issues. I'm not saying that I
>> know the answer--merely that it's not clear to me that it has
>> been sufficiently explored.
> 
> Ben,
> 
> I want to respond as WG Co-chair to this one issue.  Comments on
> your minor issues will follow, but please be assured that the
> non-editorial ones (and even some of those) have been discussed
> extensively in the WG.
> 
> There is a fundamental issue that runs across the four
> documents, that the WG discussed extensively, and that the WG
> believes is adequately described.  The WG made an explicit
> decision to not repeat that explanation at every possible point
> and in each document.  It explicitly chose overall brevity over
> repetition partially in the belief that repeating the material
> might cause important comments or requirements to get lost in
> the noise.  At the same time, it is easy to lose sight of the
> issue and its implications when reviewing the documents.  It
> actually becomes very clear when one starts considering
> implementation details.
> 
> That issue is that a upgraded IMAP or POP server may find itself
> in possession of an message that requires SMTPUTF8 ("EAI")
> capability, that it may be one message of that type among many
> messages with ACSCII-only headers that do not require that
> capability, and that it may find itself connected to by a legacy
> client.  There are two important things about that case:
> 
>   * There is absolutely no way to deliver the problem
>   message to the client.  The IMAP and POP specifications,
>   and the basic email transport and header specifications
>   from which their provisions are derived, are absolutely
>   clear that addresses and header fields are in ASCII
>   (IMAP allows for the use of some alternate character
>   sets and encodings, but that turns out to be a bad
>   choice in this case and, fwiw, conversion to use any of
>   them would also invalidate signatures.
>   
>   * There are no provisions in POP or IMAP for the server
>   to say to the client "this particular message fails
>   within the range you have specified, but cannot be
>   delivered to you" (much less why that is the case).  In
>   principle, EAI could have added such capabilities but
>   they would not haved helped legacy clients (that, by
>   definition, didn't implement them), would have added
>   clutter to the protocols, and would not have benefited
>   upgraded clients either (because it is easier to just
>   support UTF-8 headers and other requirements.
> 
> Given that situation, the POP or IMAP server can choose to do
> any of a range of things, all of them bad news.  Two of the
> choices are to _replace_ the original message with a substitute
> (or "synthetic" or "surrogate") message that provides the user
> of the client some more or less good hints  about what is going
> on and what the original message was about.  What is being
> delivered is not the original message.  If the original
> contained non-ASCII addresses, the surrogate will not be able to
> represent them directly and will, in general, not be reply-able.
> Expecting an integrity check on the original message to be valid
> with the surrogate one is

Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-simpledowngrade-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20

Summary: This draft is mostly on the right track, but has open issues

Major issues:

-- I'm concerned about the security considerations related to having a mail 
drop modify a potentially signed message. The draft mentions that this is an 
issue. I think more discussion is warranted. In particular. What client 
behavior is expected when a signature is invalidated due to downgrading? I 
suspect the answer is "warn the user, who will most likely just click through 
without understanding the issue." I'm concerned about adding yet another reason 
to train end users to ignore security warnings. OTOH, should the mail drop 
strip out signatures? That has it's own issues. I'm not saying that I know the 
answer--merely that it's not clear to me that it has been sufficiently explored.

Minor Issues:

-- It's not clear to me why this is standards track rather than informational. 
As far as I can tell, it's mainly used by the IMAP UTF8 capability draft. But 
that draft seems to list this as an example of something you can do, and lists 
it as an informational reference.

-- section 3, 2nd paragraph:

Are there any limits on how much the size can differ from the actual delivered 
message? Can it be larger? Smaller? It's worth commenting on whether this could 
cause errors in the client. (e.g. Improper memory allocation)

-- "Open Issues" section: "Should Kazunori Fujiwara’s downgrade document also 
mention DOWNGRADED?"

Good question. It seems like they should be consistent on things like this. 
(This is really more a comment on that draft than this one.)


Nits and Editorial Comments:

-- This draft appears to dispense with 2119 language. It be nice if all the 
drafts in the group handled this consistently.

-- Abstract should mention that this updates 3501

-- section 1:

Can you more explicitly define "conventional"? I assume this means clients not 
supporting the relevant UTF8 capabilities? This terminology is inconsistent 
between this and draft-ietf-eai-popimap-downgrade.

Gen-ART LC Review of draft-ietf-eai-popimap-downgrade-07

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-eai-popimap-downgrade-07
Reviewer: Ben Campbell  
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20

Summary: This draft is mostly on the right track, but has open issues

Major issues:

-- I'm concerned about the security considerations related to having a mail 
drop modify a potentially signed message. The draft mentions that this is an 
issue. I think more discussion is warranted. In particular. What client 
behavior is expected when a signature is invalidated due to downgrading? I 
suspect the answer is "warn the user, who will most likely just click through 
without understanding the issue." I'm concerned about adding yet another reason 
to train end users to ignore security warnings. OTOH, should the mail drop 
strip out signatures? That has it's own issues. I'm not saying that I know the 
answer--merely that it's not clear to me that it has been sufficiently explored.

[Note: The same issue is there for draft-ietf-eai-simpledowngrade]

Minor issues:

-- It's not clear to me why this is standards track rather than informational. 
As far as I can tell, it's mainly used by the IMAP UTF8 capability draft. But 
that draft seems to list this as an example of something you can do, and lists 
it as an informational reference.

--  draft-ietf-eai-simpledowngrade proposes to register a "DOWNGRADED" response 
code. It seems like that should be used by both or neither downgrade draft. 
(This is mentioned as an open issue in draft-ietf-eai-simpledowngrade).

Nits/editorial comments:

-- General: 

As far as I can tell, this draft and draft-ietf-eai-simpledowngrade offer two 
alternatives to solve the same problem. Unfortunately they are very different 
in structure and terminology. It would make life easier for the reader if they 
were more consistent with one-another.

I found the structure hard to read in places. In particular, the mixing of 
imperative sentences  in paragraph form with complicated conditions made it 
easy to get lost. Either a more descriptive vs imperative style, or breaking 
things down more into (numbered or bulleted) steps might make it easier to 
read. 

-- 1.1:

It would be helpful to be more explicit about what is meant by "legacy 
clients". Am I correct to assume it means clients that do not support the UTF8 
capabilities in the relevant drafts from this workgroup?

-- 1.3, 2nd paragraph

s/ "unknown/broken" / "unknown or broken"

-- 3.1.8, 1st paragraph: " If the  of the  element does 
not contain non-ASCII characters, the  element contains non-ASCII 
characters."

This appears to say that if the local part has no non-ASCII characters, then 
the domain part does. Is that the intent? I.e. there is no possibility that 
neither has non-ASCII chars?

-- 3.1.8, 2nd paragraph: "... the model above."

Please reference the section number.

-- 3.2.1:

Jumping right into the header field list without any preamble is rather abrubt.

--3.2.1: First paragraph after the header field list: " Optionally add those 
words where appropriate to the next paragraph, but I think once will make it 
clear."

I assume this was an internal comment meant to be deleted?

-- 3.2.9: 2nd paragraph: "Perform  downgrading."

Is there a condition missing here? (The structure of 3.2.9 is confusing in 
general--the paragraphs feel out of order.)

-- 5: 

Nothing for content-type?

-- 6, 1st paragraph: "But they still contain MIME-encapsulated header fields 
that contain non-ASCII strings."

Is that always true?

-- 6, 4th paragraph: "Receivers may know they need to update their MUAs, or 
they don’t care."

I don't get the point of this sentence.

-- 8, 1st paragraph: "Please change "should now be" and "should be" to "have 
been""

It's probably not worth changing at this point, but I suggest in general 
writing the words you want to see in the RFC. With all due respect to the 
apparent super powers of the RFC editor staff, asking them to change things 
unnecessarily creates opportunities for error.

-- 8, 2nd paragraph: "However [RFC6530] obsoleted [RFC5504] and this document 
does not use all "Downgraded-" header fields registered by [RFC5504]."

... And therefore what? I sounds like you expect the reader to draw a 
conclusion--better to spell it out.

Re: Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

[Ben Campbell]

On Sep 18, 2012, at 8:18 PM, Ben Campbell  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document:  draft-ietf-eai-rfc5721bis-07
> Reviewer: Ben Campbell
> Review Date: 2012-09-18
> IETF LC End Date: 2012-09-20
> 
> 
> 
> Summary:   The draft is mostly ready for publication as a draft standard. I 
> have a few editorial comments that should be considered prior to publication.

Oops, I meant proposed standard. Sorry for the confusion.

Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-rfc5721bis-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20



Summary:   The draft is mostly ready for publication as a draft standard. I 
have a few editorial comments that should be considered prior to publication.

Major issues: None

Minor issues: 

Nits/editorial comments:

-- IDNits has some complaints; please check.

-- The abstract should mention that this obsoletes 5721

-- section 2.1, 2nd paragraph: "The character encoding format of maildrops may 
not be UTF-8 or ASCII."

I'm confused by this sentence, as it seems to say that the format can't be 
UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the 
draft.  Do you mean to say that it may be some format other than those?

-- same paragraph : "The UTF8 command MAY fail."

Under what circumstances? (this seems sort of tacked onto the paragraph--does 
it belong there?)

-- 2.1, 4th paragraph: "...need not be accurate, but it is preferable if they 
were."

Not preferable enough for a SHOULD? (Note that the previous sentence used 
SHOULD for reporting actual message size counts)

-- section 7, 3rd paragraph: "It is possible for a man-in-the-middle attacker 
to insert a LANG command in the command stream, thus making protocol-level 
diagnostic responses unintelligible to the user."

This seems a bit unnecessary to call out, given that a MiTM could just change 
the diagnostic responses into Klingon even in the absence of the LANG command. 
It's at least worth mentioning that the LANG command really doesn't make this 
issue worse than it already was.

Gen-ART LC Review of draft-ietf-eai-5738bis-09

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-5738bis-09
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20

Summary: The draft is almost ready for publication as a proposed standard. I 
have a few editorial comments as well as some questions about how this relates 
to the EAI downgrade drafts.

Major issues: None

Minor issues: 

-- section 7 talks about how to handle MUAs that do not understand the UTF8 
extensions. It talks about doing complex vs rudimentary downgrades, and lists 
draft-ietf-eai-popimap-downgrade and draft-ietf-eai-simpledowngrade as 
examples. These are both informational references. I note, however, that both 
of those drafts are standards track, which makes me wonder if the authors 
expected a normative reference?

Along the same lines, section 7 seems to go to lengths to illustrate why 
downgrading is somewhere between hard and  problematic. Do we really believe 
that downgrading will ever be the "least bad"?

Nits/editorial comments:

-- IDNits reports issues; please check.

-- Abstract: "This specification replaces RFC 5738."

s/replaces/obsoletes
 (repeats in the last paragraph of section 1).

-- section 3, 1st paragraph: "Note that the "UTF8=ONLY" capability described in 
Section 6 implies the "UTF8=ACCEPT" capability."

I assumed from  context (the paragraph talks about client's use of ENABLE) that 
 this refers to client use of the ENABLE command. But section 6 talks about 
server usemof the capability.

-- 3, 2nd to last paragraph: "Mailbox names MUST comply with the Net-Unicode 
Definition (Section 2 of [RFC5198]) with the specific exception that they MUST 
NOT contain control characters (-001F, 0080-009F), delete (007F), line 
separator (2028), or paragraph separator (2029)."

You might consider recasting that in terms of actor behavior (i.e. what must a 
client and/or server do), given that the mailbox name doesn't get much say in 
the matter. This would be more consistent with the adjoining normative text 
(e.g. the next paragraph talks about how a client MUST do something and a 
server SHOULD enforce it.)

-- 4, 2nd to last paragraph:

Can this sentence be broken up or otherwise simplified? I found it easy to get 
lost in the conditions.

-- 6, 1st paragraph: "As this is an incompatible change to IMAP, a clear 
warning is necessary.  IMAP clients that find implementation of the "UTF8=ONLY" 
capability problematic are encouraged to at least detect the "UTF8=ONLY" 
capability and provide an informative error message to the end-user."

Seems like this should warrant a SHOULD

-- 6, 2nd paragraph: 'The "UTF8=ONLY" capability includes all of the functions 
of "UTF8=ACCEPT"'

Previous text said UTF8-ONLY implied UTF8-ACCEPT. That's subtly different than 
the language in this section. There may not be a practical difference, but it 
would be better to be consistent.

-- 7, 3rd paragraph: "... not really "downgraded ones" (although that 
terminology is often used for convenience) ..."

is there a formal definition of downgrade somewhere? Otherwise it's not clear 
what the objection to its use is.

-- section 9, 1st paragraph:

Is OBSOLETE in all-caps on purpose? It's not a 2119 term.
 

Re: Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

[Ben Campbell]

On Sep 18, 2012, at 8:18 PM, Ben Campbell  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document:  draft-ietf-eai-rfc5721bis-07
> Reviewer: Ben Campbell
> Review Date: 2012-09-18
> IETF LC End Date: 2012-09-20
> 
> 
> 
> Summary:   The draft is mostly ready for publication as a draft standard. I 
> have a few editorial comments that should be considered prior to publication.

Oops, I meant proposed standard. Sorry for the confusion.

Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-rfc5721bis-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20



Summary:   The draft is mostly ready for publication as a draft standard. I 
have a few editorial comments that should be considered prior to publication.

Major issues: None

Minor issues: 

Nits/editorial comments:

-- IDNits has some complaints; please check.

-- The abstract should mention that this obsoletes 5721

-- section 2.1, 2nd paragraph: "The character encoding format of maildrops may 
not be UTF-8 or ASCII."

I'm confused by this sentence, as it seems to say that the format can't be 
UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the 
draft.  Do you mean to say that it may be some format other than those?

-- same paragraph : "The UTF8 command MAY fail."

Under what circumstances? (this seems sort of tacked onto the paragraph--does 
it belong there?)

-- 2.1, 4th paragraph: "...need not be accurate, but it is preferable if they 
were."

Not preferable enough for a SHOULD? (Note that the previous sentence used 
SHOULD for reporting actual message size counts)

-- section 7, 3rd paragraph: "It is possible for a man-in-the-middle attacker 
to insert a LANG command in the command stream, thus making protocol-level 
diagnostic responses unintelligible to the user."

This seems a bit unnecessary to call out, given that a MiTM could just change 
the diagnostic responses into Klingon even in the absence of the LANG command. 
It's at least worth mentioning that the LANG command really doesn't make this 
issue worse than it already was.

Gen-ART Telechat review of draft-eggert-successful-bar-bof-08

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-eggert-successful-bar-bof-08
Reviewer: Ben Campbell
Review Date: 2012-08-28
IESG Telechat date: 2012-08-30

Summary: Ready for publication as an informational RFC

Note: The review assignment was for version 07, but since 08 was published 
prior to my review, I reviewed it instead. This version and related email 
correspondence address all of my concerns from my Gen-ART review of version 06 
at IETF last call.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

None

Re: [Gen-art] Gen-ART LC Review of draft-ietf-mptcp-api-05

[Ben Campbell]

On Aug 13, 2012, at 9:14 AM, philip.eard...@bt.com wrote:

> Ben,
> Thanks for your review. 
> 
> The right status isn't clear-cut (I think), but when we (Chairs & Wes) 
> discussed it, Info seemed best
> * mainly because precedent seems to be that API docs are informational, for 
> example socket API extensions for SCTP 
> http://datatracker.ietf.org/doc/rfc6458/ 

I'm willing to accept that there is precedent for doing this in an 
informational. (I wonder about the rational used previously, but that's 
probably neither here nor there.)

> * also the doc has two main parts - looking at the impact that MPTCP may have 
> on application performance - and describing a basic API for MPTCP-aware 
> applications. The first part seems clearly Informational. So if the API part 
> is not Info, there is the effort of splitting the doc. Pragmatically I think 
> this should only be done if clearly needed.

Agreed.

> 
> I'm afraid I don't know case history of how the IETF tries to extend non-IETF 
> standards.
> 
> On the status of Posix reference, which appears twice in the doc
>>> The abstract specification is in line with the
>   Posix standard [17] as much as possible
>>> One commonly used TCP socket option (TCP_NODELAY) disables the Nagle
>   algorithm as described in [2].  This option is also specified in the
>   Posix standard [17].  
> 
> The guidance:
>>> Normative references specify documents that must be read to understand or 
>>> implement the technology in the new RFC, or whose technology must be 
>>> present for the technology in the new RFC to work.
> 
> On its second appearance, I think [17] is definitely being used informatively.
> The first appearance is less clear  cut, I think. Am inclined to say this is 
> still informative - it's just explaining the style adopted for the abstract 
> specification (if [17] changed then it wouldn't be necessary to change this 
> doc).
> 

Agree that the 2nd appearance is informational. But the paragraph containing 
the first citation also contains the language " 
The de facto standard API for TCP/IP applications is the "sockets" interface. 
This document provides an abstract definition of MPTCP-specific extensions to 
this interface."  It seems to me that one needs to understand the sockets api 
in order to understand an extension to the sockets api. . (And, as an 
additional nit, the first quoted sentence could probably also use a citation to 
[17]) 

> Thanks also for the nits

You're welcome :-)

Thanks!

Ben.

Re: [Gen-art] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

[Ben Campbell]

On Aug 10, 2012, at 4:33 PM, =JeffH  wrote:

> Thanks Ben.
> 
> > Jeff and I had a f2f discussion about this point in Vancouver. To paraphrase
> > (and I assume he will correct me if if I mischaracterize anything), Jeff
> > indicated that this really wasn't a MUST level requirement due to the
> > variation and vagaries in application behavior and abilities.
> 
> Yes, see the NOTE in section 7.2.
> 
> > Rather, it's
> > more of a "do the best you can" sort of thing. Specifically, he indicated
> > that an implementation that chose to go ahead and serve unprotected content
> > due to the listed caveats on redirecting to HTTPS would necessarily be
> > out-of-compliance.
> 
> I presume you actually mean "not necessarily", which would then be correct, 
> unless I'm misunderstanding something.

Oops, you are correct, that's a typo.

> 
> 
> > If the requirement really that you SHOULD NOT (rather than MUST NOT) serve
> > unprotected content, then I think the original language is okay.
> 
> agreed.
> 
> thanks,
> 
> =JeffH
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Gen-ART LC Review of draft-ietf-mptcp-api-05

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-mptcp-api-05

Reviewer: Ben Campbell
Review Date: 2012-08-10
IETF LC End Date: 2012-08-14

Summary: This draft is almost ready for publication, but I have questions about 
its intended informational status.

Major issues: None

Minor issues:

-- Section 5 specifies an abstract "basic" API for MPTCP. The draft 
characterizes this as an extension to the sockets API. On it's face, this 
sounds like it's creating a standard, or will at least have the effect of 
creating a standard. Is that the intent? If so, I wonder why the intended 
status is informational rather than standards track? If not, it would be useful 
to explicitly state the intent. (For example, is this intended as an input to 
inform a standardization effort?)

I realize that the sockets API is not an IETF standard. I don't know if that is 
part of the reason for making this draft informational, nor am I familiar with 
precedent for extending non-IETF-native standards. But at the risk of attacking 
a straw man, I am concerned that putting something that could be interpreted as 
a "standard" in an informational RFC might not be the best practice for solving 
that sort of process issue.


-- It seems like at least passing knowledge of the sockets API is needed to 
understand this document. I'm curious why the POSIX reference is informational 
rather than normative?

Nits/editorial comments:

-- 3.3.1, 1st paragraph: "This will provide greater bandwidth for an 
application. "

I assume this means "as great or greater", given the previous statements that 
MPTCP should be at worst no worse than normal TCP?

-- 3.2.1, 1st paragraph: "...while having TCP SYN/ACK ready to reply to..."

I had to think about this a while to figure out the meaning. Perhaps it could 
be rephrased?

Re: [Gen-art] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

[Ben Campbell]

Jeff and I had a f2f discussion about this point in Vancouver. To paraphrase 
(and I assume he will correct me if if I mischaracterize anything), Jeff 
indicated that this really wasn't a MUST level requirement due to the variation 
and vagaries in application behavior and abilities. Rather, it's more of a "do 
the best you can" sort of thing. Specifically, he indicated that an 
implementation that chose to go ahead and serve unprotected content due to the 
listed caveats on redirecting to HTTPS would necessarily be out-of-compliance.

If the requirement really that you SHOULD NOT (rather than MUST NOT) serve 
unprotected content, then I think the original language is okay.

Thanks!

Ben.

On Aug 9, 2012, at 6:03 PM, Alexey Melnikov  wrote:

> On 02/08/2012 10:46, Ben Campbell wrote:
>> Hi, thanks for the response.  Comments inline:
>> 
>> On Jul 29, 2012, at 10:29 PM, =JeffH  wrote:
> [...]
>>>> -- section 7.2:
>>>> 
>>>> Am I correct to assume that the server must never just serve the content 
>>>> over
>>>> a non-secure connection? If so, it would be helpful to mention that, maybe
>>>> even normatively.
>>> It's a SHOULD, see the Note in that section, so it's already effectively 
>>> stated normatively, though one needs to understand HTTP workings to realize 
>>> it in the way you stated it above.  Perhaps could add a simple statement as 
>>> you suggest to the intro para for section 7 Server Processing Model, to 
>>> address this concern?
>>> 
>> I think something of the form SHOULD redirect to HTTPS, but MUST NOT under 
>> any circumstances send the content unprotected would improve the text.
> 
> Sounds good to me. (And yes, this is implied, but it doesn't hurt to state 
> explicitly.)
> 
>> That's probably already implied, and a reasonable implementor wouldn't due 
>> it anyway. But my experience is that some readers will find strange 
>> interpretations whenever you give them the wiggle room to do so, so it's 
>> better to be explicit.
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

[Ben Campbell]

Jeff and I spoke f2f. Pending actual text, I believe we have resolutions to all 
of my comments save those about an extension registry, which Jeff will discuss 
with other interested parties.

Thanks!

Ben.

On Aug 2, 2012, at 10:46 AM, Ben Campbell  wrote:

> Hi, thanks for the response.  Comments inline:
> 
> On Jul 29, 2012, at 10:29 PM, =JeffH  wrote:
>> 
>>> -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that
>>> should be explicitly flagged and mentioned in the abstract.
>> 
>> Good question, I don't believe we've discussed this possibility directly in 
>> the websec wg. In looking at the RFCs that do update RFC2616, it doesn't 
>> look like draft-ietf-websec-strict-transport-sec (HSTS) is of that ilk.
>> 
>> However, it nominally appears that an argument could be made that it'd be 
>> appropriate to update RFC2818 via draft-ietf-websec-strict-transport-sec, 
>> specifically with regards to Section 2.1.  Connection Initiation.
>> 
>> Though, RFC2818 is Informational, which may be an issue (?). Also, perhaps 
>> this is something to more appropriately do via a standards-track rfc2818bis, 
>> i.e., have the latter reference the HSTS spec.
>> 
>> this is something to discuss this coming week @IETF-84 Vancouver it seems.
>> 
>> 
> 
> I will comment on this in response to your post-meeting email.
> 
> 
>>> -- I did not find any guidance on how to handle UAs that do not understand
>>> this extension. I don't know if this needs to be normative, but the draft
>>> should at least mention the possibility and implications.
>> 
>> Agreed. My -12 working copy now contains these new subsections..
>> 
>> ###
>> 10.  Server Implementation and Deployment Advice
>> 
>>  This section is non-normative.
>> 
>> 10.1.  Non-Conformant User Agent Considerations
>> 
>>  Non-conformant UAs ignore the Strict-Transport-Security header field,
>>  thus non-conformant user agents do not address the threats described
>>  in Section 2.3.1 "Threats Addressed".  Please refer to Section 14.1
>>  "Non-Conformant User Agent Implications" for further discussion.
>> 
>>  .
>>  .
>> 
>> 14.  Security Considerations
>>  .
>>  .
>> 14.1.  Non-Conformant User Agent Implications
>> 
>>  Non-conformant UAs ignore the Strict-Transport-Security header field,
>>  thus non-conformant user agents do not address the threats described
>>  in Section 2.3.1 "Threats Addressed".
>> 
>>  This means that the web application and its users wielding non-
>>  conformant user agents will be vulnerable to both:
>> 
>> Passive network attacks due to web site development and deployment
>> bugs: For example, if the web application contains any insecure,
>> non-"https", references to the web application server, and if not
>> all of its cookies are flagged as "Secure", then its cookies will
>> be vulnerable to passive network sniffing, and potentially
>> subsequent misuse of user credentials.
>> 
>> Active network attacks: If an attacker is able to place a man-in-
>> the-middle, secure transport connection attempts will likely yield
>> warnings to the user, but without HSTS Policy being enforced, the
>> present common practice is to allow the user to "click-through"
>> and proceed.  This renders the user and possibly the web
>> application open to abuse by such an attacker.
>> 
>>  This is essentially the status-quo for all web applications and their
>>  users in the absence of HSTS Policy.
>> ###
> 
> That's all good text, but I'm not sure it actually captures my concern.
> 
> From the server's perspective, the fact that non-conformant UAs may exist, 
> the server cannot assume that UAs will honor the extension. This means that a 
> UA might attempt unprotected access to some resource assumed to be protected 
> by this extension. That is, the server can't merely select the extension and 
> forget about things--it still needs to to take the same care to avoid leaking 
> resources over unprotected connections that it would need to do if this 
> extension did not exist in the first place.
> 
> I think this is implied by your last sentence above, but it would be better 
> to say it explicitly.
> 
> 
>> 
>>> 
>>> -- How should a UA handle potential conflicts between a the policy record
>>> that inclu

Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

[Ben Campbell]

Hi, thanks for the response.  Comments inline:

On Jul 29, 2012, at 10:29 PM, =JeffH  wrote:
> 
> > -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that
> > should be explicitly flagged and mentioned in the abstract.
> 
> Good question, I don't believe we've discussed this possibility directly in 
> the websec wg. In looking at the RFCs that do update RFC2616, it doesn't look 
> like draft-ietf-websec-strict-transport-sec (HSTS) is of that ilk.
> 
> However, it nominally appears that an argument could be made that it'd be 
> appropriate to update RFC2818 via draft-ietf-websec-strict-transport-sec, 
> specifically with regards to Section 2.1.  Connection Initiation.
> 
> Though, RFC2818 is Informational, which may be an issue (?). Also, perhaps 
> this is something to more appropriately do via a standards-track rfc2818bis, 
> i.e., have the latter reference the HSTS spec.
> 
> this is something to discuss this coming week @IETF-84 Vancouver it seems.
> 
> 

I will comment on this in response to your post-meeting email.


> > -- I did not find any guidance on how to handle UAs that do not understand
> > this extension. I don't know if this needs to be normative, but the draft
> > should at least mention the possibility and implications.
> 
> Agreed. My -12 working copy now contains these new subsections..
> 
> ###
> 10.  Server Implementation and Deployment Advice
> 
>   This section is non-normative.
> 
> 10.1.  Non-Conformant User Agent Considerations
> 
>   Non-conformant UAs ignore the Strict-Transport-Security header field,
>   thus non-conformant user agents do not address the threats described
>   in Section 2.3.1 "Threats Addressed".  Please refer to Section 14.1
>   "Non-Conformant User Agent Implications" for further discussion.
> 
>   .
>   .
> 
> 14.  Security Considerations
>   .
>   .
> 14.1.  Non-Conformant User Agent Implications
> 
>   Non-conformant UAs ignore the Strict-Transport-Security header field,
>   thus non-conformant user agents do not address the threats described
>   in Section 2.3.1 "Threats Addressed".
> 
>   This means that the web application and its users wielding non-
>   conformant user agents will be vulnerable to both:
> 
>  Passive network attacks due to web site development and deployment
>  bugs: For example, if the web application contains any insecure,
>  non-"https", references to the web application server, and if not
>  all of its cookies are flagged as "Secure", then its cookies will
>  be vulnerable to passive network sniffing, and potentially
>  subsequent misuse of user credentials.
> 
>  Active network attacks: If an attacker is able to place a man-in-
>  the-middle, secure transport connection attempts will likely yield
>  warnings to the user, but without HSTS Policy being enforced, the
>  present common practice is to allow the user to "click-through"
>  and proceed.  This renders the user and possibly the web
>  application open to abuse by such an attacker.
> 
>   This is essentially the status-quo for all web applications and their
>   users in the absence of HSTS Policy.
> ###

That's all good text, but I'm not sure it actually captures my concern.

From the server's perspective, the fact that non-conformant UAs may exist, the 
server cannot assume that UAs will honor the extension. This means that a UA 
might attempt unprotected access to some resource assumed to be protected by 
this extension. That is, the server can't merely select the extension and 
forget about things--it still needs to to take the same care to avoid leaking 
resources over unprotected connections that it would need to do if this 
extension did not exist in the first place.

I think this is implied by your last sentence above, but it would be better to 
say it explicitly.


> 
> >
> > -- How should a UA handle potential conflicts between a the policy record
> > that includes the includeSubdomain, and any records for subdomains that 
> > might
> > have different parameters?
> 
> this is in the draft. the short answer is that at policy enforcement time, 
> "superdomain matches win".
> 
> At "noting an HSTS Host" time, the HSTS host's policy (if expressed) is noted 
> regardless of whether there are superdomain HSTS hosts asserting 
> "includeSubDomains".
> 
> perhaps this needs to be made more clear?

Maybe I'm missing something, but I'm not getting that answer from the text. Can 
you point out the specific language?

> 
> 
> >
> > -- section 6.1:
> >
> > The draft mentions that directives may be extended, but defers creation of 
> > an
> > IANA registry to the time of first extension. IANA registries are not
> > expensive; I suggest it be created now. If there's a good reason not to, 
> > then
> > the draft should still address the specification policy for extensions.
> >
> > Also, do you expect that some future directive might need

Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-websec-strict-transport-sec-11
Reviewer: Ben Campbell
Review Date: 2012-07-24
IETF LC End Date: 2012-07-25

Summary: This draft is almost ready for publication as a proposed standard, but 
there are a few issues that should be considered first.

*** Major issues:

None

*** Minor issues:

-- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that 
should be explicitly flagged and mentioned in the abstract.

-- I did not find any guidance on how to handle UAs that do not understand this 
extension. I don't know if this needs to be normative, but the draft should at 
least mention the possibility and implications.

-- How should a UA handle potential conflicts between a the policy record that 
includes the includeSubdomain, and any records for subdomains that might have 
different parameters?

-- section 6.1:

The draft mentions that directives may be extended, but defers creation of an 
IANA registry to the time of first extension. IANA registries are not 
expensive; I suggest it be created now. If there's a good reason not to, then 
the draft should still address the specification policy for extensions.

Also, do you expect that some future directive might need to have a 
"required-to-understand" status? Given that this is a security-affecting 
extension, it seems likely. If so, then the mechanism for expressing that needs 
to be defined in this draft.

-- section 7.2:

Am I correct to assume that the server must never just serve the content over a 
non-secure connection? If so, it would be helpful to mention that, maybe even 
normatively.

-- section 8.4:

Does this imply a duty for compliant UAs to check for revocation one way or 
another?


*** Nits/editorial comments:

-- idnits reports an uncited reference:

  == Unused Reference: 'RFC6376' is defined on line 1709, but no explicit
 reference was found in the text

-- section 1.2:

The description of indented notes is almost precisely the opposite of how they 
are described in the RFC editor's style guide. It describes them as 
"parenthetical" notes, which is how experienced RFC readers are likely to 
perceive them. While it doesn't say so explicitly, I think putting normative 
text in parenthetical notes should be avoided. If these are intended to be 
taken more strongly than that (and by the description, I take it they should be 
taken more strongly than the surrounding text), then I suggest choosing a 
stronger prefix than "NOTE:"

-- section 7:

Does the reference to I-D.ietf-tls-ssl-version3 indicate a requirement for 
SSL3? Also, that's a long expired draft, even for an informational reference.

-- section 8.2, paragraph 5 (first non-numbered paragraph after numbered list)

To be pedantic, this could be taken to mean a congruent match only applies if 
the includeSubdomains flag is not present. I assume it's intended to apply 
whether or not the flag is present.

-- section 12 and subsections:

I was surprised to see more apparently normative material after the 
non-normative guidance sections. I think it would improve the organization to 
put this closer to the normative rules for UAs.

-- section 14.1, 4th paragraph (first non-bulleted paragraph following bullet 
list)

This issue is only true for proxies that act as a TLS MiTM, right? Would 
proxies that tunnel TLS via the CONNECT method have this issue?

___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Gen-ART LC Review of draft-ietf-oauth-urn-sub-ns-05

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-oauth-urn-sub-ns-05
Reviewer: Ben Campbell
Review Date: 2012-07-03
IETF LC End Date: 2012-07-11

Summary: Ready for publication as a proposed standard

Major issues: None

Minor issues: None

Nits/editorial comments:

-- section 2:

The RFC 2119 boilerplate is present, but I don't notice any 2119 normative 
language.

-- section 4, first sentence: "None not already inherent to using URNs."

Sentence Fragment.

-- section 5.1, last bullet, "... values subordinate to urn:ietf:params:oauth 
are of the from ..."

Missing word?

Gen-ART LC Review of draft-ietf-6man-rfc3484bis-05

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-6man-rfc3484bis-05
Reviewer: Ben Campbell  
Review Date: 2012-06-14
IETF LC End Date: 2012-06-15

Summary: This draft is almost ready for publication as a proposed standard. I 
have one security consideration question that should be addressed first. I also 
have some editorial comments that might be worth addressing if there is a 
revision prior to publication.

Note: As always, reviewing a "bis" draft is difficult for someone who has not 
been involved in its creation, as one may comment on issues inherited from the 
original RFC that were not in scope to be fixed in a particular "bis" draft. 
Apologies in advance if I run afoul of such things.

Major issues:

None


Minor issues:

-- security considerations, 1st paragraph: "This document has no direct impact 
on Internet infrastructure security."

Can source and/or destination address selection could influence whether data is 
sent over and encrypted path? In particularly true since section 7 allows the 
address selection to influence interface selection? If so, it's worth 
mentioning the fact, and considering whether an encrypted path vs unencrypted 
path should be considered in the selection rules. Perhaps such decisions should 
be made prior to following the rules in this draft--but if so it would be 
helpful to explicitly say that.

Nits/editorial comments:

-- section 3/5, last paragraph: "Whether or not an address is designated a home 
address or care-of address is outside the scope of this document."

This sentence is confusing since the previous sentence indicated that "... it 
is sufficient to know whether or not one’s own addresses are designated as home 
addresses or care-of addresses." Is the point that the _mechanism_ for making 
that designation is out of scope, even though one needs to know the _results_? 
Or is this a question about talking about one's own addresses vs the 
destination addresses?

-- section 4, third paragraph: (starting with "Discussion: ..."

I tend to expect indented paragraphs like this to be parenthetical notes. The 
"discussion" label reinforces this. It seems like normative statements don't 
belong in such paragraphs. Can this be promoted to a normal paragraph? (Note 
that this occurs in several other "discussion" paragraphs as well.)

-- section 4. last paragraph:

Please expand SIIT on first mention.

-- section 5, general:

It would be helpful to define SA, SB prior to use. ( I note that the 
destination section does this for DA and DB.)

-- section 5, last paragraph:

Since this talks about Rule 2, perhaps it should be moved to immediately after 
rule 2?

-- section 6, discussion paragraph after Rule 7:

Please expand 6RD and ISATAP on first mention.

-- section 10.6, first paragraph:

Please expand ULAs on first mention.



-- 

Re: Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04

[Ben Campbell]

Thanks for the quick response. Further comments inline. I deleted sections that 
do not appear to need further discussion.

Thanks!

Ben.

On Jun 1, 2012, at 10:45 AM, Donald Eastlake wrote:

> Hi Ben,
> 
> Thanks for your review. See responses below.
> 
> On Thu, May 31, 2012 at 6:08 PM, Ben Campbell  wrote:
> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>> 
>> Document: draft-ietf-trill-rbridge-extension-04
>> Reviewer: Ben Campbell
>> Review Date: 2012-05-31
>> IETF LC End Date: 2012-06-07
>> IESG Telechat date: 2012-06-07
>> 
>> Note: Since this draft is on the agenda of the IESG Telechat on the
>> same day that the IETF last call expires, this review is intended
>> for both purposes.
>> 
>> Summary:
>> 
>> This draft is almost ready for publication as a proposed standard,
>> but I have some clarification questions and comments that should be
>> considered prior to publication.
>> 
>> Major issues:
>> 
>> None
>> 
>> Minor issues:
>> 
>> -- section 2, general:
>> 
>> Do the authors assume that all TRILL extensions will follow this
>> spec? Since RFC6325 already specifies an extension mechanism, what
>> stops an extension from ignoring this spec and doing something
>> different? Does it hurt if they do?
> 
> I am not aware of any conflicts between this draft and RFC 6325. RFC
> 6325 provides the broadest header option framework, for example
> specifying the field for the length of the options area and the
> initial two critical summary bits. This document fills in the
> structure and allocation mechanism of the remaining bits in the first
> 4-byte word of the options area, consistent with and repeating some
> material from RFC 6325, but leaving specification of the remainder of
> the options area for future documents, which should be consistent with
> both RFC 6325 and this document. (For example, some future version of
> draft-ietf-trill-rbridge-options.)

I agree there is no conflict--this draft adds details, but doesn't seem to 
contradict anything in the RFC.

> 
> However, neither RFC 6325 nor this document can actually actually bind
> the IETF against adopting future standards describing extensions that
> do not conform.

Certainly. Nothing can do that. The IETF can always update a protocol to change 
normative language, no matter how strongly it was stated originally :-)

> If future changes do not follow RFC 6325 or this
> document, for example changing the location or interpretation of the
> option length field in the TRILL Header or changing the interpretation
> of the critical summary bits in the first word of the options area,
> then this would break hardware and software implementations that
> depend on RFC 6325 and/or this document. But I trust the IETF to
> adhere to its usually high standards for backwards compatibility.
> 
> Perhaps this draft should, in the first page header, say "Updates:
> 6325", not in the sense that it makes a change but in the sense that
> it fills in more details.
> 

Assuming the additional details in this draft comprise preferred extension 
mechanism, then I think it makes sense to say that somewhere (perhaps a SHOULD 
strength), and also mark it as updating 6325. Adding details is still an update.


>> -- section 2, 3rd paragraph from end: "Non-critical extensions can
>>   be safely ignored."
>> 
>> Is that intended to be normative? (Seems like it should be, since
>> behavior for critical extensions is normative).
> 
> I think of it as more like the definition of "non-critical".

Sure--I mainly mention it to be consistent with the text for "critical" 
extensions, since it did use normative language about dropping frames.

> 
>> -- section 2.1, 1st paragraph, last sentence:
>> 
>> Redundant with normative language in previous section.
> 
> ? There is a normative requirement to discard frames with any
> unimplemented critical hop-by-hop options present, which might be
> thought to require examination of all options (something manifestly
> impossible since the format of options beyond the first word of the
> options area is not yet normatively specified). The sentence to which
> you refer just clarifies that testing the appropriate crtical summary
> bit(s) in the first word of the options area, if that word is present,
> is all that is required.

section 2 says "Any RBridge receiving a fr

Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-trill-rbridge-extension-04
Reviewer: Ben Campbell
Review Date: 2012-05-31
IETF LC End Date: 2012-06-07
IESG Telechat date: 2012-06-07

Note: Since this draft is on the agenda of the IESG Telechat on the same day 
that the IETF last call expires, this review is intended for both purposes.

Summary: 

This draft is almost ready for publication as a proposed standard, but I have 
some clarification questions and comments that should be considered prior to 
publication.

Major issues:

None

Minor issues:

-- section 2, general:

Do the authors assume that all TRILL extensions will follow this spec? Since 
RFC6325 already specifies an extension mechanism, what stops an extension from 
ignoring this spec and doing something different? Does it hurt if they do?

-- section 2, 3rd paragraph from end: "Non-critical extensions can be safely 
ignored."

Is that intended to be normative? (Seems like it should be, since behavior for 
critical extensions is normative).

-- section 2.1, 1st paragraph, last sentence:

Redundant with normative language in previous section.


-- section 2.3, first paragraph: 

Is the first sentence intended as normative?

-- section 6, last paragraph:

No security implications of this are mentioned. Is it really a security 
consideration?

Also, is this more likely to be set incorrectly than all the other things that 
some implementation might screw up, so that it warrants special treatment?


Nits/editorial comments:

-- section 1: 

Please expand TRILL on first mention in the body of the document (i.e. not just 
in the Abstract.)

-- section 2:

Please expand RBridge and IS-IS on first mention.

-- section 2, bullet list, 2nd bullet: " ... which would only necessarily 
affect the RBridge(s) where a TRILL frame is decapsulated"

Does that mean it always affects the decapsulating RBridge but might effect 
transit RBridges as well? 

-- section 2, first paragraph after bullet list: "critical hop-by-hop extension"

I assume this means an extension with the critical flag set? If so, it would be 
more precise to say that.

-- sectio 2.1, 1st paragraph:

I'm a little confused by a citation for "future documents". Do you mean the 
cited document as an example of something that might do this (in which case a 
"for example" would help), or do you mean to say that document will do this?

-- section 2.2, 1st paragraph:

Please expand PDU on first mention.

-- section 2.3, first paragraph: 

s/modifictions/modifications

-- section 5:

Since section 3 is entirely composed of the referenced table, and seems to 
exist mostly if not entirely for the purpose of this reference, why not just 
move the table to the IANA considerations section.

Gen-ART LC Review of draft-ietf-ccamp-assoc-info-03

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ccamp-assoc-info-03
Reviewer: Ben Campbell
Review Date: 2012-06-14
IETF LC End Date: 2012-06-14

Summary: This draft is ready for publication as an informational RFC.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- 2.1, 1st paragraph:

Please expand RSVP-TE on first mention.

-- 2.1, 2nd paragraph: "...can take place independent from..."

s/independent/independently

-- 2.2, paragraph 5: "... definition of the Association ID, which is (quoting 
[RFC4872]):"

The quoted text this refers to is more of a description of use than a 
definition.

Re: [Gen-art] Gen-ART LC Review of draft-ietf-pwe3-static-pw-status-10

[Ben Campbell]

On Apr 30, 2012, at 12:25 PM, Stewart Bryant wrote:

> Hi Ben
> 
> Thank you for your review.
> 
> The IANA policy is stated as IETF Review (end of first para in IANA)

Okay, I guess I just missed it.

> 
> The normative text is deliberate - this was part of the change that we needed 
> to make.
> 

Then as a reviewer, I think the proposed text is a bit confusing, as a 
paragraph describing how one element operates seems to make a normative 
requirement on the behavior of a different element. It would be better to make 
that assertion in the description of behavior for that other element. This is 
not a big deal, and certainly not a show stopper if people are attached to the 
current approach. It's just a personal opinion.

(Sorry, I'd offer more specifics, but am not in a position to pull up the text 
at the moment, so I'm responding from memory. I will look again when I get the 
chance.)

Thanks!

Ben.

Gen-ART LC Review of draft-ietf-pwe3-static-pw-status-10

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  (Proposed RFC 6478) (was draft-ietf-pwe3-static-pw-status-10)
Reviewer: Ben Campbell
Review Date:  2012-04-26
IETF LC End Date:  2012-04-30

 Note: This draft has previously been approved as RFC 6478, but I 
understand we are last calling it again due to some material changes in AUTH48. 
Therefore this is a review of the diff between revision 10 and the text at 
http://www.rfc-editor.org/authors/rfc6478.txt 


Summary:

The edited text is essentially ready for publication, but I have a couple of 
minor issues that might should be considered first.

Major issues:

None

Minor issues:

-- 5.3, last paragraph:

The last sentence changed from a non-normative statement to "This SHOULD cause 
the PE sending the PW status notification message with a PW status code equal 
to zero to stop sending and to continue normal operation."

Is that really intended as a normative statement, or a statement of fact? I 
suspect it's the latter, but if the former, then it should be stated more of 
the form "If the sending PE receives ... it SHOULD stop ..."

-- IANA considerations:

Maybe I missed it, but I don't see a registration policy for adding things to 
the new registry. This wasn't an AUTH48 change, but it should probably be there.

Gen-ART Telechat review of draft-ietf-ippm-rt-loss-03

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ippm-rt-loss-03
Reviewer: Ben Campbell
Review Date: 2012-04-10
IETF LC End Date: 2012-03-19
IESG Telechat date: 2012-04-12

Summary: This draft is effectively ready for publication as a proposed 
standard, but there are a few minor issues that may need attention first.

Major issues:

None

Minor issues:

-- section 5, last paragraph: " ... (or other process, the details of which 
MUST be specified if used)."

Specified how? Does 2330 state what level of spec is needed? I note this draft 
mentions the lack of an IANA registry...

-- section 7, paragraph 4: "Measurement implementations SHOULD address this 
possible outcome."

This seems to conflict with the MUST in the last paragraph of section 5.4.

-- section 9.1, last paragraph: "should establish bilateral or multi-lateral 
agreements"

Normative?

Also, are such policies really up to the IETF to recommend?

-- section 9.2, first paragraph: "Passive measurement must restrict attention"

Normative?



Nits/editorial comments:

-- section 3.2:

Is Tmax measured at src or dst? Does it effectively represent the "reasonable" 
time limit mentioned in TstampDst?

-- section 5.3:

This seems redundant with last paragraph of section 5.

-- section 7, paragraph 4: "As discussed above..."

A section number would be helpful.

-- section 8, 2nd paragraph: "Both unexpected test packet discards and
   the systematic and random errors and uncertainties MUST be recorded."

Sentence needs some commas to demarcate the two choices.

Gen-ART LC Review of draft-ietf-tcpm-3517bis-02

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-tcpm-3517bis-02
Reviewer: Ben Campbell
Review Date: 2012-04-04
IETF LC End Date: 2012-04-11

Summary: Essentially ready for publication. I've got a few editorial comments 
and nits that might should be considered prior to publication.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- IDNits reports some issues--please check.

-- The headers say the draft obsoletes 3517, but this is not mentioned in the 
abstract. The introduction says this is a revision of 3517, which is a bit 
ambiguous as to whether "revise" means to "obsolete" or "update".

-- Abstract: Any reason not to put the abstract on the first page as is 
currently conventional?

-- section 1, 2nd paragraph, [RFC793]

Consider moving the reference to the first TCP mention.

-- section 1, 2nd paragraph, 2nd to last sentence: "Alternate SACK-based loss 
recovery methods can be used in TCP as implementers see fit (as long as the 
alternate algorithms follow the guidelines provided in [RFC5681])."

This seems redundant with the first sentence in the paragraph.

-- section 2, definition of "Pipe": 'The algorithm is often referred to as the 
"pipe algorithm"'

Which algorithm? The one in this document? The "fundamentally different one"?

-- section 4:

Please expand SMSS on first mention.

Re: [Gen-art] Gen-ART LC/Telechat review of draft-reschke-http-status-308-05

[Ben Campbell]

Apologies for the delayed response--the day job got in the way this week.

Comments inline:

On Mar 12, 2012, at 12:16 PM, Julian Reschke wrote:

> On 2012-03-12 17:15, Ben Campbell wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>> 
>> Document: draft-reschke-http-status-308-05
>> Reviewer: Ben Campbell   
>> Review Date: 2012-03-12
>> IETF LC End Date: 2012-03-16
>> IESG Telechat date: 2012-03-15
>> 
>> Summary: This draft is basically ready for publication as an experimental 
>> RFC. I have a few minor comments that might be worth considering whether 
>> they would improve the document prior to publication.
>> 
>> Note: Since this draft is on a Telechat that precedes the end of the IETF 
>> Last Call, this review serves as both the LC and Telechat review.
> 
> Thanks.
> 
>> Major issues:
>> 
>> None:
>> 
>> Minor issues:
>> 
>> -- General: I see some discussion about existing UA behavior, but nothing 
>> about what a UA should do with a 308 other than as an implication the fact 
>> that this is a "permanent version of 307". It's probably worth describing 
>> that explicitly. (Or is that what the "clients with link-editing 
>> capabilities" statement is intended to do?If so, does that cover everything?)
> 
> The draft uses *exactly* the same words as the base spec (HTTPbis), except 
> that it combines aspects of 302 (permanence) with those of 307. I thought 
> that's clear enough.

I assume you meant 301 and 307. 

I note that all of the 3XX responses have their semantics explicitly described 
in httpbis. While some reference other 3XX codes to contrast the behavior, none 
seem to be defined in terms of each other. The 301 definition includes an 
explicit note about the POST to GET behavior. The 307 definition includes an 
explicit post about that behavior not being allowed. Section 3 of this doc does 
neither.

Looking further, I see that both the 301 and 307 definitions have different 
language about the response payload (they say if the method was not HEAD the 
payload SHOULD contain short  hypertext note, while this doc says the payload 
can contain one. (which I read as equivalent to a MAY).

Finally, both 301 and 307 contain a paragraph about automatic redirection for 
"safe" methods.

> 
>> -- section 1, last paragraph:
>> 
>> The fact that a 308 can't change the method is left as an implication of 
>> being based on 307. It would be good to state that explicitly and 
>> normatively here.
> 
> We don't state it in HTTPbis either. 301, 302, and 303 are exceptions. See 
> the new introduction in 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.7.3>.

HTTPbis sections 7.3.2, 7.3.3, 7.3.4, and 7.3.8 all contain explicit language 
or notes about about  GET and POST. I recognize that it is not stated 
_normatively_ in each case, but it's at least mentioned.

> 
>> -- section 3, 1st paragraph: "Clients with link-editing capabilities ought 
>> to..."
>> 
>> Should that be stated normatively?
> 
> No. Again, this is consistent with the text in HTTPbis for status code 302.

I concur that it says that. I find it unfortunate that HTTPbis used 
non-normative language there, but the text in this draft is consistent.

> 
>> -- section 3, third paragraph: "The new permanent URI SHOULD be given..."
>> 
>> I'm curious why that is not a MUST. Is there a reasonable (i.e. 
>> interoperable)  way to send a 308 _without_ a URI in the location field? Is 
>> the meta refresh directive something that can be used _instead_ of the 
>> Location header field?
> 
> Again, consistency with RFC 2616 and HTTPbis.

You are correct.

> 
>> -- section 4:
>> 
>> The example uses _both_ the location field and the HTML  refresh 
>> directive. Is this considered a recommended practice to the degree you might 
>> normatively recommend it in the text?
> 
> No, it's a hack that makes deployment easier until all UAs do the right 
> thing; we don't want to make that permanent.

A comment to that effect in the text would be helpful.

Gen-ART LC/Telechat review of draft-reschke-http-status-308-05

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-reschke-http-status-308-05
Reviewer: Ben Campbell  
Review Date: 2012-03-12
IETF LC End Date: 2012-03-16
IESG Telechat date: 2012-03-15

Summary: This draft is basically ready for publication as an experimental RFC. 
I have a few minor comments that might be worth considering whether they would 
improve the document prior to publication. 

Note: Since this draft is on a Telechat that precedes the end of the IETF Last 
Call, this review serves as both the LC and Telechat review.


Major issues:

None:

Minor issues:

-- General: I see some discussion about existing UA behavior, but nothing about 
what a UA should do with a 308 other than as an implication the fact that this 
is a "permanent version of 307". It's probably worth describing that 
explicitly. (Or is that what the "clients with link-editing capabilities" 
statement is intended to do?If so, does that cover everything?)

-- section 1, last paragraph: 

The fact that a 308 can't change the method is left as an implication of being 
based on 307. It would be good to state that explicitly and normatively here.

-- section 3, 1st paragraph: "Clients with link-editing capabilities ought 
to..."

Should that be stated normatively?

-- section 3, third paragraph: "The new permanent URI SHOULD be given..."

I'm curious why that is not a MUST. Is there a reasonable (i.e. interoperable)  
way to send a 308 _without_ a URI in the location field? Is the meta refresh 
directive something that can be used _instead_ of the Location header field?

-- section 4: 

The example uses _both_ the location field and the HTML  refresh 
directive. Is this considered a recommended practice to the degree you might 
normatively recommend it in the text?

Nits/editorial comments:

None
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC/Telechat review of draft-ietf-mext-mip6-tls-03

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mext-mip6-tls-03
Reviewer: Ben Campbell
Review Date: 2012-02-28
IETF LC End Date: 2012-02-29
IESG Telechat date: 2012-03-01

Note: Since the Telechat review deadline is a day before the end of the IETF 
last call, this review serves both as a Telechat review and an IETF Last Call 
review.

Summary: This draft is basically ready for publication as an experimental RFC. 
There are some clarification issues that might should be addressed prior to 
publication.

Major issues:

None


Minor issues:

-- general: 

The draft seems to be missing information on how to match TLS certificates to 
identities for HAC authentication.

-- section 1, paragraph 1, last sentence: "Client implementation experience has 
shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex."

It might be worth elaborating on why this is true. Could this be solved with a 
cleaner software architecture rather than a protocol change?

-- section 5.4:  "The actual domain name used in queries is up to the 
deployment to decide and out of scope of this specification."
 
This seems under specified for SRV

-- 5.7.4:

Are more than one DNS server allowed for each protocol?

-- 5.8:

I find this section confusing,as the first and second paragraphs seem to make 
contradictory statements about the authentication, particularly about the use 
of PSK. I think you are talking about authentication of the HAC in the TLS 
handshake vs an higher level authentication of the MN using PSK or EAP. I think 
this could use some clarification, as both paragraphs talks about 
authentication between the MN and HAC without mentioning direction.

Note that this is more clear in the security considerations section, but it 
would help for it to be more clear here.

-- 5.9, 2nd to last paragraph:

How do the first and last sentences relate? It seems to say set it to "1", 
except for this case in which you set it to "1".

-- 8.1:

Is this registry only for TLS based MIPv6? If so, does it need to be explicitly 
constrained to not used for MIPv6 in general?




Nits/editorial comments:

-- section 4.1: 

A picture showing the element and key relationships could be helpful here.

-- section 4.3, third paragraph:

Please expand BA on first mention

--section 4.3, "Security association validity times", : "hours or weeks"

Hours _to_ weeks?

-- section 4.3, "selected cyphersuite": " The selected algorithms SHOULD be one 
of the mutually supported ciphersuites"

How could it be otherwise? (i.e. why the SHOULD, and is this really normative 
vs descriptive?)

-- section 4.4: "Home Agent IP Address" : "Concerns both IPv6 and IPv4 home 
agent addresses."

Dual stack only?  (same applies to "Home Address" section)

-- section 5.1, second paragraph: "All data inside the Content portion of the 
message container MUST be encoded using octets."

I suspect I'm missing a subtlety here--but how else could you do it? Is this 
intended to imply a byte-field, or to imply no additional encoding is used?

-- section 5.2: "From now on, we use TypeValue header (TV-header) term to refer 
request-response message content HTTP-like headers."
 
Maybe that should be moved to the terminology section?

-- section 5.3, 2nd paragraph: "The MN is also the peer that always sends only 
request messages and the HAC only sends response messages."

I'm having trouble parsing. Is their a spurious "always"?

-- section 5.5 : "same to that used by HTTP"

same _as_?

-- section 5.5.5

s/till/until

-- 5.5.8, 1st sentence:

Sentence fragment. Missing words?

-- 5.9, first paragraph:

Sentence fragment.

-- 5.9, 2nd to last paragraph:

s/"In case the"/"In the case that the"

-- 9:

A general discussion of threats would be helpful. Some aspects are scattered in 
the subsections, but a summary in one place would be nice.

-- 9.2: 

It's not clear to me if the text in the "Dictionary Attack" section is actually 
related to dictionary attacks.


-- 6.1:

A picture of the general packet format would be nice. You've got them later for 
specific packet types, but no "general" picture.

--6.2: 

Section seems mostly redundant to 6.1

-- 6.3:

Please expand HoTI on first use.

-- 7:

Please expand CoTI/CoT on first use

-- 8.3:

I'm not sure I understand the mnemonic relevance of "HALTSEC"





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Followup Gen-ART Review on draft-ietf-dhc-forcerenew-nonce

[Ben Campbell]

Hi,

This is a followup on my Gen-ART review of draft-ietf-dhc-forcerenew-nonce-04, 
based on my previous review of version 03. In summary, this version is 
improved, but I still don't think it's ready for publication.


On Feb 6, 2012, at 5:17 PM, Ben Campbell wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
> Document: draft-ietf-dhc-forcerenew-nonce-03
> Reviewer: Ben Campbell
> Review Date: 2012-02-06
> IETF LC End Date: 2012-02-06
> 
> Summary:This draft is not quite ready for publication as a proposed standard. 
> There are some potentially significant issues that should be addressed first.
> 
> [Note: Hopefully this draft has had or will have a SecDir review, since it 
> seems ripe for significant security implications.]
> 

I didn't see a comment about whether this happened. I still recommend a SecDir 
review if one has not yet occurred.

> 
> *** Major issues:
> 
> -- I admit to not being a DHCP expert, but If I understand this draft 
> correctly, it proposes to send what is effectively a secret-key in a DHCPACK 
> request, then use that key to authenticate a force renew message. It seems 
> like any eavesdropper could sniff that key, and use it to spoof force renew 
> requests. The introduction mentions that there may be some environments where 
> the use of RFC3118 authentication could be relaxed, and offers an example of 
> such an environment. But nowhere does this draft appear to be limited in 
> scope to such environments. 
> 
> I think some additional text in (perhaps in the security considerations) is 
> needed to explain either why the vulnerability to eavesdroppers is either 
> okay in general, or limits the mechanism's use to environment where it is 
> okay. It also seems like that, in the best case, this mechanism proves only 
> that a Forcerenew request comes from the same DHCP server as in the original 
> transaction, but otherwise does not prove anything about the identity of that 
> server. If so, it would be worth mentioning it.
> 

This is improved by some changes to the introduction and the security 
considerations. But I still don't see a clear, normative statement about what 
environments this can be safely used in. I know Ted objected to Roberta's 
specific proposal, but I think to move forward this needs _some_ clear, 
concrete guidance about when to use or not to use it, or when 3118 
authentication is more appropriate. Don't leave it up to the reader to draw the 
right conclusion.


> -- The mechanism appears to be limited to HMAC-MD5, and there does not appear 
> to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as 
> the only choice? Is there some expectation that stronger mechanisms or 
> algorithm extensibility would be too expensive? (Perhaps the extensibility 
> method would be to specify another mechanism that's identical except for a 
> different HMAC algorithm. But if that's the intent it should be mentioned.)

There's a statement in the security considerations that "... security of the 
nonce in the case of on-link attacks isn't relevant." It would help drive the 
point home to add something to the effect that "Therefore HMAC-MD5 is by 
definition adequate for the purpose, and there is no need for an extensible 
HMAC mechanism."

> 
> *** Minor issues:
> 
> -- Section 1 " 
> In such environments the mandatory coupling between FORCERENEW and DHCP 
> Authentication [RFC3118] can be relaxed."
> 
> It's not clear to me what connection that assertion has with this draft. Is 
> there an intent that the proposed mechanisms be used only in such 
> environments? I don't find any language scoping this proposal to any 
> particular environment.

See comment under the first "major issue". I still think we need normative, 
concrete guidance about when to use or not to use this mechanism.

[...]


> 
> -- section 3.1.3, 2nd paragraph: "The server SHOULD NOT include this option 
> unless the client has indicated its capability in a DHCP Discovery message."
> 
> Why not; what harm would it do? And on the other hand, if you want to 
> discourage it, why not go all the way to "MUST NOT"?
> 

I don't think my comment has been addressed by the discussion so far. I 
understand that the server should not insert a nonce unless the client has 
advertised support--but is it the author's intent that the server should not 
_advertise_ support unless the client has first advertised support?

Additionally, this update added

Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

[Ben Campbell]

On Feb 13, 2012, at 3:21 PM, Ted Lemon wrote:

> On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote:
>> Do I infer correctly from your comment that the security properties of the 
>> mechanism don't really matter? That is, if the attacker we care about can't 
>> eavesdrop in the first place, does this really need to be an HMAC?
> 
> Hm, I thought about that a bit more after I wrote my response.   The HMAC 
> allows us to avoid sending the nonce in the clear in the DHCPFORCERENEW.   I 
> don't think this adds any value from a security perspective, actually, even 
> though it feels more comfortable.   I suspect it was put in in the original 
> version simply because of that—why send a secret over the wire when you don't 
> have to?   However, the original motivation for using the mechanism from 
> RFC3315 was to avoid defining a new mechanism for a legacy protocol.   If we 
> do need to change it, it's going to require a major rework of the document, 
> and a lot of delay, so if it causes no harm, I think that's not worth doing.

I concur it's probably not worth changing at this point--but it does inform the 
"is MD5 good enough" discussion, which might make it worth mentioning in the 
security considerations.

> 
> I too would like to see the text I proposed added to the security 
> considerations, so that we can be clear about what is being accomplished with 
> this draft.
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

[Ben Campbell]

On Feb 11, 2012, at 10:24 AM, Ted Lemon wrote:

>> [RM] The intention is to use this method only for environments with native 
>> security mechanisms, such as the Broadband Access network. You are right it 
>> is not clearly said in the document I can add the following sentence at the 
>> end of the introduction in order to clarify this point:
>> 
>> "This   mechanism is intended to be use in networks that already have native 
>> security mechanisms that provide sufficient protection against
>> spoofing of DHCP traffic."
> 
> It's probably worth revisiting the purpose of this mechanism.   The problem 
> that we are trying to solve is that people are reluctant to implement 
> DHCPFORCERENEW because it's possible that an off-link attacker could more 
> accurately guess the timing of DHCP renewal messages by first sending a 
> DHCPFORCERENEW.   The mechanism in RFC3315 (DHCPv6), which this document 
> mirrors for DHCPv4, uses a nonce to prevent an off-link attacker from 
> successfully triggering a renewal on a client by sending DHCPFORCERENEW; 
> since the attacker is off-link, it doesn't have the nonce, and can't force a 
> renewal.
> 
> An on-link attacker can always simply watch the DHCP renewal message go out 
> and respond to it, so this mechanism is useless for preventing on-link 
> attacks, and hence the security of the nonce in the case of on-link attacks 
> isn't relevant.  So the above text isn't needed.   It's possible that the 
> document doesn't clearly document the use case for this functionality; if so, 
> you are free to take the above paragraph, Roberta, and modify it to suit your 
> purposes.   But I am against adding the text you proposed, because it 
> excludes the bulk of use cases for the DHCPFORCERENEW nonce mechanism.

This is good information, and it would help to include it in the security 
considerations. I meant (but failed) to  comment in my original review that the 
security considerations would benefit from a more detailed discussion about the 
properties of the mechanism, and what attacks or vulnerabilities it is intended 
to mitigate. Your text above seems to do that.

> 
>> [RM] This is because this mechanism relays on the authentication protocol 
>> defined in section 21.5 of RFC 3315 for DHCPv6 Reconfigure and there 
>> HMAC-MD5 is used.
> 
> Essentially HMAC-MD5 is being used here to package a secret into a chunk of 
> predictable size, and the fact that there are hacks for the mechanism isn't 
> terribly important because the only attacker we are attempting to foil is one 
> that doesn't have access to the cleartext or the ciphertext.

Do I infer correctly from your comment that the security properties of the 
mechanism don't really matter? That is, if the attacker we care about can't 
eavesdrop in the first place, does this really need to be an HMAC?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

[Ben Campbell]

Hi, thanks for the response. See additional comments inline. (I removed 
sections for which no further comment seems necessary)

On Feb 10, 2012, at 7:52 AM, Maglione Roberta wrote:

[...]

> 
> -- I admit to not being a DHCP expert, but If I understand this draft 
> correctly, it proposes to send what is effectively a secret-key in a DHCPACK 
> request, then use that key to authenticate a force renew message. It seems 
> like any eavesdropper could sniff that key, and use it to spoof force renew 
> requests. The introduction mentions that there may be some environments where 
> the use of RFC3118 authentication could be relaxed, and offers an example of 
> such an environment. But nowhere does this draft appear to be limited in 
> scope to such environments.
> 
> [RM] The intention is to use this method only for environments with native 
> security mechanisms, such as the Broadband Access network. You are right it 
> is not clearly said in the document I can add the following sentence at the 
> end of the introduction in order to clarify this point:
> 
> "This   mechanism is intended to be use in networks that already have native 
> security mechanisms that provide sufficient protection against
> spoofing of DHCP traffic."

That helps, although I would suggest an additional sentence mentioning the 
specific risk in using it in environments without sufficient protection. I 
note, however, that Ted objected to this in a separate email--I will reply 
there as well.

> 
> 
> I think some additional text in (perhaps in the security considerations) is 
> needed to explain either why the vulnerability to eavesdroppers is either 
> okay in general, or limits the mechanism's use to environment where it is 
> okay. It also seems like that, in the best case, this mechanism proves only 
> that a Forcerenew request comes from the same DHCP server as in the original 
> transaction, but otherwise does not prove anything about the identity of that 
> server. If so, it would be worth mentioning it.
> 
> [RM] That's correct this mechanism only proves only that a Forcerenew request 
> comes from the same DHCP server: let me say this is a trade off between the 
> total security provided by RFC 3118 and no security at all. In addition this 
> method relays on the same mechanism already used for DHCPv6 Reconfigure 
> message

Understood, and your suggested text from the previous comment mitigates this a 
bit. It would help to include text describing exactly what security properties 
you expect from the mechanism. (e.g. Proving (with limitations) that Forcerenew 
requests come from the same server as the original transaction response, etc.)

> 
> -- The mechanism appears to be limited to HMAC-MD5, and there does not appear 
> to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as 
> the only choice? Is there some expectation that stronger mechanisms or 
> algorithm extensibility would be too expensive? (Perhaps the extensibility 
> method would be to specify another mechanism that's identical except for a 
> different HMAC algorithm. But if that's the intent it should be mentioned.)
> [RM] This is because this mechanism relays on the authentication protocol 
> defined in section 21.5 of RFC 3315 for DHCPv6 Reconfigure and there HMAC-MD5 
> is used.

RFC 3315 was published in 2003. I'm not sure the general impression of HMACMD5 
is the same now as it was in 2003. For example, 
http://www.ietf.org/mail-archive/web/cfrg/current/msg01197.html . I'm willing 
to accept that HMACMD5 is perfectly okay for this application, but it would be 
good to document more motivation than the fact it was used in 3315. If 3315 was 
being written today, would they use it? Is matching 3315 an important goal? I'm 
more interested in whether HMACMD5 is adequate for this particular use case 
based on today's knowledge about possible vulnerabilities or operational issues.

[I mentioned in my original review that I think this draft should get a SecDir 
review. They could certainly access whether hmacmd5 is an issue better than I 
can.]

> 
> *** Minor issues:
> 

[...]

> 
> -- section 3.1.3, 2nd paragraph: "The server SHOULD NOT include this option 
> unless the client has indicated its capability in a DHCP Discovery message."
> 
> Why not; what harm would it do? And on the other hand, if you want to 
> discourage it, why not go all the way to "MUST NOT"?
> 
> [RM] For backward compatibility: if the client did not indicate its 
> capability for this feature it means it is a legacy client and it does not 
> support it, so the server should not send the nonce to this client

The text is not talking about sending the nonce--it's talking about sending the 
FORCERENEW_NONCE_CAPABLE option. Unless I read it wrong, it is saying the 
server SHOULD not advertise support unless the client has already indicated 
support.

> 
> -- section 3.1.3, 5th paragraph: "...  computes an HMAC-MD5 of the Forcerenew 
> message using the Forcerenew nonce .

Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

[Ben Campbell]

Additionally, the I got a failed delivery notice (User Unknow) for David 
Miles's address.

On Feb 6, 2012, at 5:17 PM, Ben Campbell wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
> Document: draft-ietf-dhc-forcerenew-nonce-03
> Reviewer: Ben Campbell
> Review Date: 2012-02-06
> IETF LC End Date: 2012-02-06
> 
> Summary:This draft is not quite ready for publication as a proposed standard. 
> There are some potentially significant issues that should be addressed first.
> 
> [Note: Hopefully this draft has had or will have a SecDir review, since it 
> seems ripe for significant security implications.]
> 
> 
> *** Major issues:
> 
> -- I admit to not being a DHCP expert, but If I understand this draft 
> correctly, it proposes to send what is effectively a secret-key in a DHCPACK 
> request, then use that key to authenticate a force renew message. It seems 
> like any eavesdropper could sniff that key, and use it to spoof force renew 
> requests. The introduction mentions that there may be some environments where 
> the use of RFC3118 authentication could be relaxed, and offers an example of 
> such an environment. But nowhere does this draft appear to be limited in 
> scope to such environments. 
> 
> I think some additional text in (perhaps in the security considerations) is 
> needed to explain either why the vulnerability to eavesdroppers is either 
> okay in general, or limits the mechanism's use to environment where it is 
> okay. It also seems like that, in the best case, this mechanism proves only 
> that a Forcerenew request comes from the same DHCP server as in the original 
> transaction, but otherwise does not prove anything about the identity of that 
> server. If so, it would be worth mentioning it.
> 
> -- The mechanism appears to be limited to HMAC-MD5, and there does not appear 
> to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as 
> the only choice? Is there some expectation that stronger mechanisms or 
> algorithm extensibility would be too expensive? (Perhaps the extensibility 
> method would be to specify another mechanism that's identical except for a 
> different HMAC algorithm. But if that's the intent it should be mentioned.)
> 
> *** Minor issues:
> 
> -- Section 1 " 
> In such environments the mandatory coupling between FORCERENEW and DHCP 
> Authentication [RFC3118] can be relaxed."
> 
> It's not clear to me what connection that assertion has with this draft. Is 
> there an intent that the proposed mechanisms be used only in such 
> environments? I don't find any language scoping this proposal to any 
> particular environment.
> 
> -- section 3:
> 
> Does this draft update either 3203 or 3118? If so, please state that 
> explicitly in the abstract, introduction, and draft headers. (I think it must 
> at least update 3203, since that draft requires the use of 3118, and this 
> draft relaxes that.)
> 
> -- section 3.1, last paragraph: "...only if the client and server are not 
> using any other authentication..."
> 
> That seems to conflict with the statement in section 3 that this mechanism is 
> only used if RFC3118 is not used. That is, it's not a choice between this 
> mechanism or any other mechanism, it's a choice between this mechanism or 
> 3118.
> 
> -- section 3.1.3, 2nd paragraph: "The server SHOULD NOT include this option 
> unless the client has indicated its capability in a DHCP Discovery message."
> 
> Why not; what harm would it do? And on the other hand, if you want to 
> discourage it, why not go all the way to "MUST NOT"?
> 
> -- section 3.1.3, 5th paragraph: "...  computes an HMAC-MD5 of the Forcerenew 
> message using the Forcerenew nonce …"
> 
> Using it how? Is it the secret key for the HMAC calculation? (If so, why 
> aren't we calling it a "key" in the first place?)
> 
> -- section 3.1.4, 1st paragraph: "DHCP servers that support Forcerenew nonce 
> Protocol authentication MUST include the DHCP Forcerenew Nonce protocol 
> authentication option…"
> 
> Only if the client advertised it, right? Otherwise, this seems to conflict 
> with the previous SHOULD NOT.
> 
> -- section 3.1.4, 4th paragraph: "…  
> the client computes an HMAC-MD5 over the DHCP Forcerenew message, using the 
> Forcerenew Nonce …"
> 
> Using it how?
> 
> -- section 6:
> 
> You mention this mechanism is vulnerable 

Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-dhc-forcerenew-nonce-03
Reviewer: Ben Campbell
Review Date: 2012-02-06
IETF LC End Date: 2012-02-06

Summary:This draft is not quite ready for publication as a proposed standard. 
There are some potentially significant issues that should be addressed first.

[Note: Hopefully this draft has had or will have a SecDir review, since it 
seems ripe for significant security implications.]


*** Major issues:

-- I admit to not being a DHCP expert, but If I understand this draft 
correctly, it proposes to send what is effectively a secret-key in a DHCPACK 
request, then use that key to authenticate a force renew message. It seems like 
any eavesdropper could sniff that key, and use it to spoof force renew 
requests. The introduction mentions that there may be some environments where 
the use of RFC3118 authentication could be relaxed, and offers an example of 
such an environment. But nowhere does this draft appear to be limited in scope 
to such environments. 

I think some additional text in (perhaps in the security considerations) is 
needed to explain either why the vulnerability to eavesdroppers is either okay 
in general, or limits the mechanism's use to environment where it is okay. It 
also seems like that, in the best case, this mechanism proves only that a 
Forcerenew request comes from the same DHCP server as in the original 
transaction, but otherwise does not prove anything about the identity of that 
server. If so, it would be worth mentioning it.

-- The mechanism appears to be limited to HMAC-MD5, and there does not appear 
to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as 
the only choice? Is there some expectation that stronger mechanisms or 
algorithm extensibility would be too expensive? (Perhaps the extensibility 
method would be to specify another mechanism that's identical except for a 
different HMAC algorithm. But if that's the intent it should be mentioned.)

*** Minor issues:

-- Section 1 " 
In such environments the mandatory coupling between FORCERENEW and DHCP 
Authentication [RFC3118] can be relaxed."

It's not clear to me what connection that assertion has with this draft. Is 
there an intent that the proposed mechanisms be used only in such environments? 
I don't find any language scoping this proposal to any particular environment.

-- section 3:

Does this draft update either 3203 or 3118? If so, please state that explicitly 
in the abstract, introduction, and draft headers. (I think it must at least 
update 3203, since that draft requires the use of 3118, and this draft relaxes 
that.)

-- section 3.1, last paragraph: "...only if the client and server are not using 
any other authentication..."

That seems to conflict with the statement in section 3 that this mechanism is 
only used if RFC3118 is not used. That is, it's not a choice between this 
mechanism or any other mechanism, it's a choice between this mechanism or 3118.

-- section 3.1.3, 2nd paragraph: "The server SHOULD NOT include this option 
unless the client has indicated its capability in a DHCP Discovery message."

Why not; what harm would it do? And on the other hand, if you want to 
discourage it, why not go all the way to "MUST NOT"?

-- section 3.1.3, 5th paragraph: "...  computes an HMAC-MD5 of the Forcerenew 
message using the Forcerenew nonce …"

Using it how? Is it the secret key for the HMAC calculation? (If so, why aren't 
we calling it a "key" in the first place?)

-- section 3.1.4, 1st paragraph: "DHCP servers that support Forcerenew nonce 
Protocol authentication MUST include the DHCP Forcerenew Nonce protocol 
authentication option…"

Only if the client advertised it, right? Otherwise, this seems to conflict with 
the previous SHOULD NOT.

-- section 3.1.4, 4th paragraph: "…  
the client computes an HMAC-MD5 over the DHCP Forcerenew message, using the 
Forcerenew Nonce …"

Using it how?

-- section 6:

You mention this mechanism is vulnerable to MiTM attacks. Why is this okay? Are 
there some environments where it is good enough and others where it is not? 
(Also, do they really need to be MitM attackers? Seems like any eavesdropper 
could learn the nonce.)

*** Nits/editorial comments:

-- Abstract, second sentence:

I have trouble parsing this sentence. Are the propositions correct?

-- Section 3.1.1,4th paragraph: "… configured to require …"

Do you mean configured to "require", or configured to "use"? I would normally 
take "requires" to mean that the server would not work with clients that don't 
advertise support for the me

Gen-ART LC Review of draft-ietf-avtcore-srtp-vbr-audio-04

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-avtcore-srtp-vbr-audio-04
Reviewer: Ben Campbell
Review Date: 2012-01-23
IETF LC End Date: 2012-01-23

Summary: This draft is ready for publication as a proposed standard.

Note: I performed a gen-art review on revision 3 of this draft in a previous 
last call. My understanding is that the draft has been last called again due to 
the change from BCP to PS. I had no substantive concerns in that version, and 
see no new substantive concerns in this version.

Major issues: None

Minor issues: None

Nits/editorial comments:

-- The draft status still says BCP

-- section 5, 1st paragraph, 2nd to last sentence: "...but the amount of 
padding needed to hide the variation in packet size will depend on the 
codec), codec and the sophistication of the attacker),... "

Perhaps we should just assume the attacker is reasonably sophisticated by 
current standards? I assume you don't expect an implementer to guess how 
sophisticated a potential attack may be in advance--unless that is somehow a 
function of the value of the content?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART Telechat Review of draft-ietf-kitten-sasl-saml-08

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-kitten-sasl-saml-08
Reviewer: Ben Campbell
Review Date: 2012-01-13
IESG Telechat date: 2012-01-19

Summary: This draft is almost ready for publication as a proposed standard. 
There are a few minor issues that should be considered first.

Note: This is incremental to my review of version 06 at last call. Version 08 
is considerably improved and resolved most of my comments. But a few still 
remain. Quoted text below is from that previous review.

Major issues:

None


Minor issues:

> -- section 3.2, last paragraph:  "… needs to correlate the TCP session from 
> the SASL client with the SAML authentication."
> 
> Please elaborate on this correlation

The author added text, but the new text is about correlating response with 
request. The text I mentioned was about correlating a TCP connection to a SAML 
authentication.

> -- section 4, 3rd and 4th paragraph (paragraph a and b)
> 
> These seem like protocol affecting differences. If so, they need elaboration, 
> such as normative statements and formal definitions, or references to such.

I did not see a response to this comment.

> -- section 5, general:
> 
> The section seems to need further elaboration or references

I did not see a response to this comment.

> Also, this section compresses the interaction with the identity provider. Why 
> not show the details for those steps like the others? (If you mean them to be 
> out of scope, then why give as much detail as you do?)
> 

I did not see a response to this comment.



Nits/editorial comments:

> -- Pagination is strange throughout the document. (Mostly blank pages, etc.) 
> It's worse in the PDF version, but still not right in the text version.

Pagination is still strange. I see a few mostly blank pages, diagrams split 
across page breaks, etc.

> -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what needs to 
> be described here."
> 
> That reads like an author's "to do" note to himself. Has the needed 
> description been completed, or does it still need to be described?

Partially fixed. I suggest s/"needs to be"/"is"

> -- section 3.1, first paragraph:
> 
> Is "authorization identifier" the same as "IdP-Identifier"?

The paragraph has been updated, but I still have the question. 

> -- section 3.3, 2nd paragraph:  "and SHALL be used to set state in the server 
> accordingly, and it shall be used by the server"
> 
> Is this new normative language, or a repeat of language from the SAML spec?
> 

The author changed SHALL to MUST, which leads me to believe my comment was not 
clear. I did not object to SHALL. My concern was, with the reference to 
RFC4422, it was not clear if the text was introduction a new normative 
requirement, or just restating requirements from 4422. If the second, then it's 
important to make sure the reader knows which doc is authoritative. You can do 
that by keeping the language descriptive, or by explicitly (and strongly) 
attributing the language with something like 'RFC4433 says, "…. SHALL…."'

If, on the other hand, this is truly a new normative statement, then no change 
is needed.

> -- section 4, 1st paragraph:
> 
> I have difficulty parsing this.

The text is updated, but I still have trouble parsing it. In particular, I'm 
not sure what you mean by the phrase "...and appropriate references of it not 
referenced elsewhere in this document…".

> -- section 7 
> 
> Does the GSS-API description introduce security considerations? If not, 
> please say so.
> 

I did not see a response to this comment.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-kitten-sasl-saml-06
Reviewer: Ben Campbell
Review Date: 2012-01-05
IETF LC End Date:2012-01-05
IESG Telechat date: (if known)

Summary: This draft is on the right track for publication as a proposed 
standard. However, there are a few minor issues, and sufficient editorial 
issues to make the document difficult to understand. 

*** I noticed shortly before sending this that the authors submitted version 07 
today. I have not reviewed that version--this review refers to version 06.

Major issues:

None

Minor issues:

-- section 3.2, last paragraph:  "… needs to correlate the TCP session from the 
SASL client with the SAML authentication."

Please elaborate on this correlation

-- section 4, 2nd paragraph: "The SAML Idenity Provider does not have a role in 
GSS-API, and is considered an internal matter for the OpenID mechanism."

Please elaborate, as this is the only mention of OpenID in the draft. It seems 
out of context.  (If OpenID was in fact intended, please include a citation?)

-- section 4, 3rd and 4th paragraph (paragraph a and b)

These seem like protocol affecting differences. If so, they need elaboration, 
such as normative statements and formal definitions, or references to such.

-- section 5, general:

The section seems to need further elaboration or references

-- section 6.1, step 5 (alt)

Please describe the circumstances where the alternative step would occur. 
(also, please spell out "alternative") 

-- section 6.1, step 6: "The client now sends the URL to a browser for 
processing."

Isn't that a question of software design rather than protocol? (unless you mean 
something more abstract by "browser", in which case it would help to say so.)

Also, this section compresses the interaction with the identity provider. Why 
not show the details for those steps like the others? (If you mean them to be 
out of scope, then why give as much detail as you do?)

-- section 6.2:

The draft does not provide the decoding of the Base64 encoded parts like it did 
in 6.1, Without the decodes, the example is not very illuminating.

-- section 7.4: "This is an option the user has to understand and decide to use 
if the IdP is supporting it."

I doubt end users will read this spec. What does this mean for implementors?



Nits/editorial comments:

-- General:

There are a lot of editorial and organizational issues, some of which created 
difficulty in understanding the authors' intent. I noted a number of these 
below, but I doubt I caught everything. I suggest this draft have another 
detailed proofreading and editing pass before it progresses.

-- Pagination is strange throughout the document. (Mostly blank pages, etc.) 
It's worse in the PDF version, but still not right in the text version.

-- section 1.1, 2nd paragraph:

Repeating the SAML 2.0 citation here would be helpful.

-- section 1.2, 1st paragraph

The sentence structure makes it ambiguous whether the other side of the or 
should be just certificate validation, or TLS with cert validation. 

-- section 2, list starting in 2nd paragraph:

Please leave a blank line between list items. Without it, you get a 
wall-of-text effect that's difficult to read.

-- section 2, list item 3:

Is "service provider" a well defined term as used here?

-- section 2, paragraph after 1st numbered list: "This will be discussed below. 
The steps are shown from below:"

Redundant sentences. Also, I assume the discussion has already been written, so 
"will be" is not correct.

-- section 2, 2nd paragraph after 2nd numbered list: "… flow appears as 
follows:"

Please explicitly mention the figure number. E.g. "… flow appears as shown in 
Figure XX."

-- section 2, figure 2:

The numbers in parentheses are confusing. We just saw a numbered list that sort 
of corresponds to this flow, but the numbers don't match up. I realize later 
sections refer back to these numbers, but without some mention of that, a 
reader is almost certainly going to try to correlate this to the previous list.

-- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what needs to 
be described here."

That reads like an author's "to do" note to himself. Has the needed description 
been completed, or does it still need to be described?

-- section 3, 2nd paragraph: "The name of this mechanism "SAML20"."

Missing word?

-- "(via "gs2-header")"

Missing word?

-- section 3, 3rd paragraph: "The first mechanism message from the client to 
the server is the "initial-response" described below."

Please

Gen-ART Last Call Review of draft-ietf-sieve-include-13

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-sieve-include-13
Reviewer: Ben Campbell
Review Date: 2011-12-13
IETF LC End Date: 2011-12-15

Summary: This draft is almost ready for publication as a proposed standard

Major issues:

None

Minor issues:

-- section 3.1, paragraph 4: "Implementations MUST NOT generate errors for 
recursive inclusions at upload time, as this would force an upload ordering 
requirement upon script authors / generators.  However, if an active script is 
replaced with a faulty script and would remain the active script, an error MUST 
be generated and the upload MUST fail."

These two statements seem contradictory on a quick reading.  In particular, how 
can the latter assertion avoid an upload ordering requirement? Or do you mean 
faulty in some way other than being recursive?

-- section 3.4.1, paragraph 5: "If a "global" command is given the name of a 
variable that has previously been defined in the immediate script with "set", 
an error MUST be generated either when the script is uploaded or at execution 
time."

Does this conflict with the previous statement that it is okay for a global and 
a private variable to have the same name?

-- section 3.4.2:

Why do you need two ways to accomplish the same thing?

Does the global namespace have the same "requires" requirement as the global 
command?

-- section 4.2, paragraph 2:

Can you elaborate on what permissions are proper? Is it different for an 
included script than for any other script?

-- section 4.2, paragraph 3:

Can you elaborate on what you mean by "safe for a storage system"?

Nits/editorial comments:

-- section 3.1, paragraph 4: "authors / generators"

s/ "authors / generators " / "authors and generators"

-- section 3.2, paragraph 9 (Top of page 6): " 
The included script MUST be a valid Sieve script.  Each script MUST
   have its own "require" statements for all optional capabilities used
   by that script. "

Who do these normative statements apply to? As worded, it sounds like they 
apply to the user. It might be better to say that the implementation MUST 
validate that…

-- section 3.4.2, paragraph 3: "Variables declared global and variables 
accessed via the global namespace MUST be one and the same."

Plurality mismatch. I suggest something like "a variable declared as global and 
a variable accesses with the global namespace, otherwise having the same name…"

-- section 5:

Please explicitly mention the name or URL of the registry table to which this 
should be added.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART Telechat review of draft-ietf-tcpm-rfc3782-bis-04

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-rfc3782-bis-04
Reviewer: Ben Campbell
Review Date: 2011-12-12
IESG Telechat date: 2011-12-15

Summary: This draft remains almost ready for publication as a proposed standard

I performed a gen-art review of version 03 of this draft at IETF last call, 
available at http://www.ietf.org/mail-archive/web/gen-art/current/msg06919.html 
. 

Since then, the authors have submitted version 04. However, version 04 does not 
appear to address any of the comments in my previous review, nor have I 
received any responses to the review.

Thanks!

Ben.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC Review of draft-ietf-tcpm-rfc3782-bis

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-tcpm-rfc3782-bis-03
Reviewer: Ben Campbell
Review Date: 2011-11-21
IETF LC End Date: 2011-11-21

Summary: This draft is almost ready for publication as a proposed standard.

Major issues:

None

Minor issues:

-- Appendix A refers the reader back to RFC 3782 for additional information. 
But this draft purports to obsolete that RFC. If there is important info in it 
that is not covered by this draft, then it doesn't really obsolete it. Is there 
a reason that information was not brought forward into this draft?

-- There is very little 2119 normative language. On a quick scan, I see one 
capitalized SHOULD NOT and one MAY. Yet it seems like there are other 
statements that are just as important for correct behavior as those. For the 
sake of consistency, it might be easiest to just drop 2119 language entirely.

-- section 6, 2nd to last paragraph: "...it is important that the sender not 
execute the Fast Recovery steps..."

This sounds like a SHOULD NOT (example of previous comment.)


Nits/editorial comments:

-- IDNits mentions several references that have no citation in the body. I note 
that the PROTO write up indicates these have been considered and are relevant 
to the draft even though they are note cited. My understanding, however, is 
that the RFC editor style guide either requires or strongly suggests that each 
reference be cited.

-- section 4, paragraph 2: "For a TCP that implements…"

a TCP _sender_ ?

-- Appendix A, last paragraph: "Section 11 of [RFC3782] listed changes relative 
to [RFC3782]."

relative to itself?


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART Combined Last Call and Telechat Review of draft-ietf-tcpm-rfc1948bis-01

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-rfc1948bis-01
Reviewer: Ben Campbell
Review Date: 2011-01-01
IETF LC End Date: 2011-01-02
IESG Telechat date: 2011-01-03

Summary: This draft is basically ready for publication as a proposed standard. 
I have a couple of minor comments and nits that might be worth considering, but 
probably shouldn't block anything.

Major issues:

None

Minor issues:

-- section 3, paragraph after ISN formula: "It is vital that F not be 
computable…"

If it's vital for security reasons, it seems like this would be worthy of 
normative language.

-- Normative reference to RFC1321

This is a normative downref. It's a reasonable downref  (maybe even the 
canonical reasonable downref). I call it out for the sake of completeness.

-- Appendix B, Removal of "A Common TCP Bug" section:

Can you comment on why the section was removed?


Nits/editorial comments:

-- abstract

The abstract should explicitly mention the update to RFC793

-- section 1, 2nd paragraph:

Please expand ISN on first mention

-- informative references:

Is there any way to avoid orphaning the last reference fragment? It's confusing 
to find half a reference at the top of the next page.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf