Re: [Gen-art] Genart last call review of draft-ietf-tls-keylogfile-01

[Martin Thomson]

Thanks  Russ,

https://github.com/tlswg/sslkeylogfile/pull/11 and 
https://mailarchive.ietf.org/arch/msg/media-types/5IW3tN6mJkqZMyuYWLwoOMNVhgM/ 
should address those issues.

Cheers,
Martin

On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote:
> Reviewer: Russ Housley
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-tls-keylogfile-01
> Reviewer: Russ Housley
> Review Date: 2024-04-12
> IETF LC End Date: 2024-04-18
> IESG Telechat date: unknown
>
> Summary: Ready
>
>
> Major Concerns:
>
> None
>
>
> Minor Concerns:
>
> Section 3: The text says: "Access to the content of a file in
> SSLKEYLOGFILE format allows an attacker to break the
> confidentiality protection on any TLS connections that are
> included in the file."  This is clearly true.  However, the
> attacker this access to the keys can also break the integrity
> protections.
>
> Section 4: The registration of the new application/sslkeylogfile
> media-type for all IETF registrations in the standards tree
> requires a posting to the media-ty...@iana.org mail list.  A search
> of the mail archive id not uncover "sslkeylogfile".  To avoid delay,
> that mail list discussion should probably get started now.
>
>
> Nits:
>
> Section 1: s/file format that logging/file format for logging/

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

Re: [Gen-art] Golden Gate Tap Room (was: Re: Extended GEN area volunteers' get-together at IETF 117)

[Martin Thomson]

I just got bounced. Novice move, I know, but in case anyone else is late…

On Sun, Jul 23, 2023, at 18:13, Charles Eckel (eckelcu) wrote:
> Got it (before and again now). See you there soon!
>
> Cheers,
> Charles
>
>> On Jul 23, 2023, at 6:11 PM, Lars Eggert  wrote:
>> 
>> Could someone ACK the receipt of this email? Did it not make it?
>> 
>> -- 
>> Sent from a mobile device; please excuse typos.
>> 
>>> On Jul 23, 2023, at 13:23, Lars Eggert  wrote:
>>> 
>>> Hi,
>>> 
>>> Peter booked us into Golden Gate Tap Room (https://www.ggtaproom.com/) from 
>>> 7PM-9PM tonight. It's a few minutes walk from the Hilton: 
>>> https://goo.gl/maps/V3NqLSQam9AvsNKS9
>>> 
>>> See you there!
>>> 
>>> Lars

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

Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-teas-ietf-network-slices-21

[Martin Thomson]

On Wed, Jul 12, 2023, at 03:34, Adrian Farrel wrote:
>> Please consider redrawing the figures using SVG instead of ASCII.
>> Especially Figure 4 would greatly benefit from this enhancement.
>
> I think Figure is about as complex as they get, and it doesn't delight me.
> But using SVG is a step too far for me.

aasvg almost turns Figure 4 into something comprehensible, but I think that the 
problem is that it is just too busy.  The content of those clouds, especially 
the bottom two, is just incomprehensible.  I think that you might be better 
served by trying to do less with the figure.

The top, with some tweaks, looks pretty good with aasvg.  It's quite a bit 
clearer than the text version, despite this not really degrading the text 
version much, if at all.  I couldn't say the same for the bottom half:
  .--..--..--.
  |CE||CE||CE|
  '--''--''--'
 AC :AC :AC :
 -+--++--++--+-   ---
( |PE||PE||PE| ) ( IETF  )
   IETF Network(  '--''--''--'  )   ( Network )
   Slice Service   (:..:)   (  Slice  )
   Request  (  IETF Network Slice  ) (   )  Customer
 v   --   --- View
 v\./...
 v \   /Provider
 v>>>  Grouping/Mapping v v   View
 v   ^ -+--+---+--++--+---+--+--
 v   ^( |PE|...|PE||PE|...|PE|  )
   .-.   (  '--'   '--''--'   '--'   )
   | |   (:.:)
   |   NSC   |(Network Resource Partition   )
   | | -
   | | ^
   | |>  Resource Partitioning |
   '-'   of Filtered Topology  |
 v   v |

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

Re: [Gen-art] Genart last call review of draft-ietf-ohai-ohttp-06

[Martin Thomson]

Hi Peter,

You are the first to review the new revision, so thanks.

https://github.com/ietf-wg-ohai/oblivious-http/pull/235 contains most of the 
fixes here.

On Fri, Dec 16, 2022, at 16:37, Peter Yee via Datatracker wrote:
> Page 6, section
> 2.1, 1st bullet item: should this be “two additional regular HTTP requests”
> instead of “two regular HTTP requests”?

The typical deployment - where gateway and target are colocated - only involves 
two requests in total.  The "at least" exists here to imply that there might be 
more, though the two is a hard minimum (or minumum, I guess).

> Page 8, 3rd full paragraph (“Encoding..”), 3rd sentence: The len() function
> doesn’t appear to be referenced anywhere else in the document, at least from a
> cursory search. Delete the sentence if the function is unneeded.

Good catch.

> Page 9, section 3.2, figure 2: Is 262140 the right number here? It’s not
> divisible by 32. I would have thought it needed to be.

Yeah, that's a straight-up mistake; it doesn't even divide by 8.  Also, I 
realized that this doesn't define what the length field means for the 
subsequent field.  That's a big error that I'll correct separately.

> Page 17, section 5.2, 3rd paragraph, 2nd sentence: append a comma after
> “malformed”.

I think that the rules say you don't need commas until your list has 3 items.

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

Re: [Gen-art] Genart last call review of draft-ietf-httpbis-binary-message-04

[Martin Thomson]

Hey David,

I blame laziness for not trying this earlier, but once I tried out something 
*like* your suggestion I found I was pleased.

https://github.com/httpwg/http-extensions/pull/2127

It might not be as much of a change as you imagined, but I think that a small 
change like this does improve comprehension somewhat.

Thanks,
Martin

On Tue, May 24, 2022, at 23:59, David Schinazi via Datatracker wrote:
> Reviewer: David Schinazi
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-httpbis-binary-message-04
> Reviewer: David Schinazi
> Review Date: 2022-05-24
> IETF LC End Date: 2022-06-03
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Well written concise draft, apart from section 3 - see below.
>
> Major issues: None
>
> Minor issues: While this is an editorial comment, I'm raising it as a minor
> issue because it significantly hampers comprehension in my mind. I find 
> Section
> 3 incredibly hard to reason about. In order to get to the actual format, the
> reader is forced to repeatedly jump forward and backwards using a notepad to
> track state. The draft seems somewhat akin to a game like Myst if you'll 
> pardon
> the analogy. I believe that this could be resolved by the editors without too
> much work by doing the following: - keep the preface to Section 3 as-is, it
> does a great job of introducing the concepts - split up the "Message with
> Known-Length" diagram into two diagrams, one for known-length request and one
> for known-length response - similarly split up "Indeterminate-Length Message"
> diagram - reorder diagrams to avoid forward references, for example
> "Known-Length Field Section" should appear before "Message with Known-Length"
> since the latter relies on the former - define every field using a separate
> bullet following the style from RFC 9000. Currently the draft uses the
> notational conventions from RFC 9000 albeit incorrectly, for example
> "Known-Length Informational Response" does not appear in all "Message with
> Known-Length" structs but the square brackets indicating optionality are
> missing.
>
> While this is fundamentally an editorial issue that is theoretically the
> purview of the editors, such readability difficulties are worth discussing by
> the GEN Area Director if they agree with this assessment.
>
> Nits/editorial comments: None

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

Re: [Gen-art] Genart last call review of draft-ietf-git-using-github-04

[Martin Thomson]

Thanks Brian,

On Sun, Feb 23, 2020, at 17:01, Brian Carpenter via Datatracker wrote:
> Is this draft intended to become part of BCP25? I think it would be
> useful for the IESG to clarify this rather than leave it to the RFC Editor.

This is a good question.  Given the intended status of BCP, I would say that 
integrating into 25 is better than creating a new number.  I don't know how to 
best signal this intent though.

And I fixed the nit in the copy on GitHub.

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

Re: [Gen-art] Genart last call review of draft-nottingham-rfc7320bis-02

[Martin Thomson]

Thanks for the review Robert,

On Wed, Nov 27, 2019, at 09:47, Robert Sparks via Datatracker wrote:
> Neither the document nor the shepherds write-up acknowledge or explain the
> replacement of RFC6838 with RFC3986 for a reference for specifying fragment
> identifier syntax and semantics (hence dropping the reference to 6838). It
> would be nice to have something captured in the record that supports/explains
> this change.

I did notice this change in my review, but didn't consider it to be 
significant.  The shift in focus is within the bounds of what I consider 
editorial discretion as the effect is identical.

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

Re: [Gen-art] Genart last call review of draft-ietf-httpbis-encryption-encoding-08

[Martin Thomson]

Thanks Pete,

On 6 April 2017 at 15:52, Pete Resnick  wrote:
>   A "keyid" parameter SHOULD be a UTF-8
>   [RFC3629] encoded string, particularly where the identifier
> might
>   need to appear in a textual form.
>
> I presume that simply means "might need to be rendered" and does not
> include "might need to be typed in by someone", correct? The former is
> easy; the latter probably requires a bit more text.

Indeed.  Until we have a good copy-and-paste version of the Unicode
typed/spoken/interpretive-danced input problem for security
identifiers, it is not a goal to have specifications casually tackling
problems that are outside their (and maybe anyone's) capabilities.

I made the suggested change in the editor's copy.

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

Re: [Gen-art] Gen-ART review ofdraft-ietf-rtcweb-alpn-03

[Martin Thomson]

Hi Russ, sorry for missing this.  I have a pull request open against
my spec with the changes I've made.

https://github.com/martinthomson/drafts/pull/31

On 19 April 2016 at 05:35, Russ Housley  wrote:

> Minor Concerns:
>
> I think it would really help
> the reader to say at the beginning something like: "The confidentiality
> protections ensure that media is protected from other applications, but
> the confidentiality protections do not extend to traffic on the data
> channels."

Yes, this is a good change.  I have adopted it.

> I understand why authentication and confidentiality are often used
> together.  However, it is very unclear to me why there ought to be a
> linkage between c-webrtc and authentication since this service really
> is only a promise to not share media with other applications.

I've trimmed down the text on authentication.  You are right that it
basically doesn't matter here.

> After reading the whole document, I went back and read the Abstract
> again.  I do not think it captures the real intent of the document.

I've taken a variation on your text.  I think that it's a better framing.

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

Re: [Gen-art] Gen-ART review of draft-ietf-httpbis-tunnel-protocol-04

[Martin Thomson]

I apologize for missing this, it was badly filed.  Thanks for the
comments.  Fresh eyes are always helpful here, and you identified lots
of little pieces of potentially confusing text.

The changes will be in -05, but you can preview them on github:
https://httpwg.github.io/http-extensions/tunnel-protocol.html

On 22 May 2015 at 01:26, Christer Holmberg
 wrote:
> ALPN = "ALPN":" protocol-id *(COMMA protocol-id)

Julian has corrected this also.  The production that is used is
described in RFC 7230, as referenced immediately before the rule.

> Are proxies prevented from implementing any tunneled protocol? If not,
> should the text say “Proxies might not implement the tunneled protocol”?

They aren't really proxies when they implement the tunneled protocol,
are they?  That's them taking off their proxy hat and putting on a
 server hat (or maybe their MitM hat).


> Do you need both sentences, or could they be combined into a single
> sentence?

Good point.  It was a little redundant:
https://github.com/httpwg/http-extensions/commit/fb18ad4

> “For a tunnel that is then secured using TLS [RFC5246], the header field

> I think it would be useful to add a reference to RFC 7301 after TLS
> handshake:
>   “…be carried within the TLS handshake [RFC7301].”

https://github.com/httpwg/http-extensions/commit/970b37f36

> What if TLS is NOT used?

No problem.  Application protocols can still have an identifier.  Note
that we say "Other substrates could negotiate the application protocol
differently." and also, later, have a whole section on the subject:
https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-04#section-2.3

> Who makes the choice of application protocol then?

That is not known.  The ALPN identifiers - if the proxy understands
them - will probably have to include a definition that covers how the
protocol is negotiated.  All the current ones do.

> What if the recipient does not support, or does not want to use, the
> protocol(s) indicated by the client?

That's a little piece of necessary uncertainty.  Just as the proxy
cannot rely on this header field being present, it cannot rely on the
two peers actually negotiating the indicated protocol.  It can check,
but TLS is (or will be) designed to make that hard.

> The text says that the ALPN header field will contain the protocol that will
> be used within the tunnel.
>
> I think “will” is wrong wording, as the recipient has the final saying on
> what will be used. Later in the document the text says “intended to be
> used”, and I think that would fit here too.

You are right:
https://github.com/httpwg/http-extensions/commit/1bbe0aa4504

> “For a CONNECT tunnel that conveys a TLS session that in turn
>   encapsulates another protocol,…”
>
> The text is confusing. Shouldn’t it simply say “A tunnel that is secured
> using TLS”, or something?

Yeah, it's a little overwrought.  How about:
For a CONNECT tunnel that conveys a protocol secured with TLS
https://github.com/httpwg/http-extensions/commit/3e470d644

> “When used in the ALPN header field, the ALPN identifier and registry
>   are used…”
>
> What is meant by “registry” here?

Yeah, that's a little confusing.
How about: "When used in the ALPN header field, an ALPN identifier is used ..."
https://github.com/httpwg/http-extensions/commit/cdf620a

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

Re: [Gen-art] [radext] Gen-ART review of draft-ietf-radext-dynamic-discovery-13

[Martin Thomson]

Thanks.  I think that you have everything in hand.  I'm happy with the
promised changes.

On 23 March 2015 at 01:16, Stefan Winter  wrote:
> Diameter defines its own S-NAPTR tags in its own RFCs

Ack.

>> S2.1.1.2 uses SHOULD to recommend that clients retry with their other
>> certificates.  I'd recommend use of MAY here, unless you would like to
>> expand on why this a SHOULD is valuable.
>
> Well... realm discovery is triggered typically by an end user trying to
> authenticate. If a client has a certificate but doesn't want to show it,
> this becomes an avoidable DoS for the user. Also, if the client doesn't
> always try the certificates in the same order, the connection setup also
> becomes indeterministic - sometimes it works, sometimes not.
>
> The clause makes a case for "don't give up prematurely" and makes the
> behaviour deterministic.
>
> So, I believe a SHOULD is the right thing to ask for here - would you
> prefer an updated draft with this reasoning included, or are the
> explanations in this mail sufficient?

I think that mentioning the consequences would be wise.  The
incentives are certainly properly aligned.  (I do worry about the
inordinate number of protocol steps this is going to introduce, but I
guess that is the point of the experiment.)

>> S2.1.1.3.3. I know that this is experimental and all, but this seems a
>> little too hand-wavy even for that.  I think that this is the right
>> design, but the section could be a little more confident (and precise)
>> in the description of how this works.  It took me a couple of goes to
>> understand how this was intended to work.  One important realization
>> was that a common root for the realm needs to be configured.  I'd like
>> to see this section expanded slightly (my initial inclination would
>> have been toward removal, but the content is in line with the
>> experiment, so it's probably valuable).
>
> Oh, it's totally handwavy, agreed :-) The mechanism described here is
> not implemented anywhere, and DANE in general only deals with the
> server-side auth, leaving a gaping hole on the question how to validate
> client certs. So, it really is just a sketch - that's why I used that
> word in the text.
>
> Actually I find that approach rather elegant, but it would take people
> with a lot of energy to pick it up, complete the DANE specs for
> client-side auth, implement TLS libraries that can do this, and to
> actually deploy it.
>
> I'm not sure I know how to handle your comment text-wise... when it
> comes to the need of a common root, I would have hoped that there is
> already text making it clear, i.e.:
>
> "if
>DANE/TLSA records of all authorized servers are put into a DNSSEC
>zone with a common, consortium-specific branch of the DNS tree, then
>the entity executing the algorithm can retrieve TLSA Resource Records
>(TLSA RR) for the label "realm.commonroot" [...]"
>
> If you can suggest specific text that helps readers understand this
> easier, I'm all ears...

Much of the rest of the document is more precise about the steps
involved.  I got the sense that the DANE text was rushed or cursory.
I'd rather see a more precise description of the steps that a client
would use; or the text could be removed; or the text could be reduced
to something even more vague ("You could use TLSA records for this.")

> Actually, even if DNS is trustworthy, the authorisation needs to be
> checked. It's more like:
>
> (new)
> "Regardless whether the results from DNS discovery are trustworthy or
> not (e.g. DNSSEC in use), it is always important to verify that the
> server which was contacted is authorized to service requests for the
> user which triggered the discovery process."

WFM

> (What I planned to say there was that if DNS without SEC is used, not
> only the authorisation is in question and needs to be checked, but also
> the discovered IP/port; but that's not totally important in itself
> because the authorisation check comes unconditionally and covers both
> anyway)

Right.

>> S 3.4.3 doesn't cover how to handle NAPTR records with flags set to
>> "a", though other parts of the document describe that.  I think there
>> is some refactoring of the dependency on the S-NAPTR algorithm, and an
>> allowance for a default port.
>
> That's already done in step 9, which basically hands off further
> resolution to S-NAPTR by stating: "For the extracted NAPTRs, perform
> successive resolution as defined in [RFC3958], section 2.2."
>
> If anything, poiting to section 2.2 is maybe too specific, because many
> parts of RFC3958 are about "s" and "a" NAPTR entries; do you think it
> makes the document more readable if I remove the "section 2.2" ?

No, that's fine.  I was just concerned about the port part; I see that
it is there, but it's fairly obtuse.  (My reaction is partly in error:
I was relying on my memory of 3958 a little too much.)

[...]

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ie

[Gen-art] Gen-ART review of draft-ietf-radext-dynamic-discovery-13

[Martin Thomson]

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-radext-dynamic-discovery-13
Reviewer: Martin Thomson
Review Date: 2015-03-21
IETF LC End Date: 2015-03-20
IESG Telechat date: 2015-04-19

Summary: This document is of a quality I rarely see even for proposed
standard.  It is certainly fit for publication as an experimental RFC.
(In case it isn't clear, I agree with the decision to choose
experimental here, this is in a tricky area and deployment experience
will validate choices.)

Major issues: None

Minor issues:

S-NAPTR tags for RADIUS are defined, but none for Diameter.  I'm sure
this was considered, but it seems odd on first reading.

S2.1.1.2 uses SHOULD to recommend that clients retry with their other
certificates.  I'd recommend use of MAY here, unless you would like to
expand on why this a SHOULD is valuable.

S2.1.1.3.3. I know that this is experimental and all, but this seems a
little too hand-wavy even for that.  I think that this is the right
design, but the section could be a little more confident (and precise)
in the description of how this works.  It took me a couple of goes to
understand how this was intended to work.  One important realization
was that a common root for the realm needs to be configured.  I'd like
to see this section expanded slightly (my initial inclination would
have been toward removal, but the content is in line with the
experiment, so it's probably valuable).

S2.2 says:
   Since the Domain Name System is not
   necessarily trustworthy (e.g. if DNSSEC is not deployed for the
   queried domain name), it is important to verify that the server which
   was contacted is authorized to service requests for the user which
   triggered the discovery process.

This implies that DNS integrity is the only reason for authentication.
To paraphrase Steve Bellovin: you hand your packets to the attacker to
deliver.

Also:
   It MAY substitute labels on the leftmost dot-
   separated part of the NAI with the single character "*" to indicate a
   wildcard match for "all labels in this part".
Use the singular form here to avoid confusion:
  It MAY substitute the leftmost dot-
   separated label of the NAI with the single character "*" to indicate a
   wildcard match for "all labels in this part".

S3.4.1 is the first mention of UTF-8 realms, which are not permitted
by RFC 4282.  This was a point of confusion for me.  I note that the
new nai draft permits UTF-8 realms.  Please just cite that and remove
the reference to 4282.

S 3.4.3 doesn't cover how to handle NAPTR records with flags set to
"a", though other parts of the document describe that.  I think there
is some refactoring of the dependency on the S-NAPTR algorithm, and an
allowance for a default port.

Nits/editorial comments:

S1.3 Capital 'P' on first bullet
S2.1.1.1 Missing period on first note.
S2.1.1.2 Please provide a reference for "Effective TTL".
S2.1.1.3 s/PKS/PSK/ and "used for in the subsequent"
(S2.1.3 Please be consistent with the trailing period in DNS record entries)
2.1.3.c. "x-" ugh...RFC 6648
S.3.4.4 "If these
   TTLs are very low, thrashing of connections becomes possible; the
   Effective TTL mitigates that risk." - isn't this the MIN_EFF_TTL instead?
S3.4.4 the last MAY here can be a SHOULD, I think
S5 "the result O can not be trusted" -> "the result of the discovery
process can not be trusted"

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

Re: [Gen-art] A *new* batch of IETF LC reviews - 2015-03-12

[Martin Thomson]

On 12 March 2015 at 15:27, A. Jean Mahoney  wrote:
> Martin Thomson2015-03-20   draft-ietf-radext-dynamic-discovery-13

I'll try, but that time frame is a little tight.

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

Re: [Gen-art] genART review of draft-ietf-cdni-logging-15

[Martin Thomson]

That looks fine.

On 10 March 2015 at 02:41, Francois Le Faucheur (flefauch)
 wrote:
...

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

Re: [Gen-art] genART review of draft-ietf-cdni-logging-15

[Martin Thomson]

On 9 March 2015 at 10:13, Francois Le Faucheur (flefauch)
 wrote:
> Hi Martin,
>
> Getting onto you first batch of comments:
>
>>
>> Summary:
>>
>> Major issues:
>>
>> Minor issues:
>>
>> S3.1 needs to define the basic atom that is used for the logging file.
>> It appears as though the atom is an octet.
>
> We have the following statement:
> " A CDNI Logging File MUST contain a sequence of lines containing US-
>ASCII characters [CHAR_SET] terminated by CRLF.”
> I see that as defining the atom as an ASCII character.

I'd prefer it be explicit near the ABNF definitions.

>> S3.2 uses the wildcard ABNF rule (i.e., ) too aggressively.
>
> Can you give me the specifics (unless this refers to what you've expanded 
> below already)

Using <> says to a generic processor : ignore everything that follows.
It breaks automatic validation.  It's a cop-out that you don't need.
You know what letters you want to permit, so build a rule for it.

That does mean that you need to consider whether you want to permit
the ASCII BELL (or BEL) character, but I think that you already have
an answer ready-to-hand.

>> RECLINE (a potentially confusing name) could be more strictly defined.
>
> potentially confusing, but hopefully not really given the consistent 
> structure across DIRLINE/DIRGROUP/RECLINE/RECGROUP.
>
>>
>> = 1*
>>
>> ... is not valid and could be:
>>
>>CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)
>
> I have changed it to :
> "
> CDNI Logging File = 1*
> "

Again, <> is not appropriate here, it puts what you have inside it
down as comments, not actionable BNF.  Also, that name is not valid
ABNF.

> This is to avoid defining an extra name (CDNI-LOG-FILE) and have to explain 
> that CDNI-LOG-FILE is actually the CDNI Logging File.
> Let me know if that is not valid.
>
>>
>> That implies that an empty file is not valid.  I'd have thought that *
>> rather than 1* would be better.
>
> A logging file with no Logging Records is considered valid and allowed, but a 
> logging file without any directive is not considered valid.
> This is consistent with the text that I added based on our previous 
> discussion stating that “occurrences” for all directives need to be respected 
> (in other words, some directives are mandatory).

I think that you could express that better than you have.

LoggingFile = 1*(1*DIRGROUP *RECGROUP)

Might work.

>> S3.3 again uses wildcard rules too aggressively.  DIRNAME (not the
>> unix command) should be defined more explicitly, even if it is just to
>> specify what characters are allowed.  Use text to further constrain
>> it.  As it stands, a generic processor cannot know that the name
>> doesn't permit the inclusion of (for instance) ":" or CRLF.  A common
>> method is to define something like this as:
>>
>>DIRNAME = Version-directive / UUID-directive / ... / extension-directive
>>
>> More commonly, go up a level and define directive using the choice.
>> That way, each directive can define a name and value together using
>> ABNF.  e.g.
>>
>>Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT
>>
>
> I’ll park these ABNF comments since I got many others and will handle them 
> together.
>
>
>> I wouldn't be so prescriptive about the version format.  Unless there
>> are specific semantics you want to extract from each digit.
>
> Fair enough. I have relaxed it and simply made the format NHTABSTRING.
>
> In the corresponding IANA section for the Version registry, I have added:
> “
> Within the registry, Version values are to be allocated by IANA
>according to the "Specification Required" policy specified in
>[RFC5226].  Version values are to be allocated by IANA with a format
>of NAMEFORMAT (see Section 3.1).  Version values corresponding to
>specifications produced by the IETF CDNI Working Group are to be
>allocated a name starting with "CDNI".  All other Version values are
>to be allocated a name that does not start with "CDNI”.
> “

Creating carve-outs in registries like that is inadvisable.  Someone
might attach semantics to them and then you get into trouble.  See the
RFC on x-.


> I have kept CDNI/1.0 as the value allocated by this document.
>
>
>>
>> What is a receiver expected to do if the version *isn't* CDNI/1.0 ?
>> Discard the entire file?  That doesn't seem like a good way to ensure
>> forward compatibility.
>
> This has been discussed and fixed already.
>
>
>>
>> UUID: this a Universally Unique IDentifier (UUID)
>> from the UUID Uniform Resource Name (URN) namespace specified
>> in [RFC4122]) for the CDNI Logging File.
>>
>> I don't know how to apply this.  Is it the UUID portion of the URN or a URN?
>
> Good point.
>
> Text has been modified to:
> “
> this a Uniform Resource Name (URN) from the
>  Universally Unique IDentifier (UUID) URN namespace specified in
>  [RFC4122]).  The UUID contained in the URN uniquely identifies
>  the CDNI Logging File.
> "
>
>
>>
>> Please don't use MUST here: 

Re: [Gen-art] genART review of draft-ietf-cdni-logging-15

[Martin Thomson]

Gotta run, but I hope these responses help.

On 9 March 2015 at 10:13, Francois Le Faucheur (flefauch)
 wrote:
> Hi Martin,
>
> Getting onto you first batch of comments:
>
>>
>> Summary:
>>
>> Major issues:
>>
>> Minor issues:
>>
>> S3.1 needs to define the basic atom that is used for the logging file.
>> It appears as though the atom is an octet.
>
> We have the following statement:
> " A CDNI Logging File MUST contain a sequence of lines containing US-
>ASCII characters [CHAR_SET] terminated by CRLF.”
> I see that as defining the atom as an ASCII character.

I'd prefer it be explicit near the ABNF definitions.

>> S3.2 uses the wildcard ABNF rule (i.e., ) too aggressively.
>
> Can you give me the specifics (unless this refers to what you've expanded 
> below already)

Using <> says to a generic processor : ignore everything that follows.
It breaks automatic validation.  It's a cop-out that you don't need.
You know what letters you want to permit, so build a rule for it.

That does mean that you need to consider whether you want to permit
the ASCII BELL (or BEL) character, but I think that you already have
an answer ready-to-hand.

>> RECLINE (a potentially confusing name) could be more strictly defined.
>
> potentially confusing, but hopefully not really given the consistent 
> structure across DIRLINE/DIRGROUP/RECLINE/RECGROUP.
>
>>
>> = 1*
>>
>> ... is not valid and could be:
>>
>>CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)
>
> I have changed it to :
> "
> CDNI Logging File = 1*
> "

Again, <> is not appropriate here, it puts what you have inside it
down as comments, not actionable BNF.  Also, that name is not valid
ABNF.

> This is to avoid defining an extra name (CDNI-LOG-FILE) and have to explain 
> that CDNI-LOG-FILE is actually the CDNI Logging File.
> Let me know if that is not valid.
>
>>
>> That implies that an empty file is not valid.  I'd have thought that *
>> rather than 1* would be better.
>
> A logging file with no Logging Records is considered valid and allowed, but a 
> logging file without any directive is not considered valid.
> This is consistent with the text that I added based on our previous 
> discussion stating that “occurrences” for all directives need to be respected 
> (in other words, some directives are mandatory).

I think that you could express that better than you have.

LoggingFile = 1*(1*DIRGROUP *RECGROUP)

Might work.

>> S3.3 again uses wildcard rules too aggressively.  DIRNAME (not the
>> unix command) should be defined more explicitly, even if it is just to
>> specify what characters are allowed.  Use text to further constrain
>> it.  As it stands, a generic processor cannot know that the name
>> doesn't permit the inclusion of (for instance) ":" or CRLF.  A common
>> method is to define something like this as:
>>
>>DIRNAME = Version-directive / UUID-directive / ... / extension-directive
>>
>> More commonly, go up a level and define directive using the choice.
>> That way, each directive can define a name and value together using
>> ABNF.  e.g.
>>
>>Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT
>>
>
> I’ll park these ABNF comments since I got many others and will handle them 
> together.
>
>
>> I wouldn't be so prescriptive about the version format.  Unless there
>> are specific semantics you want to extract from each digit.
>
> Fair enough. I have relaxed it and simply made the format NHTABSTRING.
>
> In the corresponding IANA section for the Version registry, I have added:
> “
> Within the registry, Version values are to be allocated by IANA
>according to the "Specification Required" policy specified in
>[RFC5226].  Version values are to be allocated by IANA with a format
>of NAMEFORMAT (see Section 3.1).  Version values corresponding to
>specifications produced by the IETF CDNI Working Group are to be
>allocated a name starting with "CDNI".  All other Version values are
>to be allocated a name that does not start with "CDNI”.
> “

Creating carve-outs in registries like that is inadvisable.  Someone
might attach semantics to them and then you get into trouble.  See the
RFC on x-.


> I have kept CDNI/1.0 as the value allocated by this document.
>
>
>>
>> What is a receiver expected to do if the version *isn't* CDNI/1.0 ?
>> Discard the entire file?  That doesn't seem like a good way to ensure
>> forward compatibility.
>
> This has been discussed and fixed already.
>
>
>>
>> UUID: this a Universally Unique IDentifier (UUID)
>> from the UUID Uniform Resource Name (URN) namespace specified
>> in [RFC4122]) for the CDNI Logging File.
>>
>> I don't know how to apply this.  Is it the UUID portion of the URN or a URN?
>
> Good point.
>
> Text has been modified to:
> “
> this a Uniform Resource Name (URN) from the
>  Universally Unique IDentifier (UUID) URN namespace specified in
>  [RFC4122]).  The UUID contained in the URN uniquely identifies
>  the CDNI Logging Fil

Re: [Gen-art] genART review of draft-ietf-cdni-logging-15

[Martin Thomson]

On 5 March 2015 at 07:21, Francois Le Faucheur (flefauch)
 wrote:
...
> I have added this at the end of S3.3:
>
> NEW:
> “
> An uCDN-side implementation of the CDNI Logging interface MUST reject a CDNI
> Logging File that does not comply with the occurences specified above for
> each and every directive. For example, an uCDN-side implementation of the
> CDNI Logging interface receiving a CDNI Logging file with zero occurence of
> the Version directive, or with two occurences of the Integrity-hash, SHOULD
> reject this CDNI Logging File.
> "

That SHOULD needs to be qualified somehow.  Why would an
implementation ignore the SHOULD and not reject the file?


> And also edited the end of S3.4 as per the following:
>
> OLD:
> "
>  An uCDN-side implementation of the CDNI Logging interface MUST be
>able to accept CDNI Logging Files with CDNI Logging Records of
>Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
>defined in Section 3.4.1 as long as the CDNI Logging Record and the
>CDNI Logging File are compliant with the present document.
> “
> NEW:
> “
>  An uCDN-side implementation of the CDNI Logging interface MUST be
>able to accept CDNI Logging Files with CDNI Logging Records of
>Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
>defined in Section 3.4.1 as long as the CDNI Logging Record and the
>CDNI Logging File are compliant with the present document.
>
> In case, an uCDN-side implementation of the CDNI Logging interface receives
> a CDNI Logging File with HTTP Request Logging Records that do not contain
> field values for exactly the set of field names actually listed in the
> preceding “Fields” directive, the implementation SHOULD reject those HTTP
> Request Logging Records, and SHOULD accept the other HTTP Request Logging
> Records .
> "

Again, SHOULD is weak without some support.

> NEW:
> “
> The entity transmitting a CDNI Logging File as per the present document MUST
> set the value to "CDNI/1.0”. In the future, other versions of CDNI Logging
> File might be specified; those would use a value different to "CDNI/1.0”
> allowing the entity receiving the CDNI Logging File to identify the
> corresponding version.
> "

This doesn't tell a receiver what to do with "CDNI/1.1".  It needs to do that.

> NEW:
> "
>  The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be
>followed.
> “

In this case, a SHOULD is OK, I suppose.

> S 3.4.1
>   o  cs():
> HTTP header fields, esp. in HTTP/2 can contain HTAB, even if that
> isn't permitted by the grammar.  You probably want to describe how
> that is handled.
>
>
> Since the value of the HTTP header is encoded as a “quoted string”
> (QSTRING), is it not OK to have a HTAB within the HTTP header value as long
> as it is properly bracketed by the Quotes?

Header field *names* aren't quoted.

My point was that even though this is a bug in the sender, you are
going to see these in the wild and they are going to screw up the
logging file.

> The document says that "client-side implementation of the CDNI Logging
> interface MAY pull, at its convenience, a CDNI Logging File “ using standard
> HTTP. Since range request is just a standard HTTP mechanism, the clien-side
> may use it if it sees fit.
> Do you feel it is worth specifically calling out that range requests can be
> used?
> No problem in doing that if you feel it is useful.

Nah, that's OK.

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

Re: [Gen-art] Gen-ART review of draft-iab-2870bis-01

[Martin Thomson]

On 4 March 2015 at 18:44, Jari Arkko  wrote:
> But back to your review. As you may have seen, I think -02 addresses this 
> issue. (By deleting the text, which I think also works.)

Indeed, I now have no concerns.

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

Re: [Gen-art] genART review of draft-ietf-cdni-logging-15

[Martin Thomson]

And because I hit send too soon, here's more...

I think that this is ready.  I have a couple of major concerns:

Major General 1.

However, I would like to see more consideration given to forward
compatibility.  There are a lot of normative statements regarding what
MUST be included in the file, but no actions described for a receiver.
That means that it is hard to establish expectations regarding file
format evolution.  If the file is rejected when the version isn't
"CDNI/1.0", then that makes changes to that field impossible (and the
specification of ABNF for it somewhat pointless).

Major Specific 2.

   An implementation of the CDNI Logging interface MUST support the
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ( [RFC5288]).

Please don't do that.  There are mandatory to implement cipher suites
in all the specs you cite and you don't need anything special here.  I
have no problem with recommending PFS suites, but you might be better
served there by citing the uta TLS usage draft:
https://tools.ietf.org/html/draft-ietf-uta-tls-bcp

S 3.4.1
   o  cs():
HTTP header fields, esp. in HTTP/2 can contain HTAB, even if that
isn't permitted by the grammar.  You probably want to describe how
that is handled.

Bottom of P33 (won't adding the established-origin directive
invalidate the MD5?  What do you expect to happen there?  (I see two
choices, it would help if you could even *hint* at what you would
prefer implementations to do).

Nit: HTTP/2 not HTTP/2.0

Question: There is no mention made of range requests, for which this
might be well suited, particularly if files get large.

I note the privacy considerations are pretty reasonable.  I'd be much
happier if IP anonymization were not optional though.



On 12 February 2015 at 12:02, Martin Thomson  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-cdni-logging-15
> Reviewer: Martin Thomson
> Review Date: 2015-02-12
> IETF LC End Date: 2015-02-18
> IESG Telechat date: (if known)
>
> Summary:
>
> Major issues:
>
> Minor issues:
>
> S3.1 needs to define the basic atom that is used for the logging file.
> It appears as though the atom is an octet.
>
> S3.2 uses the wildcard ABNF rule (i.e., ) too aggressively.
> RECLINE (a potentially confusing name) could be more strictly defined.
>
>  = 1*
>
> ... is not valid and could be:
>
> CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)
>
> That implies that an empty file is not valid.  I'd have thought that *
> rather than 1* would be better.
>
> S3.3 again uses wildcard rules too aggressively.  DIRNAME (not the
> unix command) should be defined more explicitly, even if it is just to
> specify what characters are allowed.  Use text to further constrain
> it.  As it stands, a generic processor cannot know that the name
> doesn't permit the inclusion of (for instance) ":" or CRLF.  A common
> method is to define something like this as:
>
> DIRNAME = Version-directive / UUID-directive / ... / extension-directive
>
> More commonly, go up a level and define directive using the choice.
> That way, each directive can define a name and value together using
> ABNF.  e.g.
>
> Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT
>
> I wouldn't be so prescriptive about the version format.  Unless there
> are specific semantics you want to extract from each digit.
>
> What is a receiver expected to do if the version *isn't* CDNI/1.0 ?
> Discard the entire file?  That doesn't seem like a good way to ensure
> forward compatibility.
>
> UUID: this a Universally Unique IDentifier (UUID)
>  from the UUID Uniform Resource Name (URN) namespace specified
>  in [RFC4122]) for the CDNI Logging File.
>
> I don't know how to apply this.  Is it the UUID portion of the URN or a URN?
>
> Please don't use MUST here: If the
>  two values are equal, then the received CDNI Logging File MUST
>  be considered non-corrupted.
>
> MD5 collisions are easy to manufacture.  I'd also drop the MUST from
> the following sentence.
>
> S3.4: more wildcards
>
> S3.4.1: I wouldn't worry about HTTP/2 being special here.  All that
> speculation is painful, especially since HTTP/2 will likely be
> published before this document.  Better to just cite it and avoid
> getting caught up in the details.
>
>
>
>
> Nits/editorial comments:
>
> There are lots of uses of lowercase &q

[Gen-art] genART review of draft-ietf-cdni-logging-15

[Martin Thomson]

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-cdni-logging-15
Reviewer: Martin Thomson
Review Date: 2015-02-12
IETF LC End Date: 2015-02-18
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

S3.1 needs to define the basic atom that is used for the logging file.
It appears as though the atom is an octet.

S3.2 uses the wildcard ABNF rule (i.e., ) too aggressively.
RECLINE (a potentially confusing name) could be more strictly defined.

 = 1*

... is not valid and could be:

CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)

That implies that an empty file is not valid.  I'd have thought that *
rather than 1* would be better.

S3.3 again uses wildcard rules too aggressively.  DIRNAME (not the
unix command) should be defined more explicitly, even if it is just to
specify what characters are allowed.  Use text to further constrain
it.  As it stands, a generic processor cannot know that the name
doesn't permit the inclusion of (for instance) ":" or CRLF.  A common
method is to define something like this as:

DIRNAME = Version-directive / UUID-directive / ... / extension-directive

More commonly, go up a level and define directive using the choice.
That way, each directive can define a name and value together using
ABNF.  e.g.

Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT

I wouldn't be so prescriptive about the version format.  Unless there
are specific semantics you want to extract from each digit.

What is a receiver expected to do if the version *isn't* CDNI/1.0 ?
Discard the entire file?  That doesn't seem like a good way to ensure
forward compatibility.

UUID: this a Universally Unique IDentifier (UUID)
 from the UUID Uniform Resource Name (URN) namespace specified
 in [RFC4122]) for the CDNI Logging File.

I don't know how to apply this.  Is it the UUID portion of the URN or a URN?

Please don't use MUST here: If the
 two values are equal, then the received CDNI Logging File MUST
 be considered non-corrupted.

MD5 collisions are easy to manufacture.  I'd also drop the MUST from
the following sentence.

S3.4: more wildcards

S3.4.1: I wouldn't worry about HTTP/2 being special here.  All that
speculation is painful, especially since HTTP/2 will likely be
published before this document.  Better to just cite it and avoid
getting caught up in the details.




Nits/editorial comments:

There are lots of uses of lowercase "may".

Page 6 has a few instances of missing hyphens in dCDN3/dCDN2 etc...
S6.2.1: chunck

S3.1 the DATE/TIME rules can/should reference RFC 3339

S3.3 using ":" HTAB as a separator makes it hard to construct these
files manually.

S3.4 use of "c:" in combination with the unordered list is confusing
when the prefix is actually "c-".  Maybe use the string "c-" quotes
and all to denote the prefix.

S3.4.1 citing RFC 7230 is sufficient for HTTP/1.1; and probably for
HTTP in general at this moment.

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

Re: [Gen-art] Gen-art last call review of draft-ietf-httpbis-http2-16

[Martin Thomson]

I've updated the pull request.  You can see the changes there.

Note that the reason I'm pushing back hard on text additions is that
it's hard to ensure that I've correctly maintained the intent of text
that has already been extensively reviewed.  Deletions are easier, but
only slightly.  If you feel strongly about anything I've not acted on,
feel free to raise it.

On 21 January 2015 at 09:36, Elwyn Davies  wrote:
> It's the WG's choice to limit transports to TCP : so be it.  I'd have liked
> to allow alternatives such as SCTP but that is a personal view.

The only reason we did so is that no one offered to do the work.

> How about adding "subject to limited constraints" to the Section 5 bullet.

The statement is still correct without it.

> I have done a bit of homework on this including having a look at
> draft-pironti-tls-length-hiding-01,
> so I hope I understand this a little better now.  Practically, I think it
> would be helpful to move the last paragraph of s6.1 and combine it with the
> second para that introduces the idea of padding, making the security
> implications more upfront.  I think I am correct in saying that padding
> would be pointless if not using TLS: I think it would be worth saying this
> in s6.1.

Sounds reasonable.

> I think an (informative) reference to draft-pironti-tls-length-hiding-01 in
> s10.7 would be useful - I think it covers the 'redundant padding could be
> counterproductive' story in the 2nd sentence and also the statements in the
> last para of s10.7.

I think that I would, if it weren't for the relative levels involved
here.  The idea here is to include a clear signal that padding isn't
necessarily easy and then leave it to implementers to learn that this
warning was perhaps a little strong.  Better that than a false sense
of security.

>> I don't think this is a problem.  Most proposals that have been
>> floated use a reciprocal SETTINGS frame to signal that the value was
>> understood.  The only failure mode there occurs when there is a
>> collision between two extensions that results in two conflicting views
>> of the setting semantics.  Of course, that is equally possible with a
>> rejection-based scheme.
>
> Sorry, but I don't understand your logic here.  Let me try again:
>
> If (say) the client asks for a SETTINGS value from some future extension
> that the server doesn't understand, my interpretation is that the server
> will ignore the value it doesn't understand while doing the ones that it
> does understand and say 'ACK' to the client. I assume that the client is
> then entitled to believe that the server has interpreted its requested
> SETTINGS as expected and the client can do whatever the extension was
> intended to allow.  Depending on what the ignored SETTINGS are, this may
> have bad consequences during later operations.
>
> Accordingly, I think that the SETTINGS extension needs some way to tell the
> requesting endpoint that the responding endpoint couldn't action (part of)
> its requests.  The requester can then act accordingly, terminating the
> session or avoiding actions that exploit whatever setting couldn't be
> actioned.

Let me try again.  The ACK only provides an indication that the
settings that were understood were acted upon.  It doesn't provide
proof-positive that an extension was understood.  Another mechanism is
required for that.  One potential solution is to include a value for
the same setting in a separate SETTINGS frame.

>>> s3.5, paras 2-5: It would be worth explaining that what is being done
>>> here
>>> is to send what would be a method request for the PRI method which will
>>> not
>>> be recognized by well-implemented HTTP/1.x servers.  The PRI method is
>>> then
>>> reserved for HTTP/1.1 so that it can't be accidentally implemented later
>>> (see Section 11.6).
>>
>> We've discussed providing explanatory text of this nature in the
>> working group on a few occasions, but avoided it.  In this case, the
>> main beneficiaries of that information are people who aren't reading
>> and implementing this specification, so we decided against more
>> verbiage to that effect.
>
> Well.. with my gen-art hat firmly in place, part of the object of RFCs is
> that they shouldn't be totally opaque to those who are reading them, even
> those who aren't actually experts implementing the protocol.  My suggestion
> for an explanation would help those.. I didn't immediately twig why the
> string was structured as it is.

The right place for this discussion is the working group list.  If you
feel strongly enough.  I'm trying very hard to avoid (re)opening
issues.

> <>
>>>
>>> s5.1, next to last para; s5.5, para 3, s6.2, END_HEADERS, para 2:
>>> s5.1 says:
>>> OLD:
>>> Frame of unknown types are ignored.
[...]
>> I have little concern that the feature
>> will be accidentally missed.
>
> Perhaps not but I spent some time worrying about the inconsistency so other
> may..
> can we compromise on:
> NEW:
> Frames of unknown types are ignored excep

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10

[Martin Thomson]

I definitely want to avoid making prescriptive statements about what to
protect, even couched as suggestions. However, I think that a more generic
statement that describes the characteristics of a header that might need
protection is definitely a good idea.

If Herve doesn't get there first, I can purpose text that concentrates on
the coincidence of secret and small/easy-to-guess..
On Jan 22, 2015 3:17 PM, "Jari Arkko"  wrote:

> Thanks for the response. I think this may slightly enhance the feeling
> that the list may not be needed.
>
> Jari
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10

[Martin Thomson]

On 20 January 2015 at 10:48, RUELLAN Herve  wrote:
> I did a few additional ones in:
> https://github.com/http2/http2-spec/pull/694

LGTM, I suggested a reword of one of the sentences.

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

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10

[Martin Thomson]

In the absence of answers from the editors, I can provide an
explanation for the choices you have identified as being issues.

I've also turned your comments into a pull request.

https://github.com/http2/http2-spec/pull/693

You can review that; but the editors will likely have some more to say
about this.

(Note: I dropped opsdir from this reply, there was no substance there.
I look forward to a review of HTTP/2 proper.)

On 12 January 2015 at 18:12, Black, David  wrote:
> The first major issue involves the dense packing of static and
> dynamic table indices, and what appears to be an inability to
> ever change this  and HPACK in general (if that's a "feature,"
> an explanation of why is in order).

That is entirely intentional.  The same question has been raised
several times, and the answer from the working group has been
consistent:

This compression scheme will not be the fastest, or give the best
compression ratios.  It will have those limitations, but it will be
easy to understand, implement and get correct and it will provide good
enough compression performance.

It will also be completely inflexible, but if that turns out to be a
problem, we will fix it in HTTP/3, even if that means that HTTP/3 is
almost entirely identical to HTTP/2.

A few people objected to this on the grounds that this flies in the
face of a body of accepted wisdom on extensibility in protocols.  But
that flexibility turns out to be contrary to the aforementioned goals.
Ultimately, this choice was very clearly and consistently the
consensus of the working group.

I'm going to propose the following text be added:

   The HPACK format is intentionally simple and inflexible.  Both
   characteristics reduce the risk of interoperability or security
   issues based by implementation error.  No extensibility mechanisms
   are defined; changes to the format are only possible by defining a
   complete replacement.

> The second major issue is that I can't find the list of fields
> that are required to use the never-indexed syntax for security
> reasons.

That list doesn't exist, because the need to avoid indexing is highly
contextual.  Like padding, I don't expect this feature to be widely
used, because it requires specific knowledge, but it is necessary to
avoid low-entropy secrets from being exposed to CRIME-like attacks.

I'll note that the combination of "low-entropy" and "secret"
immediately makes this a scenario into which only the very careful and
knowledgeable should venture.  But apparently some do and those few
(along with the paranoid) need the mechanism.  The rest of us can just
use more entropy on our secrets.

I can't confirm, but I think we're using it in Firefox for short
cookies (over which we have little control, but still wish to
protect).

[snip]
> Minor issues:
>
> -A- Section 1.3:
>
>Dynamic Table:  The dynamic table (see Section 2.3.2) is a header
>   table used to associate stored header fields to index values.
>   This table is dynamic and specific to an encoding or decoding
>   context.
>
> Need to define "header table" before using it in this definition, or
> point to the discussion of the term in Section 1.

Or you could not use "header table":

   Dynamic Table:  The dynamic table (see Section 2.3.2) is a table that
  associates stored header fields with index values.  This table is
  dynamic and specific to an encoding or decoding context.

> -B- Section 4.2
>
> This paragraph is unclear on what has to be communicated:
[snip]
> I suggest:
>
>Multiple updates to the maximum table size can occur between the
>sending of two header blocks.  In the case that this size
>is changed more than once in this interval, the smallest
>maximum table size that occurs in that interval MUST
>be sent in an encoding context update.  The final maximum size is
>always sent, resulting in at most two encoding context updates.  This
>ensures that the decoder is able to perform eviction based on
>reductions in decoder table size (see Section 4.3).

LGTM (I apologize, that was my text).

> -C- Section 4.4:
>
> This paragraph is unclear on whether eviction occurs before or after
> adding an entry:
>
>Whenever a new entry is to be added to the dynamic table, entries are
>evicted from the end of the dynamic table until the size of the
>dynamic table is less than or equal to (maximum size - new entry
>size), or until the table is empty.
>
> I suggest inserting "(before the new entry is added)" after
> "until the size of the dynamic table"

How about this instead:

s/Whenever a new entry is to be added.../Before a new entry is added.../

> -D- Section 4.4:
>
>If the representation of the added entry references the name of an
>entry in the dynamic table, the referenced name is cached prior to
>performing eviction to avoid having the name inadvertently evicted.
>
> Cached where and how?  Please explain.

I don't find this unclear, would "saved" cause less c

Re: [Gen-art] Gen-art last call review of draft-ietf-httpbis-http2-16

[Martin Thomson]

Thanks for the thorough review Elwyn.

I've made changes in the form of a proposed change set against the
editor's copy.

https://github.com/http2/http2-spec/pull/692

You can review the changes at that link.  Note that some of the typos
you caught were already fixed, or will be fixed in other proposed
change sets.

As is customary, I will await a sanity check and AD/shepherd approval
to merge the changes into the master copy.  I expect that to occur
after the IESG discuss approval.

Responses inline.

On 19 January 2015 at 02:37, Elwyn Davies  wrote:
> Summary:
> Almost ready.  A well written document with just a few nits really.  I am
> slightly surprised (having not been following httpbis in detail) that HTTP/2
> is so tightly wedded to TCP - this is doubtless pragmatic but it adds to the
> ossification of the Internet and makes me slightly suspicious that it is an
> attempt to really confirm HTTP/2 as the waist of the neo-Internet.  Can't we
> ever use any other transport?

I think that - overall - the desire for the timely replacement of
HTTP/1.1 was stronger than the desire to attain perfection.

And rather than ossifying, the general view is that ALPN clears a path
to more changes in the future.

If you want to talk about the waist of the neo-Internet, I think
identifying HTTP more generally is appropriate; we're only really
upgrading a small part of it.  And there are ongoing plans to continue
to upgrade the entire protocol.  But our relevance is only defined by
what we ship, and this is a significant improvement that isn't worth
holding back for years while we ponder more fundamental changes.

> A couple of minor issues: (1) I am not sure
> that I see the (security) value of the padding mechanisms specified, but I
> am not an expert so I will defer to the security experts, and (2) the
> extension method for SETTINGS seems to be flawed.  Apologies for the
> slightly delayed review.

I'll address those below.  And don't concern yourself with the delay,
it's not a small document.

> Major Issues:
> s3, para 1: Just checking: HTTP/2 is defined to run over TCP connections
> only.  I take it that this is something that the WG has formally decided
> upon.  Is there something that stops HTTP/2 running over any other reliable
> byte stream protocol with in-order delivery?  Could there be a more general
> statement?

Such a statement was debated at some length.  The current view (unless
I'm mistaken) was to recognize that HTTP/2 uses TCP.  More definitive
statements were avoided to ensure that if a future document chose to
define how HTTP/2 used some other transport that wouldn't be too
disruptive.

And who said it needed to have in-order delivery?

Referring to the cited section, the accepted view on ALPN tokens is
that they identify a particular application protocol profile; a new
protocol that layered something that was partially or substantially
like HTTP/2 over another transport would have a new identifier.

> Minor Issues:
> s4.3, next to last para; s5, bullet #1:
> (Just a bit more than a nit)
> s4.3 says:
>
> Header blocks MUST be
>transmitted as a contiguous sequence of frames, with no interleaved
>frames of any other type or from any other stream.
>
> s5 says:
>
>o  A single HTTP/2 connection can contain multiple concurrently open
>   streams, with either endpoint interleaving frames from multiple
>   streams.
>
> If s4.3 is correct (which multiple repetitions elsewhere indicate that it
> is) then the bullet in s5 needs to reflect the constraint in s4.3 as they
> are currently inconsistent.

Section 5 is summary information. I don't think that further
qualification is needed at this point; as you note, the constraint is
repeated frequently.

> I am not quite sure whether the last para of s4.3 implies that the client
> must wait until
> it has the whole header block before trying to decompress or whether
> decompression
> might happen as fragments are received - please clarify this in the text.

That's a clarification that belongs in the header compression
document.  It appears in Section 3.1 of that document.

> s6.1 and s6.2: I am dubious about the value of the padding story in DATA and
> HEADERS frames, even given the caveats in s10.7.  An attacker can use the
> header to deduce the padding section.  It seems a bit odd to say that you
> can add arbitrary padding and then insist it is all zeroes.  However, I am
> not an expert in this area and will defer to security experts.

Hard as it is to get right, padding here is important in some use
cases.  We've had a lot of separate requests for the feature.

The all zeros thing is safe if your cipher provides IND-CCA, and that
is table-stakes.

You are right though about the arbitrary thing, I've removed the word
"arbitrary".

> s6.5.3: If an endpoint sends a SETTINGS value that the receiving endpoint
> doesn't understand (for an extension, say), the receiver will ignore it but
> still send an ACK.  This leaves the sending endpoint 

[Gen-art] GenART review of draft-ietf-opsawg-coman-use-cases-03

[Martin Thomson]

 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-opsawg-coman-use-cases-03
Reviewer: Martin Thomson
Review Date: 2015-01-02
IETF LC End Date:
IESG Telechat date: (if known)

Summary: Ship it.

Nits/editorial comments:
I think that there are a few too many Unnecessarily Capitalized
Phrases.  Consider downcasing for statements like "Power, Energy,
Demand and Power Quality" or "It is assumed that Energy Management
will ".

s/100.000/100,000/

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

[Gen-art] Gen-ART review of draft-ietf-ospf-te-metric-extensions-09

[Martin Thomson]

 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-te-metric-extensions-09
Reviewer: Martin Thomson
Review Date: 2014-12-29
IETF LC End Date: 2014-12-24 (nice)
IESG Telechat date: 2015-01-08

Summary: Good for PS with some minor issues.

Observations:

I find it a little disappointing that measurement techniques are so
nebulously defined.  Values are measured over "a period" using "some
method, which might be RFC 6374".  The "A" bit threshold is "a
configured value".  That means that a consumer of this information has
to take a lot on faith.  I have to assume that this is because we
can't do better.

Minor issues:
Please ensure that all the field descriptions include some textual
indication of the size of the field.  Type and length are always 16
bits each, so those can be assumed from RFC 3630.

As above, please specify the specific IEEE 754 floating point format,
i.e., "single precision".  Otherwise you have to look at the figures
to work out how many bits to use for the value and figures should be
strictly informational.

Nits:
Section 10 is missing a period.

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

Re: [Gen-art] Gen-ART of draft-dukhovni-opportunistic-security-05

[Martin Thomson]

On 25 November 2014 at 07:59, Jari Arkko  wrote:
> I agree with many of these comments (were they observed?) but I also agree 
> with the part about “ship it” :-)

I have not seen a response.

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

[Gen-art] Gen-ART of draft-dukhovni-opportunistic-security-05

[Martin Thomson]

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-dukhovni-opportunistic-security-05
Reviewer: Martin Thomson
Review Date: 2014-10-31
IETF LC End Date: 2014-11-18
IESG Telechat date: (if known)

Summary: Ship it; it's more important to have this stake in the ground
than it is to have it right.

Major issues:

This is the first attempt at definition, which appears at the bottom of page 3:

   "Opportunistic Security" (OS) is defined as the use of cleartext as
   the baseline communication security policy, with encryption and
   authentication negotiated and applied to the communication when
   available.

So I can't start from an unauthenticated, encrypted baseline?  And I
can't opportunistically add other features (like length hiding)?  How
about:

"Opportunistic Security" (OS) is defined as a security policy that
adds security features - such as encryption or authentication - based
on availability, using negotiation to enable commonly supported
features.

(the next paragraph establishes that cleartext is the baseline anyway)


I still find the paragraph that starts "An OS protocol first
determines the capabilities of the peer with [...]" goes nowhere.
There's no "then" or "second".  It just wanders off.  This is a
crucial part of the definition.  (This also appears too far down in
the document, I'm inclined to suggest that this belongs in the newly
empty Section 1).

OLD:
   An OS protocol first determines the capabilities of the peer with
   which it is attempting to communicate.  Peer capabilities may be
   discovered by out-of-band or in-band means.  (Out-of-band mechanisms
   include the use of DANE records or cached keys or credentials
   acquired via TOFU.  In-band determination implies negotiation between
   peers.)  The capability determination phase may indicate that the
   peer supports authenticated, encrypted communication;
   unauthenticated, encrypted communication; or only cleartext
   communication.
NEW:
   An OS protocol enables security features based on the capabilities that
   can be learned about a communications peer.  This might use out of
   band information, or an in-band negotiation.  As capabilities are discovered,
   they are enabled.  Failure to enable any given feature is not considered
   cause to terminate communications, since each feature is enabled
   independently.

(then you can get into f'rexamples, like the whole auth+enc -
unauth+enc - clear continuum; the STARTTLS quagmire, a DANE example =
to cover opportunistic authentication.)


Minor issues: I'm not excited about writing this, because Victor has
made a genuine effort to engage, and I understand the pressures that
are being applied from multiple directions, but here goes

My original review noted a couple of structural issues:
 - the document had too many words
 - the definition of OS in S3 was obfuscated

Though some aspects of the draft are greatly improved, and arguably a
new definition is provided (see above), I suggest that these have not
been addressed.  I contributed text and specific editorial
suggestions[1] that would have drastically reduced the amount of text,
but those were apparently only sparingly sampled.

This is only a personal reaction, but the emphasis on DANE is perhaps
a little strong.  I suggested less of that last time (i.e., none); but
there is now more.

[1] 
https://github.com/martinthomson/saag/commit/63bf358d1101b06460350a6fc5068fdedb3ff6d3
[2] 
https://tools.ietf.org/rfcdiff?url2=draft-dukhovni-opportunistic-security-05.txt

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

Re: [Gen-art] Gen-ART review of draft-ietf-manet-ibs-03

[Martin Thomson]

On 29 October 2014 03:52, Dearlove, Christopher (UK)
 wrote:
> Any objection that something better can be done needs to provide that 
> something better, not just say "asymmetric, therefore something better".

That's a totally fair comment.  I was trying for expediency, since
that is fairly obvious to me.  Here's a rough sketch:

A has the same properties you describe: a secret that only it knows
(KSAK) and a paired public value (KPAK) that it can distribute.

X generates a secret (analogous to SSK) and passes a signature over
some material (optionally its identity, as you note above, plus the
paired public value) to A.  A provides X with a signature over the
both the public value and identity that X can subsequently use to
claim that identity to others with the KPAK (analogous to PVT).  X is
expected to keep that value secret also.

Then X can send message in the form (data || PVT || sig(SSK, data ||
PVT)), and Y can validate both sig and PVT to establish that this is
valid.

I'm not saying that this is strictly better.  It is more complex; RFC
6507 seems to cleverly roll the identity of X into the public key it
uses to sign.  But this has the property that private keys aren't
shared.  That means that you can implement this using an HSM that
enforces a strict containment for keys.  It also means that you can
establish a parallel bases for trust to the single authority.


I think that this highlights the reason we call out downrefs in the
process.  As a standalone information RFC, the abstract presentation
of RFC 6507 is perfectly innocuous.  But it's application to a
standards track effort does open questions about suitability.

You claim that this is an improvement over the status quo, and that is
quite clear.  The scheme prevents participants from impersonating each
other, which might not have been possible with a system based on a
shared symmetric key.  It does however, require that all trust is
placed in an authority.  I believe that we can do better.

Maybe the property I'm describing here not valuable in the deployment
context this is designed for and maybe this can be addressed by
establishing firm expectations about applicability.  Maybe a simple
applicability statement would suffice.  That is above my pay grade to
decide.  I'll defer to the IESG on this one.

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

Re: [Gen-art] Gen-ART review of draft-ietf-manet-ibs-03

[Martin Thomson]

On 28 October 2014 06:37, Dearlove, Christopher (UK)
 wrote:
> From my perspective, and with support shown in the WG, this is an option that 
> several people want. The need for a trusted authority is a minus point, but 
> acceptable by some users and should not be blocked because it is not ideal 
> for everyone. (The only other so far standardised options, based on shared 
> keys, also are not ideal for everyone.) If there were a method that retained 
> all of the advantages of this approach and removed the need to trust the 
> authority, that would be a different matter, but I do not believe such a 
> method is known. Note that this approach has at least one advantage Martin 
> had not picked up on.


I'm not sure that I'll be able to close on this quickly, since all I
have from Christopher's description is a distinct vibe of snake-oil,
which is very unfair and almost certainly hugely inaccurate.  I don't
believe for a minute that this is what we're talking about, so I must
be misunderstanding something.

As I understand the information flow, new nodes acquire a private key
from some trusted source, which is constructed in such a way that they
are able to make assertions about their identity (an IP address, if I
understand correctly) that will be accepted by other nodes who also
trust that authority.  I know just enough about crypto to know that
something like this might be possible, but it's outside of my direct
knowledge.

What I was thinking was that if you go to the trouble of using
asymmetric crypto, then you already have the pieces to build a system
that doesn't require sharing of private keying material between any
two parties.  Then trust can be disconnected from the authority to
some extent (you might trust X because of previous things X did,
whereas now, you don't know for certain that X is the same X because
the authority might have given the keys to a new X).

All that requires is that there is a two way exchange with the
authority rather than a one way exchange between the device and the
authority.  I freely admit that I don't understand whether there might
be some restrictions on the construction of the private key such that
it binds some additional information, maybe you can explain.  (Small
words, I'm not a cryptographer, I just use it.)

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

Re: [Gen-art] Gen-ART review of draft-ietf-manet-ibs-03

[Martin Thomson]

On 24 October 2014 11:17, Dearlove, Christopher (UK)
 wrote:
> I am also not aware of a solution that overcomes this problem without 
> introducing different limitations, so it is a question of tradeoffs. This is 
> one point in that tradeoff space. If anyone has a clearly superior solution 
> that both avoids the need to trust an authority, and without introducing 
> other limitations, then there are many of us in the ad hoc network community 
> (and elsewhere, as just one example, to improve on 6507) who would like to 
> see it. Note that all of the previously specified options (in RFC 7182) rely 
> on keys shared by all participants, which is clearly weaker in some regards 
> (but acceptable to many, hence also a valid option).

It's fairly obvious that any entity that is trusted to assert identity
can arbitrarily impersonate.  But PKIX doesn't require that end
entities share private keying material with certification authorities.

I'm not 100% clear on the architecture here, but I've inferred that
participating nodes receive a private key from the trusted authority
and a set of public keys for other trusted nodes.  This could work
equally well if the nodes were able to instead distribute their own
public key to the authority.

I'm OK with making revocation out of scope, but it's not particularly
prominent, and that decision is a major constraint on the operational
approach you need when deploying something like this.

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

[Gen-art] Gen-ART review of draft-ietf-manet-ibs-03

[Martin Thomson]

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-manet-ibs-03
Reviewer: Martin Thomson
Review Date: 2014-10-23
IETF LC End Date: 2014-10-27
IESG Telechat date: (if known)

Summary: Ready with questions.

The language is quite clear and precise.  I did find that
comprehension required a non-trivial amount of digging into other
documents, but nothing was particularly hard to find.

This has a downref to 6507 (I see this in the shepherd writeup).

Questions:
The security considerations notes that the trusted authority has
access to private keys.  That would seem to defeat much of the benefit
of using asymmetric crypto here.  Why is this considered acceptable in
this context?  (I'd have thought it to be unacceptable in any context
when superior alternatives exist.)

The document mentions revocation, but does not seem to specify
anything.  If that is intentional, shouldn't the draft be more forward
about that?  (I only skimmed 6507 and the other docs, so I apologize
if I missed something.

Nits:
S4.1: duplicate "in in"

S5: It's probably not necessary to amend the reserved codepoints in
the registry: that rots quickly.

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

[Gen-art] GenART review of draft-ietf-l2vpn-evpn-10

[Martin Thomson]

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-evpn-10
Reviewer: Martin Thomson
Review Date: 2014-10-16
IETF LC End Date: past
IESG Telechat date: 2014-10-16

Summary: I found no major issues here, but I'm not able to give this
proper time to do this justice.  I have some comments, but these need
to be considered in context of the time I've spent on this.  I'm
guessing a week might be adequate, but that's time I don't have for
GenART.

Issues:

I found the overview in Section 4 to be very...wooly.  It launches
straight into alphabet soup, but didn't manage to identify what it was
that the document was trying to achieve, vs. what already exists.  It
certainly raises questions: is this document going to address the
issue of how MAC learning is populated on devices in networks attached
to CE?  Is it going to deal with (MAC) learning on the PE and CE
equipment?  What information does the CE really need at the MAC layer
to do its job?  The information provided is definitely not enough to
make sense of the remainder of the document.

Maybe that's just a shortcoming in my own education; this subject is
well outside of my field.

I also found the sudden introduction of a bag of protocol elements
without context very difficult to process.  So an ESI identifies an
EVPN?  What do I do with one?

In section 5, why is there not some sort of registry for the ESI Types
that are defined here?

Section 6:

   An Ethernet Tag ID is a 32-bit field containing either a 12-bit or a
   24-bit identifier that identifies a particular broadcast domain
   (e.g., a VLAN) in an EVPN Instance.

How do I distinguish one from t'other?

Nits:
Please check for expansion on first use for acronyms.  Maybe it's OK
to not expand LSP or MPLS, but I think that there are others that need
work.

Please provide references on first use of a new concept.  I have no
idea what a BGP NLRI is, and finding out is made more difficult by
this:

   This document defines a new BGP NLRI, called the EVPN NLRI.

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

Re: [Gen-art] Gen-ART review of draft-ietf-6lo-lowpan-mib-03

[Martin Thomson]

On 17 August 2014 23:09, Juergen Schoenwaelder
 wrote:
>
> can we get things unstuck with the following NEW text replacing the
> first paragraph in the security considerations section in -03? (I


WFM

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

Re: [Gen-art] Gen-ART review of draft-ietf-6lo-lowpan-mib-03

[Martin Thomson]

I was more concerned about the potential absence of content implied by the
trailing colon. I'm sure that you have it in hand.
On Aug 12, 2014 1:04 AM, "Juergen Schoenwaelder" <
j.schoenwael...@jacobs-university.de> wrote:

> Martin,
>
> thanks for the review. The first paragraph in the security
> considerations is following the security boilerplate for MIB modules
> that is posted here:
>
> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
>
> It seems I am actually missing this introductory paragraph:
>
>There are no management objects defined in this MIB module that have
>a MAX-ACCESS clause of read-write and/or read-create.  So, if this
>MIB module is implemented correctly, then there is no risk that an
>intruder can alter or create any management objects of this MIB
>module via direct SNMP SET operations.
>
> In general, I prefer to not change the boilerplate. Suggestions for
> boilerplate changes should be sent to the responsible AD (Benoit
> Claise) I think.
>
> /js
>
> On Mon, Aug 11, 2014 at 03:41:36PM -0700, Martin Thomson 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-6lo-lowpan-mib-03
> > Reviewer: Martin Thomson
> > Review Date: 2014-08-11
> > IETF LC End Date: 2014-06-22
> > IESG Telechat date: (if known)
> >
> > Summary: Ready.
> >
> > Nits/editorial comments:
> >
> > Looks like the first paragraph of the Security Considerations was left
> > hanging.  I looked and this sentence is a little confusing, since all
> > the MAX-ACCESS attributes are the same.
> >
> > I'm not sure that this is something that would concern me either.
> > Sure, SNMP provides an attacker a great feedback loop if they want to
> > learn what is going on, but that is something you trade off against
> > things like being able to do things like maintenance and all that
> > necessary stuff.
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-6lo-lowpan-mib-03

[Martin Thomson]

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-6lo-lowpan-mib-03
Reviewer: Martin Thomson
Review Date: 2014-08-11
IETF LC End Date: 2014-06-22
IESG Telechat date: (if known)

Summary: Ready.

Nits/editorial comments:

Looks like the first paragraph of the Security Considerations was left
hanging.  I looked and this sentence is a little confusing, since all
the MAX-ACCESS attributes are the same.

I'm not sure that this is something that would concern me either.
Sure, SNMP provides an attacker a great feedback loop if they want to
learn what is going on, but that is something you trade off against
things like being able to do things like maintenance and all that
necessary stuff.

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

Re: [Gen-art] Gen-ART review of draft-ietf-dime-app-design-guide-19

[Martin Thomson]

On 14 July 2014 10:44,   wrote:
> Part of your comments has already addressed into the latest version. Some are 
> still applicable. Please see below.
> Let me know if it is OK for you and I will produce a revision of the draft.

Sounds good.  Look to your sponsoring AD for guidance on when to post
a new revision.

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

Re: [Gen-art] [saag] Gen-ART review of draft-dukhovni-opportunistic-security-01

[Martin Thomson]

(Please keep the To/Cc; the responsible ADs/shepherds probably need to
see these emails. Add ietf@ if you feel you want the larger audience;
I figured saag was a large enough peanut gallery :)

On 10 July 2014 19:41, Viktor Dukhovni  wrote:
> On Thu, Jul 10, 2014 at 05:16:15PM -0700, Martin Thomson wrote:
>
>> Major issues:
>>
>> This misses one of the key principles behind opportunistic security:
>
> Strongly disagree.  Opportunistic security does not always downgrade
> to unauthenticated or unencrypted communication.  For example, with
> opportunistic use of DANE TLS, authentication is enforced for peers
> with usable TLSA records, while communication with other peers is
> unauthenticated or perhaps even unencrypted.
>
> So in fact, this draft specifically, and deliberately leaves the
> door open for MiTM-resistant authentication of peers for which some
> suitable mechanism (DANE, TOFU, ...) makes authentication possible.

Maybe I chose my words poorly, but I stand by the fact that this is an
important consideration in some designs.  More important than this
document implies.

>> Insistence on failure, as opposed to downgrade or some lesser level
>> of security - a characteristic of non-opportunistic security - elicits
>> responses from users to work around the problem (accept the bad
>> certificate, suppress certificate checking, etc...).
>
> For MTA-to-MTA SMTP there is no user to click OK.  Not all applications
> are web browsers.
>
>> The willingness
>> of an opportunistic security implementation to accept unvalidated
>> credentials means that it still benefits from resilience against
>> passive attack.  This is only really noted through an example of a
>> "design blunder".
>
> Opportunistic security is NOT a synonym for unauthenticated
> encryption.

I didn't suggest that it was, but it's an important feature of the
potential design space.  The document doesn't really describe any
other features that are this prominent.

>> The document skirts around it's key goal: defining OS.  Section 2
>> needs to start with a definition. The paragraph that follows the list
>> in S2 is a reasonable attempt at that and could be tweaked fairly
>> perform that function.
>
> The definition is a summary of the design principles.  We're defining
> an umbrella term for a family of protocols sharing a design
> philosophy.  It is helpful to set out the design principles first, and
> then state that OS protocols are those that adhere the design principles,
> and amplify the key points.

I stand by my comment, I think that with a title and subject matter as
is, you need to at least attempt to define the subject before
attempting to describe secondary things like design principles.

>> The Security Considerations is a response to an unstated argument, but
>> I think that the document needs to be clearer about what that argument
>> is, i.e.:
>>
>> The willingness of an OS implementation to downgrade can be
>> trivially exploited by an active attacker to strip an opportunistic
>> mechanisms.
>
> The Security Considerations section says that some protection is
> strictly better than no protection.  Thus it is often OK to accept
> some protection, even if some risks are left unmitigated.

Yes, but as I said, that statement is an answer to a question that is
only implied.  I think that the document would be better if it owned
up to the potential here.

>> Section 3 is unnecessary in its entirety:
>
> No terminology section required?  It is a subset of the Terminology
> from Steve Kent's draft.  If it is felt that all the requisite terms
> are adequately defined in-line, I am not opposed to its removal, for
> this draft less bloat is better.  It should be a succint definition.
>
>>   1. 2119 language isn't really appropriate for this document.  Many
>> of the statements that rely on this would be much better without that
>> language.  Some of the uses are actually completely inappropriate:
>> "When possible, opportunistic security SHOULD provide stronger
>> security on a peer-by-peer basis."
>
> I can downcase the "SHOULD", what is the objection to 2119?

That's not my point.  The point is that you aren't making normative
statements in this document, and nor should you.  2119 language isn't
needed.

For this specific sentence, you could use lowercase "should" and still
basically have an unsupportable statement.  stronger than what?  is
this a prediction?  I'm not sure what the right language is here, but
this reads much like the argument from the security considerations,
which is - to my mind - far more precise.

>>   2. I think that the description o

[Gen-art] Gen-ART review of draft-dukhovni-opportunistic-security-01

[Martin Thomson]

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-dukhovni-opportunistic-security-01
Reviewer: Martin Thomson
Review Date: 2014-07-08
IETF LC End Date: 2014-08-05
IESG Telechat date: (if known)

Summary: This reads a little like it was rushed.  This needs some work
before it can be considered ready.

(I've cc'd saag here.  That seemed appropriate, strip as you see fit.)


Major issues:

This misses one of the key principles behind opportunistic security:

  Insistence on failure, as opposed to downgrade or some lesser level
of security - a characteristic of non-opportunistic security - elicits
responses from users to work around the problem (accept the bad
certificate, suppress certificate checking, etc...).  The willingness
of an opportunistic security implementation to accept unvalidated
credentials means that it still benefits from resilience against
passive attack.  This is only really noted through an example of a
"design blunder".

In general, a more careful consideration of the document structure is needed.

The document skirts around it's key goal: defining OS.  Section 2
needs to start with a definition. The paragraph that follows the list
in S2 is a reasonable attempt at that and could be tweaked fairly
perform that function.

The Security Considerations is a response to an unstated argument, but
I think that the document needs to be clearer about what that argument
is, i.e.:

  The willingness of an OS implementation to downgrade can be
trivially exploited by an active attacker to strip an opportunistic
mechanisms.

The point that is made here is one that is most applicable in the
aggregate, something that is implied by "users" (in the plural form),
but should be explicit.


Minor issues:

Section 3 is unnecessary in its entirely:

  1. 2119 language isn't really appropriate for this document.  Many
of the statements that rely on this would be much better without that
language.  Some of the uses are actually completely inappropriate:
"When possible, opportunistic security SHOULD provide stronger
security on a peer-by-peer basis."

  2. I think that the description of "unauthenticated encryption" and
"TOFU" belong in the text proper.  TOFU is covered well enough by the
text in S1; unauthenticated encryption needs to be covered in the
description as a first class section, rather than piecemeal (see
above).  MitM and PFS are defined in RFC4949.


Nits/editorial comments:

References are double-bracketed "([ref])" and the "pervasive
monitoring (PM[RFC7258])" reference doesn't need the "PM".

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

Re: [Gen-art] Gen-ART review of draft-ietf-dime-app-design-guide-19

[Martin Thomson]

I just read through the diff of -24.  I'm assuming that my feedback
was lost somewhere.

On 14 September 2013 09:41, Jouni Korhonen  wrote:
> Martin,
>
> Thanks for the detailed review. I'll let the authors respond to these if they
> have further questions or clarifications to ask.
>
> - Jouni
>
>
>
> On Sep 14, 2013, at 3:13 AM, Martin Thomson  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-dime-app-design-guide-19
>> Reviewer: Martin Thomson
>> Review Date: 2013-09-13
>> IETF LC End Date: unknown, early review
>> IESG Telechat date: (if known)
>>
>> Summary: This document is ready, with some minor issues and nits.
>>
>> Minor issues:
>> I would find it a lot easier to read this document if it did as the
>> goals state (the first objective from the introduction) and clarify
>> what the extensibility rules in Diameter say with respect to each of
>> the described extensions.  It's not easy to glean this information
>> from RFC 6733, which makes reviewing this a little tricky.
>>
>> For instance, Section 4.1 doesn't really say what the expectations are
>> with respect to implementations that receive unknown or unsupported
>> commands.  I think that I could guess, but I'd rather not.  (I just
>> read the relevant parts of 6733, and it turns out that my guess was
>> wrong.)
>>
>> The same applies to Section 4.2, presumably through applying the same
>> principles.  The question here is: what would be the expected behavior
>> if a node was operating on the new application definition and that
>> node received a deleted command?  (The old implementation presumably
>> has no problem with the absence of the command if it's being removed.)
>>
>> The same applies to Section 5.
>>
>> Sections 4.4.2 and particularly 5.6 lead me to infer that the
>> extensibility for enumerated types is fundamentally broken, so maybe
>> those properties need to be expanded upon a little here too.
>>
>> The placement of the guidance in Section 5.6 seems fairly important
>> for Section 4, lest that important information be lost to someone just
>> looking to tweak a command.
>>
>> Section 4.3.1, perhaps add to the M-bit criteria: Would the presence
>> or value of the AVP alter the interpretation of the command (or any
>> other AVP) in any way?  (nit: s/AVPs/AVP on second bullet here.)
>>
>> I didn't find the list in  Section 6 particularly compelling.  It
>> seemed a little like motherhood statements.  The description of what
>> it was this was talking about: good; the description of how these
>> "often" (always?) manifest is also useful.  I wonder though whether
>> it's safe to generalize when you only see generic protocols extensions
>> as optional AVPs.  Perhaps you need to refocus on exactly that, and
>> leave the other forms of extension to speculation.
>>
>> Nits/editorial comments:
>> The last paragraph of Section 3 is confusing to me.  Firstly, the
>> subject of the reminder is missing from the first sentence.  I think
>> that the intent of that sentence is to say that extending by adding
>> applications or commands is to be avoided, but then subsequent
>> sentences make it clear that doing so is easy.  The last sentence
>> seems to be talking about something else entirely, which is the value
>> that IANA registries provide.  I am going to have to suggest that this
>> be reworded entirely.
>>
>> In Section 4.1, I'd like to see the note turned into real text.  The
>> size and complexity of an application seems to be a fairly significant
>> factor in determining whether a new application imports commands, or
>> whether separate applications are defined.
>>
>> I read the first bullet in Section 4.3.2 as a sentence, several times,
>> before realizing that it's a title.  Please reconsider the formatting
>> of this list.  At a very minimum, remove the period.
>>
>> --Martin
>>
>> p.s., I'm on vacation starting approximately ...now, since I'm out of
>> time for this review... so apologies for any slow responses to the
>> review.
>

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

Re: [Gen-art] Gen-ART review of draft-ietf-opsawg-large-flow-load-balancing-11

[Martin Thomson]

On 5 June 2014 20:29, Anoop Ghanwani  wrote:
> It is possible for a sophisticated attacker with knowledge of the details of
> large flow recognition algorithm (packet fields used and parameters of the
> algorithm) and the network topology to launch an attack in which sufficient
> traffic is generated so as to result in the flow being recognized as a large
> flow resulting the the installation of a PBR rule.  Subsequently, the
> attacker can generate traffic for other such flows resulting in consuming
> entries in the PBR table until the older, inactive flows are removed.

I had a little trouble parsing this, perhaps:

An attacker with knowledge of the large flow recognition algorithm and
any stateless distribution method can generate flows that are
distributed in a way that overloads a specific path.  This could be
used to cause the creation of PBR rules that exhaust the available
rule capacity on nodes.  If PBR rules are consequently discarded, this
could result in congestion on the attacker-selected path.
Alternatively, tracking large numbers of PBR rules could result in
performance degradation.

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

[Gen-art] Gen-ART review of draft-iab-2870bis-01

[Martin Thomson]

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-iab-2870bis-01
Reviewer: Martin Thomson
Review Date:
IETF LC End Date: 2014-06-20
IESG Telechat date: (if known)

Summary: Looks good.

Major issues: None

Minor issues:

This seems like a prohibition by omission:
  MAY also serve the root-servers.net zone, and the zone for the
  .arpa top-level domain [ARPAZONE],[RFC3172].
That is, it could be read to imply that root servers are prohibited
from serving other zones.  Why was this position taken rather than
simply noting that the root servers might serve other zones without
stipulating specifics?

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

Re: [Gen-art] Gen-ART review of draft-ietf-opsawg-large-flow-load-balancing-11

[Martin Thomson]

Inline...

On 6 May 2014 19:16, Anoop Ghanwani  wrote:
>> There's not a lot of discussion about the costs of maintaining an
>> exception list for rebalanced flows.  A hash-based distribution is
>> going to cost essentially zero state because the outbound path can be
>> determined on a per-packet basis, but as soon as you start
>> redistributing, there is an added state cost (and potential increase
>> in lookup times).  That probably needs some discussion.
>>
>
> We could probably add another subsection to Section 6 which discusses
> operational considerations.  Would the following address this concern?
>
> 6.3 Forwarding Resources
>
> Hash-based techniques used for load balancing with LAG/ECMP
> are usually stateless.  The mechanisms described in this document
> require additional resources in the forwarding plane of routers for creating
> PBR rules that are capable of overriding the forwarding decision from
> the hash-based approach.  These resources may limit the number of
> flows that can be rebalanced and may also impact the latency experienced
> by packets due to the additional lookups that are required.

Yep, that's perfect.

>> This plays into the security considerations, which I think need to
>> highlight this as a potential DoS vector.  Implementing automatic
>> redistribution on top of a hash-based stateless distribution is
>> vulnerable to attack if the hash function used is predictable.
>>
>
> Can you say something more about this attack?  Is it that an attacker
> would send large flows that map to the same link in order to consume
> resources in the PBR table?

That's exactly the concern.  Similar concerns arise in hash tables
that are predictable.  If an attacker wants to mount a DoS attack, one
vector they have open to them is to overload a single bucket, forcing
lookup times to increase from O(1) to O(N).  There's some research on
the matter, http://cr.yp.to/papers/surf.pdf for example.

> Yes, we have had issues with this when converting from Word and
> keep forgetting to adjust the .txt before submitting.

It's probably too late for this, but you might find this useful in
future: https://github.com/cabo/kramdown-rfc2629 (see it in action
here: https://github.com/tlswg/tls13-spec)

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

[Gen-art] Gen-ART review of draft-ietf-opsawg-large-flow-load-balancing-11

[Martin Thomson]

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-opsawg-large-flow-load-balancing-11
Reviewer: Martin Thomson
Review Date: 2014-04-24
IETF LC End Date: 2014-05-06
IESG Telechat date: (if known)

Summary: Basically ready.  Looks like a pretty straightforward, even
commonsense, coverage of the ways that flow distribution might be
achieved and a need for it identified.

Major issues: None

Minor issues: Or questions, really.

There's not a lot of discussion about the costs of maintaining an
exception list for rebalanced flows.  A hash-based distribution is
going to cost essentially zero state because the outbound path can be
determined on a per-packet basis, but as soon as you start
redistributing, there is an added state cost (and potential increase
in lookup times).  That probably needs some discussion.

This plays into the security considerations, which I think need to
highlight this as a potential DoS vector.  Implementing automatic
redistribution on top of a hash-based stateless distribution is
vulnerable to attack if the hash function used is predictable.

In Section 5.1 the recommended formula for determining imbalance puts
the average utilization on the divisor, which leads to large
variations in output when the overall utilization is low.  In that
state, it's probably best to avoid redistribution entirely, since no
single link is likely to be close to capacity.  I'd recommend a
simpler formula of max_i(|U_i - U_ave|).  (Note: You are missing an
ellipsis in the calculation of U_ave in the divisor part.)

Nits/editorial comments:

You don't rely on the definition of COTS, which I think is good.  It
can probably go.  There may be others.  I don't tend to check these
things.

Some diagrams have some alignment issues, see Figure 2.

I've never encountered a Fat-Tree before.  So the use of the name
actually hindered comprehension.  It's harmless, but probably
unnecessary.

Section 5.3 essentially includes a copy of Section 4.3.1.

The formulae in Section 5.6.1 are incomprehensible.  I assume that
there is a missing solidus '/' character on each.

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

Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

[Martin Thomson]

On 10 April 2014 07:15, Jari Arkko  wrote:
>>
>> A lot has happened since RFC 3455 was published.  The privacy considerations 
>> around the use of P-Access-Network-Info are unchanged from their pre-Geopriv 
>> form.  In particular, I find the UA knowledge part to be problematic; 
>> Geopriv definitions can probably help here.
>>
>> [RJ] sorry cannot do
>
> I think a better approach would be to describe the issues, rather than try to 
> change what the implementations do, if that is what you meant by using 
> Geopriv definitions.

Yes, a description of the issues would be appropriate.  I don't expect
to change anything here, but this is a very poorly understood
architecture with privacy properties that are challenging.  Making
those properties clearer is - I believe - entirely appropriate.
Geopriv [RFC6280] has tools that you can use - a framework of terms
and concepts - that should make this relatively easy to achieve.  It
shouldn't require more than a couple of paragraphs.

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

Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

[Martin Thomson]

On 9 April 2014 05:41, Jari Arkko  wrote:
> Have there been any responses or changes based on your comments? I do not see 
> the document version having changed...

I have seen no response or revision.

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

Re: [Gen-art] Partial Gen-ART review of draft-ietf-nfsv4-rfc3530bis-25

[Martin Thomson]

On 4 March 2014 20:10, Haynes, Tom  wrote:
> In reviewing the Gen-ART reviews of 3530bis, I realized I had not
> responded to your review. We had been very focused on S12.

I thank you for taking the time.  I honestly hope that I've helped in
some way to improve the document.

It's been too long since I did this for me to be able to respond
usefully to your comments, but it appears as though you have covered
most of the issues well.

Regarding snake oil, I re-read the new 1.3.3.3 and I think that the
minor additions you've made there help.  I think that my objection may
have been largely as a result of not having sufficient context to
understand in combination with what is a somewhat abstract
description.  I appreciate the expansion of the text, it's more
informative.

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

[Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

[Martin Thomson]

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-drage-sipping-rfc3455bis-13
Reviewer: Martin Thomson
Review Date: 2014-02-27
IETF LC End Date: 2014-03-14
IESG Telechat date: (if known)

Summary: I find it strange that this 3GPP document is being published
on the standards track.  But since it's a -bis there is clearly
precedent, and it is otherwise sound.

Major issues:

This document doesn't include enough information for me to some of the
headers.  For example, there isn't enough information in the document
to allow me to interpret the contents of cgi-3gpp:
  cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string)
(I pick on P-Access-Network-Info, because I'm somewhat familiar with it.)

This can probably be addressed by the inclusion of appropriate
normative references.  I seem to recall there being a 3GPP TS that
covered at least some of these.

Minor issues:

RFC 4244 is now obsolete, see 7044.  (related nit: Change log entry #2
seems quite defensive, unnecessarily so.  This document only needs to
define P-Called-Party-ID, and reference History-Info as an alternative
mechanism.)

Change log entry #5, mentions a shortcoming of 3455 (no registry for
access network types), but the draft does nothing about it.  It seems
to be propagating the mistake it notes.

A lot has happened since RFC 3455 was published.  The privacy
considerations around the use of P-Access-Network-Info are unchanged
from their pre-Geopriv form.  In particular, I find the UA knowledge
part to be problematic; Geopriv definitions can probably help here.

S6.1 P-Associated-URI is a powerful linkability vector, which could be
a far more serious privacy leak than the text implies.  The following
seems like good advice, but is not sufficient:

   An eavesdropper could possibly collect the list of identities a user
   is registered.  This can have privacy implications.  To mitigate this
   problem, this extension SHOULD only be used in a secured environment,
   where encryption of SIP messages is provided either end-to-end or
   hop-by-hop.

You also have to trust the other end of the hop with the information.
I think that's implicit, but probably needs to be stated.

S6.4  This claim sounds false to me:

   However, there
   are no security problems resulting from a UA inserting incorrect
   information.  Networks providing services based on the information
   carried in the P-Access-Network-Info header field will therefore need
   to trust the UA sending the information.  A rogue UA sending false
   access network information will do no more harm than to restrict the
   user from using certain services.

Any parameter whereby changing it can cause loss of service is likely
to be true in the inverse.  The draft makes no claims that would make
me believe otherwise.

Nits/editorial comments:

S1 Having the disclaimer as the first section is a little strange.  I
don't know what it is disclaiming yet.

S1, S3 It looks like a few characters are missing from these sections:
"trust.These", "environment The", "[RFC3455]   This"

The change log contains a lot of normative language.  I expected to
see pointers to changes, and maybe some justification, but items
include normative-sounding text and no pointers(7), other contain
pointers and duplicate text (3&4)

Change log #6 notes the removal of a field; given that this is
extensible, why not just mark the CDMA 2000 item deprecated instead of
removing it?

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

Re: [Gen-art] Gen-ART review of draft-ietf-alto-protocol-25

[Martin Thomson]

On 5 February 2014 05:01, Elwyn Davies  wrote:
> This is not really anything to do with me but I would point out that the
> Information Centric Networking folks would probably disagree with the
> view on "new data" that Martin expresses below - ICN would prefer that
> if the data is the same then it has a single way of naming it and any
> copy is as good as any other (and the recipient can check it).

It's always nice to conceptualize the next highest layer of
abstraction, but I find that when enacting anything, the lowest
abstraction layer that works is often best.

There's nothing wrong with the concept you describe.  But I haven't
found that the abstraction is as useful in practice as it is in
theory.

> As regards locations and URIs, the ni naming scheme (RFC 6920) for data
> objects is a URI scheme that specifically avoids incorporating locations
> in the components that uniquely identify the data whilst allowing a
> location to be added as a hint.

I didn't suggest ni, for two reasons: ni isn't widely used; and the
document already has an additional layer of indirection, my concern
was that the additional indirection was unnecessary, not that a
different form would be more appropriate.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-alto-protocol-25

[Martin Thomson]

On 27 January 2014 08:16, Wendy Roome  wrote:
> An “ALTO Server” is a collection of services provided by a provider. That
> provider may distribute these services over several different physical
> servers, and that distribution may change over time. If we used URIs to
> identify those services, the IDs would have to change whenever the provider
> redistributed services.

That might be considered a feature.  Let me try to explain.

What you are suggesting is a very common reaction to REST.  Stuff does
need to move, and it frequently does in practice.  But that doesn't
necessarily change the way that things are identified.

If it is more convenient for a provider to use a form of internal
identification, using a URI does not prevent this.  That happens all
the time.  The unique ID column in your SQL database frequently gets
mapped to some portion of a URI.

Moving can still happen, but it doesn't work quite how you are
thinking (I think).  You don't really move data, you make new data.
And the IRD helps your clients discover the new data.  For example, a
network map at https://a.example.com/map/12 is moved to a new location
at https://b.example.com/maps/primary/12.  The data might be the same,
but it is a different thing (caches will have to download a copy, even
if the content is the same).  Clients using cost maps will see a new
location upon which the cost map depends.

The key point here is that this doesn't require the use of mechanisms
that are duplicative of these existing functions.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-alto-protocol-25

[Martin Thomson]

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-alto-protocol-25
Reviewer: Martin Thomson
Review Date: 2014-01-25
IETF LC End Date: 2014-02-04
IESG Telechat date: ?

Summary:  This is a pretty damned good document and an impressive
achievement.  Don't let the number of issues I raise lead you to
conclude that it isn't.  It's huge and complex and does a decent job
of containing that complexity, even though at times it requires a deal
of back-and-forth to comprehend properly.  I don't think it should be
published until at least the major issues I raise have been addressed,
but those issues don't represent fundamental flaws.

Major Issues:

You can't use US ASCII encoding as you do; simply stating that the
value is a string would be better.  JSON is required to be
UTF-{8|16|32}, so mandating an alternative encoding could be a real
problem.  Same for most of the string-based types.  In most cases you
can simply s/US ASCII string/string/ safely.  This extends to the way
that specific characters are identified; this should use the U+
notation, rather than the 0x notation used.

Section 10.2 defines a resource ID.  Why do this when you could use
URIs?  After all, that's what URIs are for.  I realize that this would
be something of a major change to the protocol, but I think that the
question is particularly important.

Use of URIs has particularly benefits too.  For example, the "uses"
attribute of the IRD would be made far more easily navigable if URIs
were used.

It's unclear to me what value VersionTag (Section 10.3) has over URI +
ETag.  Section 10.3 doesn't really explain this at all, and the bulk
of the explanation is ad hoc at best.  I'll note that the way of
describing a dependency is quite roundabout and potentially
problematic.  Each resource that has a dependency has a name+tag for
each dependency.

The name is a name from an IRD, but this creates a uniqueness problem
if multiple IRDs reference the same IR.  This seems likely for cases
where adjunct services like the endpoint cost service rely on a common
network map.

On the other hand, if this were changed to URI + ETag, consistent with
my earlier recommendation, there would be no need for the extra
indirection and HTTP headers could carry version information for each
resource.  All that would be required is to identify dependencies
correctly.  Even better, a link relation.

I note also that vtag is used in filtered documents.  I think that
this is problematic because two differently filtered maps will have
the same ID, and - according to 11.3.1.6 - the same vtag.  That makes
it impossible to identify a filtered map.  Better to instead identify
each with their own URI (use Content-Location) and to separately
identify the complete map from the filtered one so that it can be made
clear that identifiers in each of the filtered maps is from the same
namespace.

Minor Issues:

I think that the document needs to be clearer with respect to how the
source and destination in a cost map are identified.  For example,
Section 6.1.2 specially calls out IP addresses as the basis for costs.
 However, the introduction to Section 6 states (though I may be
inferring this) that PID is the only basis.

Section 8.2 leaves quite a few questions unanswered.  For instance, is
'object' and 'object-map' the only reserved words?  How is Type2
actually defined as a string?  How might I define Type4 as an array?
I'm not expecting formal grammar or a rigorous definition, but the
definition is a wee bit sparse.

The MUST in Section 8.3.3 isn't really necessary.  Particularly when
it is so immediately contradicted.

Section 8.3.4.3 isn't exhaustive, obviously, but it does highlight
just two of the major fallback techniques:
 * ask another server
 * manage without the information (since it's basically advisory in
most use cases anyway)
The third option is to find an alternative way to obtain the desired
information, since the protocol provides redundancy at more than the
resource level.  For example, a complete cost map could be requested
if the endpoint cost service fails.  This would be suboptimal, but
probably better than managing without.

Section 8.3.7 seems odd.  At the server, it would be easier to require
that cookies not be set.  A client is likely going to use a general
purpose client for making requests, so cookies set by the server are
probably going to be returned as per spec.  In either case, forcing
cookies to be ignored is potentially restrictive on the server choices
(authentication springs to mind here) or requiring of special work on
the client.  Either requires greater justification than this document
provides.

In Section 8.4.1, why 

Re: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04

[Martin Thomson]

WFM

On 22 January 2014 23:22, Victor Kuarsingh  wrote:
> Martin,
>
> I am loading a new new version today, but here is that section (originally
> called "Motivation") for quick review.
>
> ** Beginning of section **
>
> Existing Network Considerations (new name of section)
>
> The selection of CGN may be made by an operator based on a number of
> factors. The overall driver to use CGN may be the depletion of IPv4 address
> pools which leaves little to no addresses for a growing IPv4 service or
> connection demand growth. IPv6 is considered the strategic answer for IPv4
> address depletion; however, the operator may independently decide that CGN
> is needed to supplement IPv6 and address their particular IPv4 service
> deployment needs.
>
> If the operator has chosen to deploy CGN, they should do this in a manner as
> not to negatively impact the existing IPv4 or IPv6 subscriber base. This
> will include solving a number of challenges since subscribers whose
> connections require translation will have network routing and flow needs
> which are different from legacy IPv4 connections.
>
> ** End of section **
>
> regards,
>
> Victor K
>
>
>
> On Wed, Jan 22, 2014 at 10:01 AM, Martin Thomson 
> wrote:
>>
>> On 22 January 2014 13:00, Benoit Claise  wrote:
>> > Is your concern that  the sentence "IPv6 is considered the strategic
>> > answer"
>> > in section 2 is not stressed enough?
>>
>>
>> I think that the text in the second paragraph is slightly more loaded.
>>  In particular,
>>
>>These issues
>>leave an operator in a precarious position which may lead to the
>>decision to deploy CGN.
>>
>> The rest of the section uses similarly loaded:
>>
>>The ability to replace IPv4-only equipment may be out of the control
>>of the operator, and even when it's in the administrative control, it
>>poses both cost and technical challenges as operators build out
>>massive programs for equipment retirement or upgrade.
>>
>> "precarious position", "poses both cost and technical challenges", ...
>> all arguably true, but not strictly neutral.
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04

[Martin Thomson]

On 22 January 2014 13:00, Benoit Claise  wrote:
> Is your concern that  the sentence "IPv6 is considered the strategic answer"
> in section 2 is not stressed enough?


I think that the text in the second paragraph is slightly more loaded.
 In particular,

   These issues
   leave an operator in a precarious position which may lead to the
   decision to deploy CGN.

The rest of the section uses similarly loaded:

   The ability to replace IPv4-only equipment may be out of the control
   of the operator, and even when it's in the administrative control, it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade.

"precarious position", "poses both cost and technical challenges", ...
all arguably true, but not strictly neutral.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04

[Martin Thomson]

On 15 January 2014 19:40, Victor Kuarsingh  wrote:
>> Which seems wise given their somewhat contentious nature.  But then
>> the entirely of Section 2 does exactly the opposite.  I don't know
>> what the right answer is here, but maybe the right thing to do is
>> delete Section 2.
>
>
> [VK]  The intention of this section was to explain that CGN may be used by
> operators and discuss some of the factors that may go (or have gone) into
> that decision.  The point in the abstract was intended to tell the reader
> that the authors were not suggesting that CGN was "good" or "needed".
>
> There are some important points that I think are important within the
> section (section 2), so perhaps if I/we can remove specific text that seems
> to given the impression that we are defending CGN, I can do so.

I'd like to understand what you think is important here.  Much of the
text explaining why CGN is used basically amounts to justification for
it.

In contrast, the list of requirements you provide is fairly neutral
and seems to cover most of the reasons well enough for me at least.

>> I'm not sure what "security measures" might be employed here:
>>
>>If a provider plans to operate the pre-translation realm (CPE towards
>>translator IPv4 zone) as a non-public like network, then additional
>>security measures may be needed to secure this environment.
>>
>> What might be secured in these scenarios?  Confidentiality?  Access to
>> network resources?  Perhaps this should talk about what a network
>> operator wants to secure: access to the network.  Then maybe talk
>> about access control and isolation.
>
>
> [VK]  The point here was that the document/authors have assumed the position
> that the CGN realm (within the context of this document) is that it's
> publicly accessible (to the extent that it can be behind a translation
> function.   The point was that if an operator wanted something more secure
> (which can be a number of thinks include items you listed like access
> to/from the Internet etc) that those would require mode consideration.
>
> We did not itemize those considerations as any list I generate would be
> somewhat arbitrary (should I select a few examples).  If you feel that such
> a partial listing is material, I can do so.  My concern here is that once we
> put in such a list, we may have to deal with conversations like "why did you
> not include such and such .. etc"
>
> The overall expectation is that the operator should expect the same level of
> exposure as traditional customers.

The problem with the text as it stands is that it is vague to the
point that it actively encourages the sorts of questions I raised.

If you want to avoid the questions, maybe consider whether the
sentence is even needed.

>> In Section 4, this seems a little vague:
>>
>>Various redundancy models
>>can be used within this architecture to support failover from one
>>physical CGN hardware instance to another.
>>
>> I don't expect an enumeration of the options, but this seems important
>> enough to at least point to where the redundancy options might exist?
>> Redundant "VPNs"/LSPs?  Redundant paths from the VRF termination?
>
>
> [VK] Our expectation was that the operator would be able to derive their own
> answers on how to enable redundancy in their model.  The expectation is that
> the reader already would understand (or would need to verse themselves) CGN
> and MPLS/VPNs.  Therefore they would be able to enumerate the options on
> their own.
>
> We were trying to keep the text simple and show the basic association of how
> to deploy the CGN using MPLS/VPNs.  I would not want to sound prescriptive
> on how to actually design a specific instance.
>
> In disclosure, when I did my design, I did use multiple RD/RTs and imported
> those routes into a common CPE VPN.  But that specific option may not be
> used by others. I would expect an operator who has already deployed
> MPLS/VPNs to have a redundancy model already in place, and they would evolve
> that for this purpose.
>
> To exemplify that point, I had discussions with two other Canadian ISPs who
> tested/integrated CGNs using this method (MPLS/VPNs) and one did not put in
> network based redundancy (just had to CGN functions at a common
> endpoint/VRF) and the other did have redundancy but only employed a single
> RD/RT (and just had multiple defaults).  Each of us (three) chose redundancy
> models which matched our pre-existing MPLS network designs.  I would expect
> the same from others as well (although this may be a poor assumption).

I don't think that you have to enumerate, though it is perhaps the
wording that is the problem here.  As phrased it implies a panoply of
wonderful options that are being purposefully withheld from the
reader.  Perhaps a rephrasing will make this intent clearer:

The described architecture does not prescribe a single redundancy
model that ensures network availability as a result of CGN failure.
Deployments are able

[Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04

[Martin Thomson]

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-opsawg-lsn-deployment-04
Reviewer: Martin Thomson
Review Date: 2014-01-06
IETF LC End Date: 2014-01-06
IESG Telechat date: (if known)

Summary:  This document describes a generic way that MPLS LSPs can be
deployed to support the deployment of CGNs in a way that addresses a
range of common requirements.  As a draft, it's still a little rough,
but it is mostly ready for publication as an Informational RFC.

Major issues: none

Minor issues:

The abstract says this:

  This document does not intend to defend the
   merits of CGN.

Which seems wise given their somewhat contentious nature.  But then
the entirely of Section 2 does exactly the opposite.  I don't know
what the right answer is here, but maybe the right thing to do is
delete Section 2.

Figures 1 and 2 should probably use different labels for the two CPE
boxes.  The top one is being translated, the bottom one isn't.

Section 6 is a little too speculative to be valuable.  How about using
the boilerplate:

  This document has no IANA actions.

I'm not sure what "security measures" might be employed here:

   If a provider plans to operate the pre-translation realm (CPE towards
   translator IPv4 zone) as a non-public like network, then additional
   security measures may be needed to secure this environment.

What might be secured in these scenarios?  Confidentiality?  Access to
network resources?  Perhaps this should talk about what a network
operator wants to secure: access to the network.  Then maybe talk
about access control and isolation.

In Section 4, this seems a little vague:

   Various redundancy models
   can be used within this architecture to support failover from one
   physical CGN hardware instance to another.

I don't expect an enumeration of the options, but this seems important
enough to at least point to where the redundancy options might exist?
Redundant "VPNs"/LSPs?  Redundant paths from the VRF termination?

Nits:

Missing period in Section 9

I found the structure of the first part of Section 3.1 difficult:

   Centralized deployments of CGN (longer proximity to end user and/or
   higher densities of subscribers/connections to CGN instances) differ
   from distributed deployments of CGN (closer proximity to end user and
   /or lower densities of subscribers/connections to CGN instances).

Maybe this could be expanded a little to improve comprehension.

This statement seems redundant:

   Other requirements may be assessed on a operator-by-operator basis,
   but those listed above may be considered for any given deployment
   architecture.

As far as it goes, some of the requirements listed might not apply to
a particular deployment, or part thereof.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-6man-ug-05

[Martin Thomson]

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-ug-05
Reviewer: Martin Thomson
Review Date: 2013-11-19
IETF LC End Date: 2013-11-28
IESG Telechat date: Not yet available

Summary: The document is ready for publication as Proposed Standard.

This document describes the problems arising from the pseudo-semantics
assigned to the 'u' and 'g' bits of EUI-64-derived interface
identifiers and declares these semantics void.  I found the
thoroughness of the justification a little excessive, but I can
appreciate why it needs to be that way :)
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-netext-pd-pmip-11

[Martin Thomson]

Inline.

On 28 October 2013 17:24, Carlos Jesús Bernardos Cano  wrote:
>> Where is ALL_ZERO defined?  (Same for NON_ZERO.)  I can guess, but I
>> don't like doing that.
>
> [Authors] These are defined in RFC5213. We can add a explicit reference
> first time we introduce these terms.

Thanks.

> [Authors] The client does not always use port 68. Therefore, we believe
> current rule is flexible and sufficient.

That's the answer I was looking for.

> [Authors] We summarize what the document is defining in the
> Introduction:
>
> "   This specification defines extensions to the Proxy Mobile IPv6
>protocol for allowing mobility support to the mobile networks
>attached to a mobile router.  The mobile router can request the
>mobility entities in the Proxy Mobile IPv6 domain for one or more
>delegated IP prefixes using DHCP Prefix Delegation extensions
>[RFC3633], or through other means such as static configuration, or
>access technology specific mechanisms."

That's higher level than I was hoping for.  This says "extensions"
without specifying what those extensions are for.  It's a small thing,
but you only need to say that you define an extension parameter for
carrying prefix information in proxy binding update and proxy binding
answer messages.

> [Authors] We believe it is better to use the labels for the sake of
> ensuring the correctness of the text.

Correctness and readability aren't mutually exclusive goals.  But it's
your document.

>> Expand acronyms.
>
> [Authors] Which acronyms are you referring to? in the text or in the
> figure 2?

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

[Gen-art] Gen-ART review of draft-ietf-netext-pd-pmip-11

[Martin Thomson]

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-netext-pd-pmip-11
Reviewer: Martin Thomson
Review Date: 2013-10-27
IETF LC End Date: 2013-10-31
IESG Telechat date: ?

This document is ready (PS), modulo a few niggles.

Minor issues:

Where is ALL_ZERO defined?  (Same for NON_ZERO.)  I can guess, but I
don't like doing that.

S5.3:
It's been a while since I've done DHCP, but doesn't the client use
port 68? Wouldn't that mean that the SA1(OUT) and SA2(IN) rules
require a label for both local_port and remote_port?  Or have we
started to use ephemeral ports at the client now (in which case, good,
because that port 68 thing is a major headache)?

Nits:

The overview sections don't make it easy to work out what this
document is actually defining.  It took me until 3.2.3 to be even
moderately certain what it was that this documented defined.  Is there
any way to be more specific about what extensions are being defined in
S1 or the lead-in to S3?

S1:

   "In this context, the mobility management support that
   is enabled for an individual IP host, which is the mobile node."

Seems like an unfinished sentence.  Or maybe a redundant "that".

S2:

This document really needs a f'rinstance.  It's pretty clear why this
is being done, but it's unnecessarily convoluted by a need to use the
official labels for everything.  For instance, LFN is probably just my
PC tethered to my phone (the MR).

S3.2.1:

Expand acronyms.

5.1.2:

The text around PBU is strange with regard to the lifetime of zero
conditions.  Suggest a four-way list rather than
two-way-plus-exceptions-on-each.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-dime-app-design-guide-19

[Martin Thomson]

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-dime-app-design-guide-19
Reviewer: Martin Thomson
Review Date: 2013-09-13
IETF LC End Date: unknown, early review
IESG Telechat date: (if known)

Summary: This document is ready, with some minor issues and nits.

Minor issues:
I would find it a lot easier to read this document if it did as the
goals state (the first objective from the introduction) and clarify
what the extensibility rules in Diameter say with respect to each of
the described extensions.  It's not easy to glean this information
from RFC 6733, which makes reviewing this a little tricky.

For instance, Section 4.1 doesn't really say what the expectations are
with respect to implementations that receive unknown or unsupported
commands.  I think that I could guess, but I'd rather not.  (I just
read the relevant parts of 6733, and it turns out that my guess was
wrong.)

The same applies to Section 4.2, presumably through applying the same
principles.  The question here is: what would be the expected behavior
if a node was operating on the new application definition and that
node received a deleted command?  (The old implementation presumably
has no problem with the absence of the command if it's being removed.)

The same applies to Section 5.

Sections 4.4.2 and particularly 5.6 lead me to infer that the
extensibility for enumerated types is fundamentally broken, so maybe
those properties need to be expanded upon a little here too.

The placement of the guidance in Section 5.6 seems fairly important
for Section 4, lest that important information be lost to someone just
looking to tweak a command.

Section 4.3.1, perhaps add to the M-bit criteria: Would the presence
or value of the AVP alter the interpretation of the command (or any
other AVP) in any way?  (nit: s/AVPs/AVP on second bullet here.)

I didn't find the list in  Section 6 particularly compelling.  It
seemed a little like motherhood statements.  The description of what
it was this was talking about: good; the description of how these
"often" (always?) manifest is also useful.  I wonder though whether
it's safe to generalize when you only see generic protocols extensions
as optional AVPs.  Perhaps you need to refocus on exactly that, and
leave the other forms of extension to speculation.

Nits/editorial comments:
The last paragraph of Section 3 is confusing to me.  Firstly, the
subject of the reminder is missing from the first sentence.  I think
that the intent of that sentence is to say that extending by adding
applications or commands is to be avoided, but then subsequent
sentences make it clear that doing so is easy.  The last sentence
seems to be talking about something else entirely, which is the value
that IANA registries provide.  I am going to have to suggest that this
be reworded entirely.

In Section 4.1, I'd like to see the note turned into real text.  The
size and complexity of an application seems to be a fairly significant
factor in determining whether a new application imports commands, or
whether separate applications are defined.

I read the first bullet in Section 4.3.2 as a sentence, several times,
before realizing that it's a title.  Please reconsider the formatting
of this list.  At a very minimum, remove the period.

--Martin

p.s., I'm on vacation starting approximately ...now, since I'm out of
time for this review... so apologies for any slow responses to the
review.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-geopriv-res-gw-lis-discovery-05

[Martin Thomson]

Thanks Peter.

I fixed all the nits:
https://github.com/martinthomson/drafts/commit/0e7cc6089e96f6b4b2a2cff0d094733b313b8e39

On 31 July 2013 13:50, Peter Yee  wrote:
> Page 9, section 4.2, 2nd paragraph, 1st sentence: I'll admit my ignorance
> of the finer points of the DNS and inquire what this sentence is supposed
> to mean.  To what are the additional domain names added and how does this
> allow a DNS record to cover a larger set of addresses?  Perhaps it's just
> the wording or my lack of knowledge, but I didn't follow this point fully.

This relates to the label shortening.  In the reverse tree, an IP
address is represented as a series of labels in reverse order.  Fewer
labels means that the resulting name covers a specific prefix (each
label is 8 bits for v4, 4 bits for v6).  I've added an example to this
section that I hope helps demonstrate this.
https://github.com/martinthomson/drafts/commit/29a4c98deaa1c9f9be66633e7bdfc7fd971318e9

> Page 14, 6th paragraph, last sentence: Are there any concrete
> suggestions on who a device might determine accuracy?

An independent, trusted source of location information could aid in
verification, even in the trusted source is unable to provide
information with the same accuracy as the discovered LIS.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [apps-discuss] Gen-ART review of draft-bormann-cbor-04

[Martin Thomson]

Hi Carsten,

I wasn't really looking for a defense of the design in the form you
just provided, cogent as it was.  I want to know what value you get
from these extensibility features, not a reiteration (and expansion)
of the characteristics of those features.

My operating assumption was that JSON was successful precisely because
it was only extensible in one limited direction.  In some ways, this
is the challenge I wanted to set by writing my review.  Can you a)
invalidate that theory somehow, and b) motivate the addition of each
axis of extensibility.

As I said privately, I have no problem with shipping a proposed
standard RFC that has a clear set of goals, and I think that you are
doing the right thing in that regard.  What I really want to do is
have is that other conversation.  And maybe long review threads are
the wrong place for that conversation, I don't know (maybe I'll drop
gen-art on my next reply).

On 12 August 2013 20:28, Carsten Bormann  wrote:
> CBOR maps are intended to be maps, not multimaps.  Duplicate keys are
> an encoding error.  Unfortunately, what should be considered duplicate
> is often application dependent (are 0 and 0.0 the same key?  "Å" and
> "Å"?), so a generic parser will only be able to do part of the work.

Ouch, really?  Add this to the list of things that a using
application/specification needs to worry about.  SASLprep anyone?
Maybe there should be a list of those somewhere in the draft, which
includes:

The types to implement (and whether to disallow or ignore others)
What map keys to permit and how to compare them (with a special note
about IEEE 754 NaN values, which might be bit-exact, but don't compare
equal)
The extension points to implement (and how to ignore 28-30)
Whether to allow tags
Which tags to ignore
What date format(s) to use
What to do about JSON if you are performing translation (see tags)
What types to permit indefinite length encoding for
... and I'm sure I've missed something

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

Re: [Gen-art] [apps-discuss] Gen-ART review of draft-bormann-cbor-04

[Martin Thomson]

On 5 August 2013 18:43, Joe Hildebrand (jhildebr)  wrote:
> Sorry, my response is also correspondingly long.

I'll be brief.  Though Joe missed my point on several of his rebuttals
(which I found to be an odd thing to do anyway), I see no reason to
quibble.  I think that the bulk of the comments are valid, though I
might disagree on several.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-bormann-cbor-04

[Martin Thomson]

Adding draft-relevant recipients.

On 30 July 2013 00:05, Martin Thomson  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-bormann-cbor-04
> Reviewer: Martin Thomson
> Review Date: 2013-07-29
> IETF LC End Date: ?
> IESG Telechat date: 2013-08-15
>
> Summary:
> This document is not ready for publication as proposed standard.
>
> I'm glad that I held this review until Paul's appsarea presentation.
> This made it very clear to me that the types of concerns I have are
> considered basically irrelevant by the authors because they aren't
> interested in changing the design goals.  I don't find the specific
> design goals to be interesting and am of the opinion that the goals
> are significant as a matter of general application.  I hope that is
> clear from my review.
>
> Independent of any conclusions regarding design goals, there are
> issues that need addressing.
>
> (This is an atypical Gen-ART review.  I make no apologies for that.  I
> didn't intend to write a review like this when I started, but feel
> that it's important to commit these thoughts to the record.  It's also
> somewhat long, sorry.  I tried to edit it down.)
>
> I have reviewed the mailing list feedback, and it's not clear to me
> that there is consensus to publish this.  It might be that the dissent
> that I have observed is not significant in Barry's learned judgment,
> or that this is merely dissent on design goals and therefore
> irrelevant.  The fact that this work isn't a product of a working
> group still concerns me.  I'm actually interested in why this is
> AD-sponsored rather than a working group product.
>
> Major issues:
> My major concerns with this document might be viewed as disagreements
> with particular design choices.  And, I consider it likely that the
> authors will conclude that the document is still worth publishing as
> is, or perhaps with some minor changes.  In the end, I have no issue
> with that, but expect that the end result will be that the resulting
> RFC is ignored.
>
> What would cause this to be tragic, is if publication of this were
> used to prevent other work in this area from subsequently being
> published.  (For those drawing less-than-charitable inferences from
> this, I have no desire to throw my hat into this particular ring,
> except perhaps in jest [1].)
>
> This design is far too complex and large.  Regardless of how
> well-considered it might be, or how well this meets the stated design
> goals, I can't see anything but failure in this document's future.
> JSON succeeds largely because it doesn't attempt to address so many
> needs at once, but I could even make a case for why JSON contains too
> many features.
>
> In comparison with JSON, this document does one major thing wrong: it
> has more options than JSON in several dimensions.  There are more
> types, there are several more dimensions for extensibility than JSON:
> types extensions, values extensions (values of 28-30 in the lower bits
> of the type byte), plus the ability to apply arbitrary tags to any
> value.  I believe all of these to be major problems that will cause
> them to be ignored, poorly implemented, and therefore useless.
>
> In part, this complexity produces implementations that are far more
> complex than they might need to be, unless additional standardization
> is undertaken.  That idea is something I'm uncomfortable with.
>
> Design issue: extensibility:
> This document avoids discussion of issues regarding schema-less
> document formats that I believe to be fundamental.  These issues are
> critical when considering the creation of a new interchange format.
> By choosing this specific design it makes a number of trade-offs that
> in my opinion are ill-chosen.  This may be in part because the
> document is unclear about how applications intend to use the documents
> it describes.
>
> You may conclude after reading this review that this is simply because
> the document does not explain the rationale for selecting the approach
> it takes.  I hope that isn't the conclusion you reach, but appreciate
> the reasons why you might do so.
>
> I believe the fundamental problem to be one that arises from a
> misunderstanding about what it means to have no schema.  Aside from
> formats that require detailed contextual knowledge to interpret, there
> are several steps toward the impossible, platonic ideal of a perfectly
> self-describing fo

[Gen-art] Gen-ART review of draft-bormann-cbor-04

[Martin Thomson]

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-bormann-cbor-04
Reviewer: Martin Thomson
Review Date: 2013-07-29
IETF LC End Date: ?
IESG Telechat date: 2013-08-15

Summary:
This document is not ready for publication as proposed standard.

I'm glad that I held this review until Paul's appsarea presentation.
This made it very clear to me that the types of concerns I have are
considered basically irrelevant by the authors because they aren't
interested in changing the design goals.  I don't find the specific
design goals to be interesting and am of the opinion that the goals
are significant as a matter of general application.  I hope that is
clear from my review.

Independent of any conclusions regarding design goals, there are
issues that need addressing.

(This is an atypical Gen-ART review.  I make no apologies for that.  I
didn't intend to write a review like this when I started, but feel
that it's important to commit these thoughts to the record.  It's also
somewhat long, sorry.  I tried to edit it down.)

I have reviewed the mailing list feedback, and it's not clear to me
that there is consensus to publish this.  It might be that the dissent
that I have observed is not significant in Barry's learned judgment,
or that this is merely dissent on design goals and therefore
irrelevant.  The fact that this work isn't a product of a working
group still concerns me.  I'm actually interested in why this is
AD-sponsored rather than a working group product.

Major issues:
My major concerns with this document might be viewed as disagreements
with particular design choices.  And, I consider it likely that the
authors will conclude that the document is still worth publishing as
is, or perhaps with some minor changes.  In the end, I have no issue
with that, but expect that the end result will be that the resulting
RFC is ignored.

What would cause this to be tragic, is if publication of this were
used to prevent other work in this area from subsequently being
published.  (For those drawing less-than-charitable inferences from
this, I have no desire to throw my hat into this particular ring,
except perhaps in jest [1].)

This design is far too complex and large.  Regardless of how
well-considered it might be, or how well this meets the stated design
goals, I can't see anything but failure in this document's future.
JSON succeeds largely because it doesn't attempt to address so many
needs at once, but I could even make a case for why JSON contains too
many features.

In comparison with JSON, this document does one major thing wrong: it
has more options than JSON in several dimensions.  There are more
types, there are several more dimensions for extensibility than JSON:
types extensions, values extensions (values of 28-30 in the lower bits
of the type byte), plus the ability to apply arbitrary tags to any
value.  I believe all of these to be major problems that will cause
them to be ignored, poorly implemented, and therefore useless.

In part, this complexity produces implementations that are far more
complex than they might need to be, unless additional standardization
is undertaken.  That idea is something I'm uncomfortable with.

Design issue: extensibility:
This document avoids discussion of issues regarding schema-less
document formats that I believe to be fundamental.  These issues are
critical when considering the creation of a new interchange format.
By choosing this specific design it makes a number of trade-offs that
in my opinion are ill-chosen.  This may be in part because the
document is unclear about how applications intend to use the documents
it describes.

You may conclude after reading this review that this is simply because
the document does not explain the rationale for selecting the approach
it takes.  I hope that isn't the conclusion you reach, but appreciate
the reasons why you might do so.

I believe the fundamental problem to be one that arises from a
misunderstanding about what it means to have no schema.  Aside from
formats that require detailed contextual knowledge to interpret, there
are several steps toward the impossible, platonic ideal of a perfectly
self-describing format.  It's impossible because ultimately the entity
that consumes the data is required at some level to understand the
semantics that are being conveyed.  In practice, no generic format can
effectively self-describe to the level of semantics.

This draft describes a format that is more capable at self-description
than JSON.  I believe that to not just be unnecessary, but
counterproductive.  At best, it might provide implementations with a
way to avoid an occasional extra line of code for type conversion.

Extensibility a

Re: [Gen-art] Timing of reviews: conclusion

[Martin Thomson]

On 11 July 2013 13:03, Brian E Carpenter  wrote:
> but IMHO it would be better
> if we submitted our reviews via the review tool, which could then
> send them on as email automatically.

I have all the same problems as Brian.  And this might also make
access control easier, such that reviews could be sent to WG lists
without requiring sign-up (though on reflection, that's a little
optimistic).
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-geopriv-held-measurements-07.txt

[Martin Thomson]

Correct.  There are a number of DISCUSS positions that will be resolved by -08. 
 I haven't read all the DISCUSS material yet, but I expect that there will need 
to be a few more edits to catch the rest of them.  I'll have to coordinate with 
Richard to determine when to ship -08.  I don't want to interfere with AD 
reviews.

> -Original Message-
> From: Jari Arkko [mailto:jari.ar...@piuha.net]
> Sent: Tuesday, 11 June, 2013 22:45
> To: Suresh Krishnan
> Cc: draft-ietf-geopriv-held-measurements@tools.ietf.org; General Area
> Review Team
> Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-geopriv-held-
> measurements-07.txt
> 
> Thank you very much for the review, Suresh. I followed your discussion with
> Martin, and the conclusions seem correct to me. But I don't think we should
> approve the draft until the -08 appears. Martin?
> 
> Jari
> 
> On Jun 10, 2013, at 2:15 PM, Suresh Krishnan
>  wrote:
> 
> > I have been selected as the General Area Review Team (Gen-ART)
> > reviewer for this draft (for background on Gen-ART, please see
> > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> >
> > Please wait for direction from your document shepherd or AD before
> > posting a new version of the draft.
> >
> > Document:  draft-ietf-geopriv-held-measurements-07.txt
> > Reviewer: Suresh Krishnan
> > Review Date: 2013/06/10
> > IESG Telechat date: 2013/06/13
> >
> >
> > Summary: This draft is almost ready for publication as a Proposed
> > Standard, but I had a few minor comments as identified in my last call
> > review dated 2013/05/08. The authors had agreed to fix the following
> > issues but I have not seen an updated draft yet.
> >
> > Minor
> > =
> >
> > * Section 5.2
> >
> > - The Interface-Id option is the DHCPv6 equivalent of the circuit
> > identifier defined in RFC3046. Please add a reference to Section 22.18
> > of RFC3315 that describes this option.
> >
> > - Is there any specific reason that the giaddr is being specified
> > using the IPv4-mapped IPv6 address format? From my reading giaddr is
> > of type bt:ipAddressType and it allows specification of both IPv4 and
> > IPv6 addresses natively.
> >
> > * Section 8.7 Page 53
> >
> > I think there may be an off-by-one error here.
> >
> > 
> >
> > Shouldn't this be
> >
> > 
> >
> > so that the largest value will fit in 28 bits?
> >
> > Thanks
> > Suresh
> >
> >
> > ___
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
> 

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

[Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-radius-opt-12

[Martin Thomson]

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>

Document: draft-ietf-dhc-dhcpv6-radius-opt-12
Reviewer: Martin Thomson
Review Date: 30 May 2013
IETF LC End Date: 30 May 2013
IETF Telechat Date: 30 May 2013

Summary:  This document is ready for publication as proposed standard.

Major Issues: None

Minor Issues:
The security of this mechanism seems to rely on trust in the relay.
None of the RADIUS options are authenticated by the DHCP server, so
the integrity of the relay is paramount.  The "may" in the following
statement should probably be removed:

   The mechanism described in this document may^H^H^H introduce new attack
   vector against the DHCPv6 server in case the DHCPv6 relay agent is
   compromised.

Adding a statement to the effect that the authenticity of RADIUS
options is not assured by any means other than trust in the relay
would be better, e.g.,

   No mechanism is provided to support the authenticity of RADIUS
attributes that are encapsulated in this way.  The DHCPv6 server
relies on trust in the DHCPv6 relay to avoid making decisions based on
forged RADIUS attributes.

The statement below doesn't really highlight what sort of "security"
problems might arise when relaying RADIUS options to the DHCP server:

   [...]  Designated
   expert should carefully consider the security implications of
   allowing the relay agent to include new RADIUS attribute for the
   addition to this registry.

I think that this refers to the text regarding encryption in Section
8, but it implies that there might be other issues.  (The above is
also grammatically suspect.)

Editorial nits: None

p.s., My apologies about the timing of this review.  -12 fixed my
earlier issues, so I had to start over.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Partial Gen-ART review of draft-ietf-nfsv4-rfc3530bis-25

[Martin Thomson]

On 30 May 2013 05:29, Jari Arkko  wrote:
> Also, did I miss a response form the authors/WG to this review? I can not 
> find one in my e-mail archives…

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-geopriv-held-measurements-07

[Martin Thomson]

Thanks Suresh.

I've made the changes in the -08 that I'm holding for AD go-ahead.  I'll try to 
remember to send you a note when this goes out.

> Summary: This draft is almost ready for publication as a Proposed
> Standard, but I have a few minor comments that you may wish to address.
> 
> * Section 5.2
> 
> - The Interface-Id option is the DHCPv6 equivalent of the circuit
> identifier defined in RFC3046. Please add a reference to Section 22.18 of
> RFC3315 that describes this option.

Got it.  Thanks.

> - Is there any specific reason that the giaddr is being specified using
> the IPv4-mapped IPv6 address format? From my reading giaddr is of type
> bt:ipAddressType and it allows specification of both IPv4 and IPv6
> addresses natively.

Yeah, that is strange.  I'll use a "normal" address.  (I think that I was just 
testing out schema validation in the examples and it leaked out.)

> * Section 8.3 Page 44
> 
> IPv4-compatible addresses have been deprecated in the IPv6 addressing
> architecture (RFC4291) and need not be supported here.

That's true, but deprecated != MUST NOT use.  If it's all the same to you, I'd 
rather just leave as is.  If I were to make a change, it would be to remove 
acceptance of the dotted quad portion entirely.  But I think that the mapped 
address form is in use.  I'd have to check with the working group on that.

> * Section 8.7 Page 53
> 
> I think there may be an off-by-one error here.
>  

Yes, good catch.  Either down by one or maxExclusive :)

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

Re: [Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06

[Martin Thomson]

On 26 April 2013 10:44, Stewart Bryant  wrote:
> Section 6.3 now says
>
> The HMAC proceedure described in [RFC2104] is used to compute the hash.

s/proceedure/procedure/

> The hash is computed over the entire GAP message as shown in Fig1.

What value does the Authentication TLV have when it is input to the HMAC?

> The length of the Authentication Data field is always less than or equal
> to the message digest size of the specific hash function that is being
> used, however the implementer needs to consider that although this
> decreases the size of the message, it results in a corresponding
> reduction in the strength of the assurance provided.
> Hash truncation is not RECOMMENDED.

This last part could probably be a new paragraph.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-07

[Martin Thomson]

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 (post) Last Call comments
you may receive.

Document: draft-ietf-mpls-tp-ethernet-addressing-07
Reviewer: Martin Thomson
Review Date: 2013-04-19
IETF LC End Date: 2013-02-18 (!)
IESG Telechat date: 2013-04-25

Summary: This document is almost ready for publication as proposed
standard.  There are some minor issues

Major issues: None

Minor issues:

The structure of the document is odd.  The individual pieces of
explanation are good, it's just that different bits are revealed in a
strange order.  If the intent is to describe a method of selecting an
Ethernet address to attach to MPLS-TP packets, I would have thought
that structuring the document to correspond to the prioritization of
methods would make sense.  That is, from what I can infer:
If unicast, use a unicast address (MUST for multipoint attachment,
SHOULD for others)
  1. from G-ACh, if available
  2. from static configuration, if operationally feasible
otherwise, for point-to-point links you can use
  3. the IANA-assigned special address
  4. FF-FF-FF-FF-FF-FF
Reordering might help with understanding the process.

If multicast/broadcast LSPs, there doesn't seem to be any actual
recommendations or advice in the document.  There is only an
admonition to use encapsulation, which is probably necessary for other
reasons anyhow.  So it's not clear how Section 3, paragraph 1 is
relevant to this document.  It doesn't offer any guidance on how one
might select an appropriate Ethernet address for those frames.
Presumably these could be unicast, multicast or broadcast depending on
routing requirements for the LSP, in which case maybe there is no good
advice to give. If there really is no good advice to give, or there is
no intent to provide advice for multicast/broadcast LSPs, a statement
to that effect would be helpful.

Section 3, Paragraph 2 just reiterates parts of Section 2, it could be removed.

S5: I can't reconcile "The advertised information SHOULD be persistent
across restarts."  with "Received advertisements MUST be discarded
across restarts."

S4, pp5: Why force a mapping to EUI-64?  Is canonicalization important
for some reason?

S4, pp5: The paragraph beginning with "In the event a GAP message is
not received within the previously received associated Lifetime, ..."
is a little confusing (and I'm familiar with G-ACh already).  This
could be clearer.  Maybe:  "A node could cease transmission of G-ACh
advertisements, or cease to include a Source MAC Address TLV in
advertisements, either of which cause the TLV lifetime to elapse.
After the Source MAC Address TLV lifetime has elapsed, this value
SHOULD no longer be used to select a MAC address; the node SHOULD
return to selecting MAC addresses as though no advertisements were
received."

S7.3: IETF review is a pretty high bar.  (Sadly, I missed this on
G-ACh, or I would have made the same comment.)  Did you consider
allowing IESG Approval as an alternative?


Nits/editorial comments:
There are a couple of lowercase instances of RFC2119 keywords that
could be confusing.  The very last line of S4, the second last
sentence of S2.  Consider alternative wordings for these statements.

S2, pp3: s/i.e.  /i.e., /
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Partial Gen-ART review of draft-ietf-nfsv4-rfc3530bis-25

[Martin Thomson]

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-nfsv4-rfc3530bis-25
Reviewer: Martin Thomson
Review Date: 2013-04
IETF LC End Date: too soon
IESG Telechat date: ditto

Summary: I have some confidence that this document is ready for
publication.  What I have seen is sufficiently well specified that it
could be implemented, mostly.  There are large parts of this document
that I simply haven't read.  I can't justify spending more time.
(Sorry Jari, I tried.)

Reviewing this document is especially difficult because the it relies
heavily on context.  A lot of this context is only gained by reading on
and stumbling upon that context.  Much of this could be addressed
with appropriate forward references.

It's clear that Section 12 is largely new, or at least significantly
changed from RFC 3530.  Section 12 on its own would constitute a
larger than average RFC.

If accessibility is a goal, the document could have been split and it
probably should have been.  However, I suspect that accessibility
isn't that important to those working on this.

The document talks quite frequently about "before", with reference to
NFSv2 or NFSv3.  This is almost always useless to a reader without
context.  I don't expect you to do anything about this, but I'd
request that any future revision consider removing this.  For one, in
reviewing a -bis draft, I personally think of RFC3530 as the "before"
to which is refered.  On the whole, fewer history lessons and more
real context would have made this a lot easier to read.

General: The document uses lowercase "must" and "may" a lot.  It's not
clear whether these are intended to be interpreted as normative
statements or not.  To my eyes, most of these are.  On the other hand,
there are places where 2119 language is used to effectively specify
implementation details that aren't observable at a protocol level.
If the document weren't so large, I'd suggest that the editors go through
and make sure that every 2119 keyword is in uppercase and then to
check each and every instance.

Nits:

1.5.3 - I realize that it might be premature to explain details when the
draft hasn't yet described how to identify locations (that's a truly
unfortunate choice of word).  Maybe a short primer on that could be
included.  At this point, I'm relying on assumed knowledge about
filesystems to understand concepts like: hierarchical ACLs, pseudo
filesystems, attributes.

Even the fact that a filesystem is a tree with terminal nodes that
contain sequences of bytes.  Non-terminal nodes (directories) and
terminal nodes (files) are named (hence the UTF-8) and have
attributes.  Where it gets fuzzy is when it uses "path name".  Is
"path name" an abstraction that encapsulates "directory name" and
"file name"?  Is a "file name" the name of the node, or is it the
entire locator including the names of the directory above it (and some
unspecified separator)?

1.5.3.1
   [...]  The server provides multiple
   filesystems by gluing them together with pseudo filesystems.  These
   pseudo filesystems provide for potential gaps in the path names
   between real filesystems.

I don't know how to interpret this last statement.  I'm using a fair
bit of guesswork to infer how this works as it is, but that
understanding does not result in gaps, just pseudo filesystems (with
no actual files).


1.5.3.3 - The description of namespaces is singularly unhelpful in
conveying any information about the mechanism.  The benefits of this
snake oil are clearly splendrous.

s/alternate/alternative/ - I know that alternate is acceptable US
English, but alternate means something else to other English speakers.

1.5.5 - NLM could probably use a citation.

3.1 - "The registered port 2049 [RFC3232] for the NFS protocol SHOULD
be the default configuration."  This is an implementation requirement,
not a protocol one.

- "this will allow NFS to transit firewalls" is only true if the
firewall is configured to recognize NTP using port numbers and allow
its passage.

- "To date, all NFSv4 implementations are TCP based." Is this
really an appropriate statement for an RFC?

- "UDP by itself is not sufficient as a transport for NFSv4,
neither is UDP in combination with some other mechanism (e.g., DCCP
[RFC4340], NORM [RFC5740])."  This statement is strange, given that
UDP is specifically prohibited.  I understand that something layered
on UDP (SCTP perhaps) might be able to meet the requirements, but this
statement implies that neither congestion control (DCCP), nor
reliability (NORM) is sufficient.  The draft should enumerat

Re: [Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06

[Martin Thomson]

Hi Stewart,

Looks like you have most of this in hand.  A few comments.

On 27 March 2013 13:11, Stewart Bryant  wrote:
>>> In Section 4.4, how does the duration interact with the lifetime?
>>> What happens when the duration is longer than lifetime such that the
>>> TLV is expunged before the duration is up?
>
> Well that would normally be a silly thing to do, but we do not propose to
> stop
> it lest it be something an application actually wants.
>
> This would be functionally equivalent to issuing a short term note
> that was only transiently valid, or issuing some sort of synchronization
> message. I can't think why you would want to do it, but why would we
> stop it?

There was an implicit question here.  Namely:  Do you want to codify
anything regarding expectations on this?  Can I rely on an
attribute/action with a long duration after the retention interval has
expired?

>>> Section 5.2 states:
>>> [...] If one
>>> of the received TLV objects has the same Type as a previously
>>> received TLV then the data from the new object SHALL replace the data
>>> associated with that Type unless the X specification dictates a
>>> different behavior.
>>>
>>> This leads to different retention characteristics depending on some
>>> arbitrary application-specific requirements.  It also complicates
>>> implementations.  Is there a strong motivation for the "unless the X
>>> specification dictates a different behavior" part of this statement?
>
> Yes, on the one hand we do not wish to constrain the applications, and
> on the other we trust the application developers and the IETF review
> process (required for a code point) to stop silly behaviour.

I don't find that answer particularly satisfactory.  If I were to
build a generic implementation of this, I wouldn't want to allow for
this feature because it's a fairly large complication.  That's what
I'm trying to get to: what motivation can you provide to an
implementer to support this feature?  And in case I'm not being clear,
what would you want to put in the draft?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06

[Martin Thomson]

I sent the following review a few weeks back.  I just wanted to make sure
that it didn't get accidentally stored in /dev/null.


On 15 February 2013 14:33, Martin Thomson  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-mpls-gach-adv-06
> Reviewer: Martin Thomson
> Review Date: 2013-02-15
> IETF LC End Date: 2013-02-27
> IESG Telechat date: (if known)
>
> Summary: The document is almost ready for publication as proposed
> standard.  There is a major issue that should be easy to resolve.
>
> Major issues:
>
> Section 6.3 duplicates the description of HMAC provided in RFC 2104.
> That is likely to cause a bug.
>
> If you reference RFC 2104, then the only requirement is a clear
> specification for what message is input to the HMAC.  Currently, this
> is buried.  It is unclear if the input includes the G-ACh header
> defined in RFC 5586 (it doesn't need to, but this needs to be made
> explicit).
>
> Filling the authentication part with 0x878FE1F3 seems unnecessary busy
> work, but it's harmless as long as the hash function produces a
> multiple of 32 bits of output.
>
> Minor issues:
>
> To avoid forward compatibility issues, reserved fields should come
> with guidance that says: "Implementations of this protocol version
> MUST set reserved fields to all zero bits when sending and ignore any
> value when receiving messages."
>
> In Section 4.4, how does the duration interact with the lifetime?
> What happens when the duration is longer than lifetime such that the
> TLV is expunged before the duration is up?
>
> Section 5.2 states:
>[...] If one
>of the received TLV objects has the same Type as a previously
>received TLV then the data from the new object SHALL replace the data
>associated with that Type unless the X specification dictates a
>different behavior.
>
> This leads to different retention characteristics depending on some
> arbitrary application-specific requirements.  It also complicates
> implementations.  Is there a strong motivation for the "unless the X
> specification dictates a different behavior" part of this statement?
>
> If this behaviour is desirable, a note regarding what happens to the
> composed TLV when some of the values that contribute to it might
> expire might be necessary.
>
> Regarding the last paragraph of Section 6.3:
>   This also means that the use of hash functions with larger
>   output sizes will increase the size of the GAP message as
>   transmitted on the wire.
>
> If you want to prevent hash truncation, then use 'MUST'.  Personally,
> I see no reason to do so.  It's a good way to get smaller messages,
> with a corresponding reduction in the strength of the assurance
> provided.
>
> Nits:
>
> Section 3 could use some subheadings to aid navigation (and referencing).
>
> Section 3 describes the size of fields only through ASCII-art.  It's a
> fairly simple thing to add a bit count to the description of each
> field.  That includes the reserved fields, which have no descriptions.
>
> I like the text in the editors note on page 8.  Why is it not the
> actual text already?
>
> Sections 4.2 and 4.3 could probably use a note that notes that
> retention of these TLVs doesn't make any sense.  These could be sent
> with zero lifetime, except that if these are sent along with the
> Source Address TLV, that's not possible... unless you send multiple
> application data blocks for the same application.  Is that possible?
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06

[Martin Thomson]

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-mpls-gach-adv-06
Reviewer: Martin Thomson
Review Date: 2013-02-15
IETF LC End Date: 2013-02-27
IESG Telechat date: (if known)

Summary: The document is almost ready for publication as proposed
standard.  There is a major issue that should be easy to resolve.

Major issues:

Section 6.3 duplicates the description of HMAC provided in RFC 2104.
That is likely to cause a bug.

If you reference RFC 2104, then the only requirement is a clear
specification for what message is input to the HMAC.  Currently, this
is buried.  It is unclear if the input includes the G-ACh header
defined in RFC 5586 (it doesn't need to, but this needs to be made
explicit).

Filling the authentication part with 0x878FE1F3 seems unnecessary busy
work, but it's harmless as long as the hash function produces a
multiple of 32 bits of output.

Minor issues:

To avoid forward compatibility issues, reserved fields should come
with guidance that says: "Implementations of this protocol version
MUST set reserved fields to all zero bits when sending and ignore any
value when receiving messages."

In Section 4.4, how does the duration interact with the lifetime?
What happens when the duration is longer than lifetime such that the
TLV is expunged before the duration is up?

Section 5.2 states:
   [...] If one
   of the received TLV objects has the same Type as a previously
   received TLV then the data from the new object SHALL replace the data
   associated with that Type unless the X specification dictates a
   different behavior.

This leads to different retention characteristics depending on some
arbitrary application-specific requirements.  It also complicates
implementations.  Is there a strong motivation for the "unless the X
specification dictates a different behavior" part of this statement?

If this behaviour is desirable, a note regarding what happens to the
composed TLV when some of the values that contribute to it might
expire might be necessary.

Regarding the last paragraph of Section 6.3:
  This also means that the use of hash functions with larger
  output sizes will increase the size of the GAP message as
  transmitted on the wire.

If you want to prevent hash truncation, then use 'MUST'.  Personally,
I see no reason to do so.  It's a good way to get smaller messages,
with a corresponding reduction in the strength of the assurance
provided.

Nits:

Section 3 could use some subheadings to aid navigation (and referencing).

Section 3 describes the size of fields only through ASCII-art.  It's a
fairly simple thing to add a bit count to the description of each
field.  That includes the reserved fields, which have no descriptions.

I like the text in the editors note on page 8.  Why is it not the
actual text already?

Sections 4.2 and 4.3 could probably use a note that notes that
retention of these TLVs doesn't make any sense.  These could be sent
with zero lifetime, except that if these are sent along with the
Source Address TLV, that's not possible... unless you send multiple
application data blocks for the same application.  Is that possible?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-avtcore-srtp-encrypted-header-ext-04

[Martin Thomson]

I've reviewed the latest (-06) and it is equally ready.  (That is,
I've seen no changes as a result of this review.)

On 17 January 2013 13:49, Martin Thomson  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-avtcore-srtp-encrypted-header-ext-04
> Reviewer: Martin Thomson
> Review Date: 2013-01-17
> IETF LC End Date: 2013-01-17
> IESG Telechat date: (if known)
>
> Summary:  This document is clear, well-written and ready for
> publication as proposed standard.
>
> Minor issues:  I wonder if it is necessary to establish a registry for
> the labels used in SRTP key derivation (k_e, k_s, k_he, k_hs, etc...).
>  As unlikely as it seems, a collision in this space would be bad.
>
> Nits/editorial comments:
> S5: s/alternate/alternative/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Fwd: Gen-ART review of draft-ietf-avtcore-srtp-encrypted-header-ext-04

[Martin Thomson]

FYI, I can't believe that I did this again.

Sorry Russ.

-- Forwarded message --
From: Martin Thomson 
Date: 17 January 2013 13:49
Subject: Gen-ART review of draft-ietf-avtcore-srtp-encrypted-header-ext-04
To: draft-ietf-avtcore-srtp-encrypted-header-ext@tools.ietf.org


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-encrypted-header-ext-04
Reviewer: Martin Thomson
Review Date: 2013-01-17
IETF LC End Date: 2013-01-17
IESG Telechat date: (if known)

Summary:  This document is clear, well-written and ready for
publication as proposed standard.

Minor issues:  I wonder if it is necessary to establish a registry for
the labels used in SRTP key derivation (k_e, k_s, k_he, k_hs, etc...).
 As unlikely as it seems, a collision in this space would be bad.

Nits/editorial comments:
S5: s/alternate/alternative/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GenART review of draft-schaad-pkix-rfc2875-bis-03

[Martin Thomson]

I have reviewed the changes in -06.  All my concerns were addressed.

(Not that they were significant.)

Now that OIDs were allocated, it's really, truly ready now.

--Martin

On 6 December 2012 17:02, Martin Thomson  wrote:
> Document: draft-schaad-pkix-rfc2875-bis-03
> Reviewer: Martin Thomson
> Review Date: 2012-12-06
> IETF LC End Date: Aaaages
> IESG Telechat date: (if known)
>
> Summary: Looks good to me.  Ship it.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GenART review of draft-schaad-pkix-rfc2875-bis-03

[Martin Thomson]

On 7 December 2012 00:25, Jim Schaad  wrote:
>> Needs more ASN.1
>
> I'm lost with this, what do you believe needs to be added?  The ASN.1 as it 
> stands is complete.

'twas in jest.  Don't worry about it.  I didn't see any errors, but
I'm not a very good ASN.1 parser.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GenART review of draft-schaad-pkix-rfc2875-bis-03

[Martin Thomson]

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: raft-schaad-pkix-rfc2875-bis-03
Reviewer: Martin Thomson
Review Date: 2012-12-06
IETF LC End Date: Aaaages
IESG Telechat date: (if known)

Summary: Looks good to me.  Ship it.

Nits/editorial comments:

Section 3 does not establish a notation convention for multiplication.
 I didn't find a specific place that this was a problem, but it seemed
appropriate since multiplications was, in some places denoted 'n*b'
and others as 'xy', even though multi-character identifiers are used
in many places.  This does imply that a precedence override is
necessary.  I suggest parentheses, since they are already used
extensively.

Section 3: s/MAC funtion/MAC functions/

Section 5: could use a more rigorous list construction, the
definitions all run together

Needs more ASN.1

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

Re: [Gen-art] Gen-ART review of draft-ietf-6man-uri-zoneid-05

[Martin Thomson]

On 17 November 2012 00:16, Brian E Carpenter
 wrote:
> I don't quite understand that. RFC3986 section 2.1 says
>   pct-encoded = "%" HEXDIG HEXDIG
> with no restrictions on HEXDIG, so why is %01 disallowed?
> (I agree it would be meaningless, but that's another matter).

Meaningless is precisely my point.  It's unclear what is exactly the
right behaviour in this situation, so hedging on the vague side,
inadvisable as that normally is, might be safest.

>>> s/proxy/intermediary/
>
> proxy or other intermediary?

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

Re: [Gen-art] Gen-ART review of draft-ietf-6man-uri-zoneid-05

[Martin Thomson]

Try again, this time with the right recipients.

On 16 November 2012 12:22, Martin Thomson  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-6man-uri-zoneid-05
> Reviewer: Martin Thomson
> Review Date: 2012-11-16
> IETF LC End Date:  2012-11-26
> IESG Telechat date: not scheduled
>
> Summary:  This document is ready for publication as Proposed Standard,
> with nits.
>
> Nits/editorial comments:
>
> The document could be made shorter by removing:
>
>We now present the necessary formal syntax.
>
>The 6man WG discussed and rejected an alternative in which the
>existing syntax of IPv6address would be extended by an option to add
>the ZoneID only for the case of link-local addresses.  It was felt
>that the present solution offers more flexibility for future uses and
>is more straightforward to implement.
>
> This latter text might be put in the appendix, if it is necessary at
> all.  The text in the security considerations is probably adequate.
>
> The following statement implies "special" processing for zone IDs at user 
> input:
>
>This document implies that all browsers should recognise a ZoneID
>preceded by an escaped "%".  In the spirit of "be liberal with what
>you accept", we also recommend that URI parsers accept bare "%" signs
>(i.e., a "%" not followed by two valid hexadecimal characters).  This
>makes it easy for a user to copy and paste a string such as
>"fe80::a%en1" from the output of a "ping" command and have it work.
>
> Even though 01 is " two valid hexadecimal characters", U+01 is not a
> valid URI character at that position.  Thus, the range of inferred
> zone IDs is (potentially) larger than the text implies.
>
> Browsers frequently accept (and display) URIs with unescaped parts.
> This is just another example of that common logic.  Thus, this might
> be phrased more simply as:
>
>Software that accepts URIs with unescaped portions can permit the
>entry of IPv6 addresses with an unescaped zone separator.
>
> This allows implementations to infer behaviour, which is probably OK
> in this context.
>
> s/proxy/intermediary/
>
> In the appendix, it might be worth noting that option 3 was selected.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-6man-uri-zoneid-05

[Martin Thomson]

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-uri-zoneid-05
Reviewer: Martin Thomson
Review Date: 2012-11-16
IETF LC End Date:  2012-11-26
IESG Telechat date: not scheduled

Summary:  This document is ready for publication as Proposed Standard,
with nits.

Nits/editorial comments:

The document could be made shorter by removing:

   We now present the necessary formal syntax.

   The 6man WG discussed and rejected an alternative in which the
   existing syntax of IPv6address would be extended by an option to add
   the ZoneID only for the case of link-local addresses.  It was felt
   that the present solution offers more flexibility for future uses and
   is more straightforward to implement.

This latter text might be put in the appendix, if it is necessary at
all.  The text in the security considerations is probably adequate.

The following statement implies "special" processing for zone IDs at user input:

   This document implies that all browsers should recognise a ZoneID
   preceded by an escaped "%".  In the spirit of "be liberal with what
   you accept", we also recommend that URI parsers accept bare "%" signs
   (i.e., a "%" not followed by two valid hexadecimal characters).  This
   makes it easy for a user to copy and paste a string such as
   "fe80::a%en1" from the output of a "ping" command and have it work.

Even though 01 is " two valid hexadecimal characters", U+01 is not a
valid URI character at that position.  Thus, the range of inferred
zone IDs is (potentially) larger than the text implies.

Browsers frequently accept (and display) URIs with unescaped parts.
This is just another example of that common logic.  Thus, this might
be phrased more simply as:

   Software that accepts URIs with unescaped portions can permit the
   entry of IPv6 addresses with an unescaped zone separator.

This allows implementations to infer behaviour, which is probably OK
in this context.

s/proxy/intermediary/

In the appendix, it might be worth noting that option 3 was selected.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-appsawg-media-type-suffix-regs-06

[Martin Thomson]

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-appsawg-media-type-suffix-regs-06
Reviewer: Martin Thomson
Review Date: 2012-10-16
IETF LC End Date: 2012-10-19
IESG Telechat date: 2012-10-25

Summary: This document is ready for publication as a (?) RFC.

Minor issues: Is BCP status really appropriate?  Informational seems
more appropriate for this sort of document.  The choice of providing a
modicum of guidance in Section 2, as opposed to in the RFC that
establishes the registry, could suggest this status, but that seems a
bit weak as motivation.

Nits:

+der doesn't even make a passing reference to +ber.  That's odd, since
one describes a subset of the other.

Mention of schema for +der and +ber doesn't seem relevant to the key
security consideration: that structures can be nested indefinitely.
This is possible regardless of what the schema says - a generic
processor is more likely to fall victim in that regard.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-snell-http-prefer-14

[Martin Thomson]

I have reviewed -15 of this draft and my major issues have been
resolved.  This document is ready.

On 21 September 2012 16:43, Martin Thomson  wrote:
> Lucky you.  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-snell-http-prefer-14
> Reviewer: Martin Thomson
> Review Date: 2012-09-21
> IETF LC End Date: 2012-10-12
>
> Summary: This document is in pretty good shape.  I have a concern over
> how Prefer: wait might be implemented that I believe needs to be
> addressed prior to publication as Proposed Standard.  There are also a
> number of additional concerns, though nothing particularly serious.
>
> Major issues:
>
> Section 3.4 specifies timing requirements that a server has to act
> upon with no good way of gaining the information it needs.  It assumes
> clock synchronization. Given that terrible clock synchronization is
> the default mode of operation for internet hosts, this seems to be a
> poor choice.
>
> In any case, this design forces a server to wait less than the allowed
> time in all cases, but gives the server no good information to choose
> an appropriate time adjustment.  A server has to assume that the
> client has already expended some period waiting.  Assuming that the
> client is going to abandon the request at the identified time, then
> the server is obliged to wait less than the entire period, lest the
> response be wasted.  Even if we assume that clocks are synchronized,
> the resolution of Date and wait are capped at a second, so worst case
> we have a 1 second window of uncertainty on when the request was sent.
>  This is worse if there are clock errors, particularly if the client
> clock runs ahead of the server.
>
> I can't see how I would implement this feature so that it behaves
> reliably for arbitrary hosts.
>
> On the other hand, the client has the ability to make its own
> determination about clock synchronization and network transit delays.
> A single request with wait=0 would provide a good measurement of total
> non-server delays, without any quantization noise (Date is rounded or
> trimmed to the second, which makes this determination difficult).  The
> client could then adjust the value of the wait preference to account
> for what it learns, with the server being able to then concentrate on
> the time elapsed between receipt and sending.  Clock differences are
> then irrelevant.
>
> Minor comments:
>
> In Section 3.2:
>
>When honoring the "return-representation" preference, the server MUST
>include a Content-Location header field specifying the URI of the
>resource representation being returned.
>
> This is a requirement that could be inadvertently violated by servers.
>  This really isn't what you are intending here.  The idea is to ensure
> that the returned representation doesn't get mistaken for a
> representation of the request URI, *when it is not*.  This does not
> require 2119 language to convey, though I would agree that a reminder
> is necessary here.  How about:
>
>The returned representation might not be a representation for the
> effective request
>URI [[this is the term du jour, I believe]] when the request
> affects another resource.
>The Content-Location header can be used to identify the URI of the returned
>representation.
>
> (I'd note that return-representation is less useful for PUT than POST
> or PATCH.  You don't mention PATCH at all.)
>
> In Sections 3.2 and 3.3, the mutual exclusivity of these parameters is
> handled differently to the strict/lenient parameters.  Instead of all
> the 2119 stuff, how about:
>
>The "return-minimal" and "return-representation" preferences are
>mutually exclusive directives.  A request that contains both preferences
>can be treated as though neither were specified.
>
> Alternatively, did you consider specifying a single preference here?
> i.e., Prefer: return=minimal and Prefer: return=representation
>
> Section 3.5, is it useful to observe that the "strict" preference is
> useful for ensuring that all aspects of a request are handled, so that
> recoverable errors don't result in important parts of a request being
> "missed" by a server?
>
> Did you consider a single preference here?  i.e., Prefer:
> processing=strict or Prefer: processing=lenient
>
> Regarding Section 3.5, which do we assume to be the existing behavior
> for a server?  strict or lenient?
>
> I'd ask a

[Gen-art] Gen-ART review of draft-snell-http-prefer-14

[Martin Thomson]

Lucky you.  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-snell-http-prefer-14
Reviewer: Martin Thomson
Review Date: 2012-09-21
IETF LC End Date: 2012-10-12

Summary: This document is in pretty good shape.  I have a concern over
how Prefer: wait might be implemented that I believe needs to be
addressed prior to publication as Proposed Standard.  There are also a
number of additional concerns, though nothing particularly serious.

Major issues:

Section 3.4 specifies timing requirements that a server has to act
upon with no good way of gaining the information it needs.  It assumes
clock synchronization. Given that terrible clock synchronization is
the default mode of operation for internet hosts, this seems to be a
poor choice.

In any case, this design forces a server to wait less than the allowed
time in all cases, but gives the server no good information to choose
an appropriate time adjustment.  A server has to assume that the
client has already expended some period waiting.  Assuming that the
client is going to abandon the request at the identified time, then
the server is obliged to wait less than the entire period, lest the
response be wasted.  Even if we assume that clocks are synchronized,
the resolution of Date and wait are capped at a second, so worst case
we have a 1 second window of uncertainty on when the request was sent.
 This is worse if there are clock errors, particularly if the client
clock runs ahead of the server.

I can't see how I would implement this feature so that it behaves
reliably for arbitrary hosts.

On the other hand, the client has the ability to make its own
determination about clock synchronization and network transit delays.
A single request with wait=0 would provide a good measurement of total
non-server delays, without any quantization noise (Date is rounded or
trimmed to the second, which makes this determination difficult).  The
client could then adjust the value of the wait preference to account
for what it learns, with the server being able to then concentrate on
the time elapsed between receipt and sending.  Clock differences are
then irrelevant.

Minor comments:

In Section 3.2:

   When honoring the "return-representation" preference, the server MUST
   include a Content-Location header field specifying the URI of the
   resource representation being returned.

This is a requirement that could be inadvertently violated by servers.
 This really isn't what you are intending here.  The idea is to ensure
that the returned representation doesn't get mistaken for a
representation of the request URI, *when it is not*.  This does not
require 2119 language to convey, though I would agree that a reminder
is necessary here.  How about:

   The returned representation might not be a representation for the
effective request
   URI [[this is the term du jour, I believe]] when the request
affects another resource.
   The Content-Location header can be used to identify the URI of the returned
   representation.

(I'd note that return-representation is less useful for PUT than POST
or PATCH.  You don't mention PATCH at all.)

In Sections 3.2 and 3.3, the mutual exclusivity of these parameters is
handled differently to the strict/lenient parameters.  Instead of all
the 2119 stuff, how about:

   The "return-minimal" and "return-representation" preferences are
   mutually exclusive directives.  A request that contains both preferences
   can be treated as though neither were specified.

Alternatively, did you consider specifying a single preference here?
i.e., Prefer: return=minimal and Prefer: return=representation

Section 3.5, is it useful to observe that the "strict" preference is
useful for ensuring that all aspects of a request are handled, so that
recoverable errors don't result in important parts of a request being
"missed" by a server?

Did you consider a single preference here?  i.e., Prefer:
processing=strict or Prefer: processing=lenient

Regarding Section 3.5, which do we assume to be the existing behavior
for a server?  strict or lenient?

I'd ask an IANA considerations expert to look at Section 4.1.  Did you
want something other than the strict letter of "Specification
Required"?

Nits:

The wording of Section 2.1 is a little contorted.  The second
paragraph is a single sentence.  "event just potentially" is a little
redundant.  Suggest a reword to cover just the key points:
 - Prefer is not intended to affect content negotiation.
 - If a preference could affect what a cache stores or how it stores
it [httpbis-p6], then the server MUST use Vary: Prefer.  This applies
even if the request does not include Prefer.
Caution is always good, but 

[Gen-art] Gen-ART review of draft-ietf-pce-hierarchy-fwk-04

[Martin Thomson]

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-pce-hierarchy-fwk-04
Reviewer: Martin Thomson
Review Date: 2012-09-23
IETF LC End Date: 2012-08-24
IESG Telechat date: -

Summary:
This document is ready for publication as an Informational RFC.

Nits:
I think that you probably meant to have the second letter of
"Antonymous System" rotated 180 degrees.  This appears several times.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GenART review of draft-ietf-storm-iscsi-sam-06

[Martin Thomson]

David,

I think that you successfully covered most of the concerns.  I fully
expected there to be a number of decisions that would be immutable for
that reason.  I'll look for the update.

--Martin

On 13 August 2012 14:32, Black, David  wrote:
> Martin,
>
> Thank you very much for this review - you found a number of things
> that need attention, but there are also a few comments that
> (probably unbeknownst to you) represent design decisions that
> cannot be revisited courtesy of the amount of deployed iSCSI
> "running code".
>
> Responses are inline below.
>
> Thanks,
> --David
>
>> -Original Message-
>> From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of
>> Martin Thomson
>> Sent: Tuesday, July 24, 2012 6:54 PM
>> To: draft-ietf-storm-iscsi-sam@tools.ietf.org; gen-art@ietf.org
>> Subject: [Gen-art] GenART review of draft-ietf-storm-iscsi-sam-06
>>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>>
>> Document: draft-ietf-storm-iscsi-sam-06
>> Reviewer: Martin Thomson
>> Review Date: 2012-07-24
>> IESG Telechat date: ?
>>
>> Summary: This document has a few issues that would need to be
>> addressed before it is published as a Standards Track RFC.
>>
>> Major Issues: None
>>
>> Minor Issues:
>>
>> Is the intent to reference RFC 3720 or the new -cons draft (as
>> published)?  Given that -cons is intended to obsolete 3720, I would
>> have expected no reference to 3720 at all.
>
> That's a correct expectation, and results from some confusion over what the
> final status of RFC 3720 would be.  As RFC 3720 is being obsoleted by the
> -cons draft, RFC3720 cannot be normatively referenced by either the -sam or
> -cons drafts, and hence most of the citations in the body of the -sam draft
> need to be to the -cons draft.
>
>> Section 5.1 / 5.1.1 does not define how many bits the PRI field
>> consumes.  I might infer from the diagram that is the four most
>> significant bits of the second byte, but the diagram is unclear.  In
>> any case, the diagram should only be used for illustrative purposes
>> and the text should provide the definitive answer.
>>
>> Section 5.2.1 also relies on the diagram.  Though in this case it is
>> clearer and I can easily infer that the status qualifier is one byte,
>> I'm still relying on the diagram.
>
> These two are minor, but I have no problem with changing them as suggested.
>
>> Why is Section 6.2.1 not Section 5.1.2?  Same for 6.2.2 and 6.2.3.
>> Aren't these new (?) additions to the Command PDU?  Or is there
>> another PDU that these apply to?
>
> There's another PDU that these apply to, the Task Management Function
> Request PD - its layout diagram needs to be copied into the -sam
> draft from section 11.5 of the -cons draft so that the -sam draft is
> somewhat more self-contained.
>
>> Section 7.1.1 What does it mean to not claim support for any
>> particular level?  Obviously you can't use the features described
>> here, but what else?
>
> It just means that the system is running "iSCSI" without providing
> any additional details.  The ability to announce support without
> claiming support for any particular level is a SCSI feature that is
> applied to all SCSI-related standards.  The other party in the
> communication needs to make least common denominator assumptions
> about supported functionality, subject to further checks that may
> provide additional information (e.g., iSCSI text key negotiation,
> read a particular SCSI VPD page).
>
>> Section 8 makes a bold claim that needs substantiation.  Given the
>> global nature of task identifiers, is it necessary to prevent one user
>> from querying a task that another created?
>
> No it is not - to the extent that iSCSI has a notion of user, that
> notion is session-wide across all connections.
>
>> What about triggering reset on a I_T nexus that another user is using?
>
> The I_T NEXUS RESET function in the -sam draft can't do that because that
> function is reflexive - it resets the I_T nexus on which the function is
> sent.  Yes, this really is a SCSI version of "shoot yourself in the foot"
> :-) and it is useful because target systems generally respond by cleaning
> out all of the state related to the nexus which can clean up some situations.

[Gen-art] GenART review of draft-ietf-storm-iscsi-sam-06

[Martin Thomson]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-storm-iscsi-sam-06
Reviewer: Martin Thomson
Review Date: 2012-07-24
IESG Telechat date: ?

Summary: This document has a few issues that would need to be
addressed before it is published as a Standards Track RFC.

Major Issues: None

Minor Issues:

Is the intent to reference RFC 3720 or the new -cons draft (as
published)?  Given that -cons is intended to obsolete 3720, I would
have expected no reference to 3720 at all.

Section 5.1 / 5.1.1 does not define how many bits the PRI field
consumes.  I might infer from the diagram that is the four most
significant bits of the second byte, but the diagram is unclear.  In
any case, the diagram should only be used for illustrative purposes
and the text should provide the definitive answer.

Section 5.2.1 also relies on the diagram.  Though in this case it is
clearer and I can easily infer that the status qualifier is one byte,
I'm still relying on the diagram.

Why is Section 6.2.1 not Section 5.1.2?  Same for 6.2.2 and 6.2.3.
Aren't these new (?) additions to the Command PDU?  Or is there
another PDU that these apply to?

Section 7.1.1 What does it mean to not claim support for any
particular level?  Obviously you can't use the features described
here, but what else?

Section 8 makes a bold claim that needs substantiation.  Given the
global nature of task identifiers, is it necessary to prevent one user
from querying a task that another created?  What about triggering
reset on a I_T nexus that another user is using?

Questions (for -cons):

Section 6.2 makes the following requirement:
   If the connection is still active (it is not undergoing an
   implicit or explicit logout), QUERY TASK MUST be issued on the
   same connection to which the task to be queried is allegiant at
   the time the Task Management request is issued. If the
   connection is implicitly or explicitly logged out (i.e., no other
   request will be issued on the failing connection and no other
   response will be received on the failing connection), then a
   QUERY TASK function request may be issued on another connection.
   This Task Management request will then establish a new allegiance
   for the command being queried.

The comment is probably more for of -cons (Section 4.2.5.1 and Section
7.2.2).  Obviously, this design is long-standing, and I'm only reading
parts of the specification.

There is an implication that tasks have identification that is
globally unique, even if the normal behaviour is to bind (ally) a
request with a connection.  The reasons for allowing this are not
explained, but it imposes some fragility on the system.  For instance,
the requirement that the old connection be closed with a "remove the
connection for recovery" seems counter to the goal of failure
recovery.  If the point of this is for failure recovery, then a
primary failure mode would be network failure - in which case this
mechanism cannot be used.

What purpose does this allegiance feature address?

What are the security implications of using allegiance?

Nits:

I don't know what tooling was used to generate this document, but
there are some strange artifacts.  In particular, diagrams and tables
are misaligned in a number of places.

There are a few terms like "I_T nexus" that are not explained prior to
use.  These are defined in -cons.  However, I find the existence of a
terminology mapping table in this draft to be strange.  Wouldn't that
table be more useful in the "core" document?

Section 4.1:

This seems unnecessarily convoluted:

  Note that an operational value of "2" or higher for this key on
  an iSCSI session does not influence the SCSI level features in
  any way on that I_T nexus. An operational value of "2" or higher
  for this key permits the iSCSI-related features defined in this
  document to be used on all connections on this iSCSI session.
  SCSI level hand-shakes (e.g. commands, mode pages) eventually
  determine the existence or lack of various SAM-5 features
  available for the I_T nexus between the two SCSI end points). To
  summarize, negotiation of this key to "2" or higher is a
  necessary but not a sufficient condition of SAM-5 compliant
  feature usage at the SCSI protocol level.

How about:

  In addition to negotiating a value of "2" or higher, support for an individual
  MUST also be signaled using SCSI level hand-shakes prior to use.

I know that adds 2119 language, but if the goal is to prevent someone
from attempting to use a feature prior to getting positive
confirmation of support, then this should be ok.

Section 6.2 describe

Re: [Gen-art] Gen-ART LC review of RFC2818

[Martin Thomson]

On 8 June 2012 00:33, Brian E Carpenter  wrote:
> Please see attached review. I haven't cc'ed the IETF or IESG since
> my comment is only a process issue, but this can be forwarded as you
> think fit. If the IESG can see a way round it consistent with RFC 2026,
> that would be fine by me.

The "Updates" in RFC 5785 is an error, as noted in an erratum on that document.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-melnikov-smtp-priority-tunneling-02

[Martin Thomson]

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-melnikov-smtp-priority-tunneling-02
Reviewer: Martin Thomson
Review Date: 2012-06-08
IETF LC End Date: 2012-07-02
IESG Telechat date: (if known)

Summary: This document is ready for publication as an Experimental
RFC, with one question.

Major issues: None

Minor issues:
I'm not sure that I agree with the SHOULD strength requirement on MSAs
or MTAs to strip mt-priority headers.  There's a marked difference
between failure to meet local preconditions for compliance and
whatever conditions some other MTA might place on mt-priority
observance.  GIven that each hop is expected to make their own
determination about priority anyway, what benefit is there in removing
information that might inform that choice?

Nits/editorial comments:
Section 7, check grammar: "within a close environment) ."
Section 7.1: I don't like statements like "has pros and cons" without
any guidance.  The pros and cons are probably easy to describe (they
seem intuitively obvious), so they are either important enough to
describe or not worth mentioning at all.  Either is better than the
tease.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Fwd: Gen-ART review of draft-ietf-tcpm-tcpmss-04

[Martin Thomson]

Feature request for the tool: a place to put reviews so that I don't
keep forgetting to CC the gen-art list.

-- Forwarded message --
From: Martin Thomson 
Date: 20 May 2012 19:34
Subject: Gen-ART review of draft-ietf-tcpm-tcpmss-04
To: draft-ietf-tcpm-tcpmss@tools.ietf.org


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-tcpmss-04
Reviewer: Martin Thomson
Review Date: 2012-05-20
IETF LC End Date:
IESG Telechat date: (if known)

Summary: This draft clarifies a point of potential confusion around
the use of the TCP MSS.  The draft is ready for publication as an
informational RFC, with a couple of nits.

Major issues: none

Minor issues: none

Nits/editorial comments:

Opinion... The draft seems a little long.  Section 4 contains the only
truly crucial point: namely the one made after the matrix.  That
alone, plus the short description in Section 2, seems sufficient. The
appendix is excessive.

Section 6 does not contain security considerations.  It need not
contain anything.

Sections 3 and 5 have extra indentation for their subsections.

The table in Section 4 has a wayward period.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review: draft-ietf-marf-as-13

[Martin Thomson]

Look, this really doesn't bother me that much.  But I can't even
imagine what a sensible implementation would do for these two points.
I don't like 2119 language that I can't see how to comply with.

Maybe I'm just not imaginative enough.

On 13 April 2012 12:14, Murray S. Kucherawy  wrote:
>> Section 6.1, point 1 cannot be an interoperability requirement if there
>> isn't a mechanism provided.
> Existing implementations generally support this capability, but they all have 
> different ways of doing so.  Thus, there's (currently) no standard way to do 
> it.  Our ADs thus suggested the text that's there.

It's the unsolicited case that bothers me here.  Is there some sort of
general advice that can be given on how to implement this for an
unsolicited report? Or are these existing implementations so radically
different that is tricky?  (That would be interesting in and of
itself.)

>> Section 6.3, point 1 has the same complaint for the "SHOULD", though in
>> this case the softness of the "SHOULD" makes this more tolerable.
>
> The choice to deviate means the benefits described later in that point's text 
> are lost.  That's the tradeoff.

Again, I'm less concerned with the why, but the how.

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

Re: [Gen-art] [marf] Gen-ART review: draft-ietf-marf-as-13

[Martin Thomson]

On 13 April 2012 14:05, Barry Leiba  wrote:
> The advantage here is that the AS is a standards-track document, and
> will progress along the standards track just as a Technical
> Specification would.  Making it Information loses that aspect.

It wouldn't make sense for this to be made informational.  There are
too many all-caps words.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review: draft-ietf-marf-as-13

[Martin Thomson]

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-marf-as-13
Reviewer: Martin Thomson
Review Date: 2012-04-12
IETF LC End Date:
IESG Telechat date: (if known)

Summary: This document is fit for publication, though some minor
issues might warrant further consideration.

Major issues: None

Minor issues:

Reading through, this doesn't smell very much like an applicability
statement at all.  It has the distinct odor of a profile, or a set of
implementation/deployment/operational guidelines.  That might just be
me.

Section 4.2 doesn't really contain enough information for me to
determine when I might want to ignore your SHOULD.

Section 6.1, point 1 cannot be an interoperability requirement if
there isn't a mechanism provided.  The text is perfectly clear, but I
can't implement anything here to address the "MUST".  The problem is
that the reports are unsolicited, and therefore an out-of-band
"session" has not been established between providers. (Is an abuse
report the in-band solution you are looking for?  Yes, Section 7,
point 2, I know...)

Section 6.3, point 1 has the same complaint for the "SHOULD", though
in this case the softness of the "SHOULD" makes this more tolerable.

Nits/editorial comments:

Expand on first use: MUA, SPF, DKIM.

Parentheses around references is excessive ([CITE]).

Section 5.2, point 2 is a bit of a truism...MUST support optional
fields being optional.  Is it really necessary?

Section 6.3, point 3, sentence 2: missing comma after "([RFC3912])"

Section 6.4, point 3, did not parse: "reports are generated with use
by recipients not using"

Section 6.5, point 3 could be made MUST NOT by saying "MUST NOT reject
non-ARF messages based solely on the format" or by adding other
qualifications to that effect.  Obviously this has to allow for local
policy that rejects messages on other criteria, but you can make a
requirement like this.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GenART review of draft-ietf-pwe3-redundancy-06

[Martin Thomson]

Thanks! Looks good.

On 11 April 2012 09:31, Bocci, Matthew (Matthew)
 wrote:
> Martin,
>
> On 11/04/2012 16:55, "Martin Thomson"  wrote:
>
>>On 11 April 2012 06:44, Bocci, Matthew (Matthew)
>> wrote:
>>> MB> Yes, it's really the communication mechanisms. Those details are
>>> specified in the separate, standards-track,
>>> draft-ietf-pwe3-redundancy-bit, which does impact interoperability.
>>> Therefore I propose updating this sentence to clarify what is out of
>>> scope.
>>> "The mechanism for communicating the preferential forwarding status are
>>> outside the scope of this document. "
>>
>>Since you have the reference, is the reason you don't want to
>>reference it that you don't want a downref?
>
> MB> No. This is a framework/requirements document, and
> the WG made a specific decision early on to separate this from the
> mechanism used to convey preferential forwarding status.
>
>
>>
>>>>Section 4.1: "Non-revertive behavior MUST be supported, while
>>>>revertive behavior is OPTIONAL."
>>>>
>>>>The reason for this requirement is non-obvious (at least to me).  Some
>>>>justification for it seems appropriate.
>>>
>>> MB> This is an operator requirement to ensure that the protocols
>>>developed
>>> in support of PW redundancy at least support non-revertive operation as
>>>a
>>> baseline. To implement a revertive behaviour, you will need to designate
>>> one of the Pws
>>
>>So you had a choice: one mandatory, but which; or both mandatory.  The
>>WG chose non-revertive as the only mandatory option.  I guess I was
>>(obliquely) requesting that you provide motivation in the document,
>>rather than just in response to my mail.
>
>
> MB> I propose modifying the paragraph as follows:
>
>  o  Non-revertive behavior MUST be supported, while revertive behavior
>      is OPTIONAL. This avoids the need to designate one PW as primary
> unless revertive
> behavior is explicitly required.
>
>
>>
>>>>Section 4.1:    "Protection switchover can be triggered by the operator
>>> MB> This requirement does have a protocol implication, both in terms of
>>> the state machine and the ability to coordinate the state at both PEs in
>>> the case
>>> that a manual switchover is initiated from only one PE.
>>
>>The process that you describe doesn't address that requirement.  That
>>process ensures that operator intervention doesn't cause a failure by
>>ensuring that the operator is unable to disable a redundant PW by
>>removing the only active path.  From the protocol perspective, you
>>need a mechanism for signaling that a path is being administratively
>>disabled.
>>
>>So:
>>
>>Requirement: Protection switchover can be initiated by either PE.
>>Motivation: Operator intervention may be necessary to disable one part
>>of a redundant PW.
>>
>>Product requirement: Operator intervention shall not be able to
>>disable a PW by disabling the only available part of a redundant PW.
>>
>>(Excuse the sloppy terminology, it's been a while and I'm too lazy to
>>get this right.)
>>
>>I don't have any real problem with your explanations, but it seems to
>>me at least that it could be made clearer.  Don't feel obligated to
>>change on my accord alone, but there are value in being really clear
>>about these requirements.
>
> MB> I propose modifying the paragraph as follows:
>
>  o  Protection switchover can be initiated from a PE e.g. using
>      a Manual lockout/force switchover, or it may be triggered by a
>      signal failure i.e. a defect in the PW or PSN. Manual switchover may
> be necessary
> if it is required to disable one PW in a redundant set. Both methods MUST
>      be supported and signal failure triggers MUST be treated with a
>      higher priority than any local or far-end manual
>      trigger.
>
>
> Regards
>
> Matthew
>
>
>>
>>--Martin
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GenART review of draft-ietf-pwe3-redundancy-06

[Martin Thomson]

On 11 April 2012 06:44, Bocci, Matthew (Matthew)
 wrote:
> MB> Yes, it's really the communication mechanisms. Those details are
> specified in the separate, standards-track,
> draft-ietf-pwe3-redundancy-bit, which does impact interoperability.
> Therefore I propose updating this sentence to clarify what is out of
> scope.
> "The mechanism for communicating the preferential forwarding status are
> outside the scope of this document. "

Since you have the reference, is the reason you don't want to
reference it that you don't want a downref?

>>Section 4.1: "Non-revertive behavior MUST be supported, while
>>revertive behavior is OPTIONAL."
>>
>>The reason for this requirement is non-obvious (at least to me).  Some
>>justification for it seems appropriate.
>
> MB> This is an operator requirement to ensure that the protocols developed
> in support of PW redundancy at least support non-revertive operation as a
> baseline. To implement a revertive behaviour, you will need to designate
> one of the Pws

So you had a choice: one mandatory, but which; or both mandatory.  The
WG chose non-revertive as the only mandatory option.  I guess I was
(obliquely) requesting that you provide motivation in the document,
rather than just in response to my mail.

>>Section 4.1:    "Protection switchover can be triggered by the operator
> MB> This requirement does have a protocol implication, both in terms of
> the state machine and the ability to coordinate the state at both PEs in
> the case
> that a manual switchover is initiated from only one PE.

The process that you describe doesn't address that requirement.  That
process ensures that operator intervention doesn't cause a failure by
ensuring that the operator is unable to disable a redundant PW by
removing the only active path.  From the protocol perspective, you
need a mechanism for signaling that a path is being administratively
disabled.

So:

Requirement: Protection switchover can be initiated by either PE.
Motivation: Operator intervention may be necessary to disable one part
of a redundant PW.

Product requirement: Operator intervention shall not be able to
disable a PW by disabling the only available part of a redundant PW.

(Excuse the sloppy terminology, it's been a while and I'm too lazy to
get this right.)

I don't have any real problem with your explanations, but it seems to
me at least that it could be made clearer.  Don't feel obligated to
change on my accord alone, but there are value in being really clear
about these requirements.

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

Re: [Gen-art] Gen-ART review of draft-george-travel-faq-03

[Martin Thomson]

-05 is good.

On 10 February 2012 10:15, Martin Thomson  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-george-travel-faq-03
> Reviewer: Martin Thomson
> Review Date: 2012-02-10
> IETF LC End Date: 2012-03-06
> IESG Telechat date: ?
>
> Summary: Ready
>
> Major issues: none
>
> Minor issues: none
>
> Nits/editorial comments:
> List construction throughout is a little haphazard. Check
> capitalization in particular.
> s/Souvenier/Souvenir/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GenART review of draft-ietf-pwe3-redundancy-06

[Martin Thomson]

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-pwe3-redundancy-06
Reviewer: Martin Thomson
Review Date: 2012-03-15
IETF LC End Date: 2012-03-21
IESG Telechat date: (if known)

Summary: The draft has some minor issues.

Major issues: none

Minor issues:

3.2.2 states: "The mechanisms for achieving this selection are outside
the scope of this document."

The example then describes the _conditions_ under which the selection
is made.  So the statement doesn't quite make sense.  It's reasonable
to presume that a standard doesn't prescribe the internal behaviour of
a PE where interoperability is no concern.  Even though this is just
an example, it makes a very specific presumption about the behaviour
of the PE in reaction to an event.  I can't imagine any other reaction
in this case, so I'm left wondering: what exactly is out of scope for
this?  Communication of the event between PE1 and PE2?

Section 4.1: "Non-revertive behavior MUST be supported, while
revertive behavior is OPTIONAL."

The reason for this requirement is non-obvious (at least to me).  Some
justification for it seems appropriate.

Section 4.1:"Protection switchover can be triggered by the operator [...]"

Again, justification would be nice.  This actually smells more like a
product specification that requirement for interoperability.  If the
requirement is, as I suspect, that switchovers triggered by manual
intervention can be marked as such in the protocol _so that they can
be treated with lower priority_, then that is definitely
understandable.

Section 4.2:"[...] MUST support the configuration of revertive or
non-revertive protection switching modes."

If revertive switching is optional, then this requirement makes not
sense for (T-)PEs that don't implement it.

Nits:
The figures are somewhat difficult to read overall.  It's unclear what
significance is attached to the dots in many of the diagrams, since
they aren't always consistent (see Figure 3).
Figure 5 is especially difficult to read.  Another instance is the
choice of '.' or '|' in Figure 4, which could have some significance,
but probably doesn't because the usage is quite inconsistent.  Having
labels for lines/tunnels impinge on boxes is difficult to interpret.
Reducing the noise in the diagrams would help.  The text is adequate
to make up the shortfall.  (Figure 7 is perfectly clear.)

Labeling of PEs in 3.2.2 makes it hard to follow because PE2 is
attached to CE2.  I'd suggest renames such that you have {CE1, PE1a,
PE1b} and likewise.

The first requirement in 4.1 is missing a couple of spaces (after the
comma, in "besupported").

4.2 has an empty bullet.

Not expanded on first use: PSN, LDP
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art