Re: [Gen-art] Genart last call review of draft-ietf-cellar-ffv1-16

[Spencer Dawkins at IETF]

Hi, Joel,

On Mon, Jul 13, 2020 at 11:17 PM Joel Halpern via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Joel Halpern
> 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 treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-cellar-ffv1-16
> Reviewer: Joel Halpern
> Review Date: 2020-07-13
> IETF LC End Date: 2020-07-16
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This document appears to be ready for publication as an
> Informational
> RFC.
>
> *I would have raised question about the intended status, but it appears
> that
> this is an established IETF convention and I see no reason to argue.)
>
> Major issues:
>
> Minor issues:
> Section 3.4 (Context) introduces the notation Q_{#}[ subscript }.  As
> that
> is the first reference to Q_{#}, it is rather confusing to the
> reader.  I
> grant that the term is defined in the next section (3.5).  Couldn't
> they be
> reversed?
>
> Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are these all the same
> thing.
>
> Section 3.8.1.2 refers to get-rac (which is treated as a function in
> the
> pseudo-code) as being the process described in section 3.8.1.1.  The
> text
> in 3.8.1.1 does not call out any of its computed values as an explicit
> result or return.  While I would guess that the intention is to use the
> byte stream (B()), the text does not actually say that.  If that is the
> intention, could the last line of 3.8.1.1 be "get_rac() returns
> sequential
> bytes from the Byte Stream (B()) as computed by the computation
> described
> in section 3.8.1.1"?
>
> Nits/editorial comments:
>

Thanks for the review! We'll work through these comments.

Best,

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

Re: [Gen-art] [Taps] Genart last call review of draft-ietf-taps-minset-06

[Spencer Dawkins at IETF]

Hi, Michael,

On Fri, Aug 31, 2018, 15:35 Michael Welzl  wrote:

> Hi Spencer,
>
> See below:
>
> On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
> Thanks, Robert, for the careful read, and thanks, Michael, for the quick
> response. I have one thought, on Robert's last question.
>
> On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl  wrote:
>
>> Hi,
>>
>> Thank you very much for this careful review!  We just posted a revision (
>> -07 ) that, we believe, addresses these comments.
>>
>> A few answers in line below:
>>
>> > On 28 Aug 2018, at 23:38, Robert Sparks  wrote:
>> >
>> > Reviewer: Robert Sparks
>> > Review result: Ready with Nits
>
>
> ...
>
>
>> > In Appendix A.1, this document had to "slightly change" the
>> > characterization of features  from those in RFC8303, introducing this
>> > "ADDED" construct. That feels out of balance. Is this a warning sign
>> > that RFC8303 needs adjusting?
>>
>> It isn't: different from this document, RFC 8303 does not make any
>> changes or derive anything from the services that protocols offer - it just
>> reflects what the protocol specifications say.
>>
>> In the minset document, there are only 3 items using the "ADDED"
>> construct, and this is only meant to streamline the derivation a little.
>> Take "Unreliably transfer a message", for example.
>> This is based on (from RFC 8303) "Unreliably transfer a message, with
>> congestion control" for SCTP, and "Unreliably transfer a message, without
>> congestion control" for UDP(-Lite). The added "Unreliably transfer a
>> message" leaves the choice of congestion control open, such that an
>> application CAN simply say "Unreliably transfer a message" without having
>> to care about the choice of congestion control (unless it wants to care,
>> which comes at the cost of binding itself to either UDP(-Lite) or SCTP).
>>
>
> Michael, this explanation helps a lot, but since I happen to know that
> Robert is out of town for the three-day weekend in the US, I'll guess on
> his behalf that "ADDED" may not be the word you're looking for - at a
> minimum, "transfer unreliably" in RFC 8303 being divided into "transfer
> unreliably with congestion control" and "transfer unreliably without
> congestion control" in this draft doesn't look like addition to me.
>
> Is this more about "refactoring the protocol-independent definition in RFC
> 8303”?
>
>
> Yes, “refactoring” is exactly right - it’s not adding anything new. We
> could just as well have left this without the “ADDED” cases and then had
> more explanations in the “discussions” section (appendix A.3), but these
> are so minor that they don’t really merit a “discussion”, hence we felt
> that this way it’s shorter and clearer.
>
> If that helps, I can rename “ADDED” into “REFACTORED”?
>

I'll let you and Robert resynchronize on this, now that I think you'll be
talking about the same thing.

I'll watch, if I'm needed, of course.

Spencer

Cheers,
> Michael
>
> But, whatever it is, if you two can figure out how to describe what's
> happening, that will probably help figure you and Robert agree on an
> understanding about how to handle his comment.
>
> Spencer
>
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Taps] Genart last call review of draft-ietf-taps-minset-06

[Spencer Dawkins at IETF]

Thanks, Robert, for the careful read, and thanks, Michael, for the quick
response. I have one thought, on Robert's last question.

On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl  wrote:

> Hi,
>
> Thank you very much for this careful review!  We just posted a revision (
> -07 ) that, we believe, addresses these comments.
>
> A few answers in line below:
>
> > On 28 Aug 2018, at 23:38, Robert Sparks  wrote:
> >
> > Reviewer: Robert Sparks
> > Review result: Ready with Nits





> > In Appendix A.1, this document had to "slightly change" the
> > characterization of features  from those in RFC8303, introducing this
> > "ADDED" construct. That feels out of balance. Is this a warning sign
> > that RFC8303 needs adjusting?
>
> It isn't: different from this document, RFC 8303 does not make any changes
> or derive anything from the services that protocols offer - it just
> reflects what the protocol specifications say.
>
> In the minset document, there are only 3 items using the "ADDED"
> construct, and this is only meant to streamline the derivation a little.
> Take "Unreliably transfer a message", for example.
> This is based on (from RFC 8303) "Unreliably transfer a message, with
> congestion control" for SCTP, and "Unreliably transfer a message, without
> congestion control" for UDP(-Lite). The added "Unreliably transfer a
> message" leaves the choice of congestion control open, such that an
> application CAN simply say "Unreliably transfer a message" without having
> to care about the choice of congestion control (unless it wants to care,
> which comes at the cost of binding itself to either UDP(-Lite) or SCTP).
>

Michael, this explanation helps a lot, but since I happen to know that
Robert is out of town for the three-day weekend in the US, I'll guess on
his behalf that "ADDED" may not be the word you're looking for - at a
minimum, "transfer unreliably" in RFC 8303 being divided into "transfer
unreliably with congestion control" and "transfer unreliably without
congestion control" in this draft doesn't look like addition to me.

Is this more about "refactoring the protocol-independent definition in RFC
8303"?

But, whatever it is, if you two can figure out how to describe what's
happening, that will probably help figure you and Robert agree on an
understanding about how to handle his comment.

Spencer
___
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-tsvwg-rfc4960-errata-06

[Spencer Dawkins at IETF]

FWIW,

On Thu, Jun 7, 2018 at 5:33 AM Gorry Fairhurst  wrote:

> +1, as Chair. I see we have caused a little confusion here - The WG will
> not repeat this list of changes again as a part of the new .bis document.
>
> There could always be potentially be further changes as the .bis
> document passes through the WG - of course - but we'd rather expect this
> spec is mature -- indeed there was suggestion the final Spec could
> progress to Full Standard (to be confirmed of course).
>

Thanks, Michael and Gorry, for clarifying this.

I think everyone who lived through 4460 and 4960 knew this, and no one one
who didn't live through that knew it, so that's very helpful.

Spencer


> Gorry
>
> On 07/06/2018, 11:19, Michael Tuexen wrote:
> >> On 7. Jun 2018, at 02:43, Christer Holmberg<
> christer.holmb...@ericsson.com>  wrote:
> >>
> >>
> >> Hi,
> >>
>  Not a comment on the document, but a question/suggestion:
> 
>  If you want to have a place holder for changes to be done in the bis
>  (which seems to be the main purpose of the errata document), why not
>  create a GitHub repo for the bis, and then document everything as
> GitHub
>  issues? Then, when you start working on the bis, you can map each
> issue
>  to
>  a pull request etc.
> >>> We did use a github report using issues which working on this document.
> >>>
> >>> Replacing this document with an github issue tracker doesn't seem
> >>> attraktive to me. Github can go away at any time or gets replaced
> >>> by other tools and than the information would not be accessible
> >>> anymore. Please note that we document the changes and the reasoning
> >>> not for us, but for developers which are interested in it in the
> >>> future.
> >> Sure, but my understanding is that the future, i.e., the bis document,
> is
> >> coming soon, and I guess the bis document will anyway describe the
> changes
> >> (and the reasons) compared to RFC 4960.
> > Hi Christer,
> >
> > no it doesn't. It will be basically RFC 4960 + the diff from the errata
> > document applied.
> >
> > We did this in the past. See
> > RFC 2960 as the initial specification of SCTP.
> > RFC 4460 as an errata document
> > RFC 4960 as the updated specification of SCTP.
> >
> > As you see, RFC 4960, does not tell you what has changed or why.
> > If a developer is not interested in that and just wants to
> > implement SCTP, only the reading on RFC 4960 is needed. If
> > someone wants to understand the changes, he can read RFC 4460.
> >
> > Best regards
> > Michael
> >> Anyway, since I haven’t been involved in the work, I don’t want to argue
> >> about the way the WG is working. It was just a question/suggestion :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
>  Regards,
> 
>  Christer
> 
>  On 04/06/18 13:13, "Gen-art on behalf of Christer Holmberg"
>   >
>  wrote:
> 
> > Hi Gorry,
> >
> > ...
> >
> >> The information in this document does not update RFC4640 or the
> Errata
> >> to that specification.  The document is instead provided as input to
> >> preparation of a new document that is expected to be a
> standards-track
> >> replacement for RFC4960. If approved, the replacement document will
> >> incorporate the updates described here and any other changes needed
> to
> >> allow this to progress this specification along the standards track.
> > I am ok with the two first sentences.
> >
> > But, I don’t think you can make the last sentence. This document
> cannot
> > normatively define text for the replacement document, or assume that
> > everything will be incorporated: the WG will have to agree on what
> goes
> > into the replacement document once it has been added to the charter
> > etc,
> > using normal IETF procedures.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
>  On 03/06/18 21:59, "Gen-art on behalf of Paul Kyzivat"
>  
> wrote:
> 
> > [[INCOMPLETE, NOT READY TO SEND. PLEASE IGNORE]]
> >
> > 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
> > <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-tsvwg-rfc4960-errata-06
> > Reviewer: Paul Kyzivat
> > Review Date: 2018-06-03
> > IETF LC End Date: 2018-06-04
> > IESG Telechat date: ?
> >
> > Summary:
> >
> > This draft is on the right track but has open issues, described
> in
> > the
> > review.
> >
> > Issues:
> >
> > Major: 1
> > Minor: 2
> > Nits:  1
> 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc4960-errata-06

[Spencer Dawkins at IETF]

Just chiming in as AD ...

On Mon, Jun 4, 2018 at 7:18 AM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:

> Hi,
>
> >>> The information in this document does not update RFC4640 or the Errata
> >>> to that specification.  The document is instead provided as input to
> >>> preparation of a new document that is expected to be a standards-track
> >>> replacement for RFC4960. If approved, the replacement document will
> >>> incorporate the updates described here and any other changes needed to
> >>> allow this to progress this specification along the standards track.
> >> I am ok with the two first sentences.
> >>
> >> But, I don’t think you can make the last sentence. This document cannot
> >> normatively define text for the replacement document, or assume that
> >> everything will be incorporated: the WG will have to agree on what goes
> >> into the replacement document once it has been added to the charter etc,
> >> using normal IETF procedures.
> >And it wouldn't say those exact words of course!
> >
> >If I carefully composed actual text, it would be IETF-compliant;-)
>
> Great! :)
>

Your AD agrees with adding words like the ones you're discussing here, once
you figure out exactly what words should be added.

Spencer


>
> All I want is to avoid a situation where someone laters suggests some
> modified text for the bis, and the reply is that the text in the errata
> draft has already been agreed upon by the WG to be included in the bis.
>
> Regards,
>
> Christer
>
>
>
> > On 03/06/18 21:59, "Gen-art on behalf of Paul Kyzivat"
> >  wrote:
> >
> >> [[INCOMPLETE, NOT READY TO SEND. PLEASE IGNORE]]
> >>
> >> 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
> >> <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>..
> >>
> >> Document: draft-ietf-tsvwg-rfc4960-errata-06
> >> Reviewer: Paul Kyzivat
> >> Review Date: 2018-06-03
> >> IETF LC End Date: 2018-06-04
> >> IESG Telechat date: ?
> >>
> >> Summary:
> >>
> >> This draft is on the right track but has open issues, described in
> >>the
> >> review.
> >>
> >> Issues:
> >>
> >> Major: 1
> >> Minor: 2
> >> Nits:  1
> >>
> >> 1) MAJOR:
> >>
> >> The format of this document disturbs me. According to the abstract:
> >>
> >>  ... This
> >>  document provides deltas to RFC4960 and is organized in a time
> >>  ordered way.  The issues are listed in the order they were
> >>brought
> >>  up.  Because some text is changed several times the last delta
> >>in
> >> the
> >>  text is the one which should be applied.
> >>
> >> This format makes the document hard to deal with. A developer who
> >> wants
> >> to implement sctp with some or all of the errata fixes will want to
> >> work
> > >from a variant of 4960 that incorporates all of those fixes - a bis.
> > But
> >> it isn't clear how this document helps with that. I don't think you
> >> can
> >> start with 4960 and simply apply all the deltas sequentially,
> >>because
> >> overlapping changes won't work right.
> >>
> >> A developer won't be interested in the order in which errata were
> >> reported. An actual bis document would be more useful to a developer
> >> than this format. Is that not being done because doing so would be
> >> more
> >> difficult? Or because it isn't yet certain that these are the
> >>correct
> >> fixes?
> >>
> >> I think you should give some serious consideration of the most
> >> suitable
> >> form for this document, in the context of how it is intended to be
> >> used.
> >>
> >> 2) MINOR (maybe MAJOR):
> >>
> >> Discovering where one change is impacted by another change is hard..
> >>
> >> I dug into the details of the document to understand how many places
> >> there are actually overlaps between the changes in multiple
> >>sections.
> >> (It took a lot of work to do this.) I found five of these:
> >>
> >> - 3.1 / 3.23
> >> - 3.3 / 3.43
> >> - 3.5 / 3.10
> >> - 3.6 / 3.23
> >> - 3.24 / 3.32
> >>
> >> (I don't guarantee that this list is exhaustive.)
> >>
> >> Of these, I think only one (3.1/3.23) explicitly indicates the
> >> conflict,
> >> and it only indicates it within 3.23.
> >>
> >> Most of the changes don't have any conflicts. And some of the
> >> conflicts
> >> could be removed by being more precise in indicating the change
> >>being
> >> made. In cases where this isn't possible, the presence of the
> >>conflict
> >> 

Re: [Gen-art] Genart last call review of draft-ietf-tsvwg-iana-dscp-registry-05

[Spencer Dawkins at IETF]

Hi, Christer,

On Wed, May 23, 2018 at 1:41 PM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:

> Reviewer: Christer Holmberg
> Review result: Almost 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 treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-tsvwg-iana-dscp-registry-05
> Reviewer: Christer Holmberg
> Review Date: 2018-05-23
> IETF LC End Date: 2018-05-25
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is well written, and almost ready for publication. I
> have
> one minor editorial comment that I'd like the authors to address.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>
> The Abstract says:
>
> "This update to RFC2474 changes the IANA assignment method..."
>
> ...and the Introduction says:
>
>  "To allow the IETF to utilise Pool 3 codepoints, this document
>requests IANA to to manage Pool 3 assignments for DSCP values in Pool
>3 via the Standards Action policy [RFC8126].  This assignment method
>requires publication of a Standards Track or Best Current Practice
>RFC."
>
> I suggest to replace "method" with "policy".
>

I think that's right. https://tools.ietf.org/html/rfc8126#section-4 does
call these "assignment policies".

Gorry, if you agree, could you make that change?

Thanks,

Spencer
___
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-ippm-2330-ipv6-04

[Spencer Dawkins at IETF]

On May 23, 2018 7:10 AM, "MORTON, ALFRED C (AL)" <a...@research.att.com>
wrote:

Hi Spencer,



If co-authors are satisfied with the version I sent

on May 9th, then we are ready to go.


I'll give the authors a day to object, and then get this draft placed on a
telechat agenda ...

Spencer

 FYI – I’m taking a few days off, so replies will be

delayed, like this one.



regards,

Al



*From:* Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
*Sent:* Tuesday, May 22, 2018 11:02 AM
*To:* MORTON, ALFRED C (AL) <a...@research.att.com>
*Cc:* Francesca Palombini <francesca.palomb...@ericsson.com>; gen-art <
gen-art@ietf.org>; i...@ietf.org; draft-ietf-ippm-2330-ipv6@ietf.org

*Subject:* Re: Genart last call review of draft-ietf-ippm-2330-ipv6-04



Hi, Al,

On Wed, May 9, 2018 at 1:23 AM MORTON, ALFRED C (AL) <a...@research.att.com>
wrote:

Spencer wrote:

If you folks can contact the original authors and ask if they have any
objections to use of the updated copyright boilerplate now, that may come
in handy the next time IPPM needs to update 2330.



If you can't, it's probably best to update the copyright disclaimer now.



[acm] I updated the disclaimer in the working version.

I think there are a few more editorial comments to resolve.



I think we're just waiting for a fairly small -05 revision to put this on a
telechat, is that the way it looks to you?



Spencer



Al



*From:* Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
*Sent:* Tuesday, May 8, 2018 1:20 PM
*To:* Francesca Palombini <francesca.palomb...@ericsson.com>
*Cc:* MORTON, ALFRED C (AL) <a...@research.att.com>; gen-art@ietf.org;
i...@ietf.org; i...@ietf.org; draft-ietf-ippm-2330-ipv6@ietf.org
*Subject:* Re: Genart last call review of draft-ietf-ippm-2330-ipv6-04



Hi, draft-ietf-ippm-2330-ipv6.all,



On Fri, Apr 27, 2018 at 2:43 AM, Francesca Palombini <
francesca.palomb...@ericsson.com> wrote:

> [acm]
> We can add the pre-5378 disclaimer as a catch-all, but I doubt the
original
> authors would make any fuss about the small amount of common text with
> 2330.
> Almes, Paxson, Mahdavi and Mathis are all gentlemen and the best of their
> time.
>

I'm sure they are :) Just relaying what the id-nits told me.



If I might make an observation - the discontinuity between pre-5379 and
post-5370 copyright grants isn't going to get better (until all pre-5370
RFCs are Historic), and we already have some running code from pre-5370 RFC
authors becoming unreachable (in extreme cases, because they died).



If you folks can contact the original authors and ask if they have any
objections to use of the updated copyright boilerplate now, that may come
in handy the next time IPPM needs to update 2330.



If you can't, it's probably best to update the copyright disclaimer now.



Thanks!



Spencer
___
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-ippm-2330-ipv6-04

[Spencer Dawkins at IETF]

Hi, Al,

On Wed, May 9, 2018 at 1:23 AM MORTON, ALFRED C (AL) <a...@research.att.com>
wrote:

> Spencer wrote:
>
> If you folks can contact the original authors and ask if they have any
> objections to use of the updated copyright boilerplate now, that may come
> in handy the next time IPPM needs to update 2330.
>
>
>
> If you can't, it's probably best to update the copyright disclaimer now.
>
>
>
> [acm] I updated the disclaimer in the working version.
>
> I think there are a few more editorial comments to resolve.
>

I think we're just waiting for a fairly small -05 revision to put this on a
telechat, is that the way it looks to you?

Spencer


> Al
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
> *Sent:* Tuesday, May 8, 2018 1:20 PM
> *To:* Francesca Palombini <francesca.palomb...@ericsson.com>
> *Cc:* MORTON, ALFRED C (AL) <a...@research.att.com>; gen-art@ietf.org;
> i...@ietf.org; i...@ietf.org; draft-ietf-ippm-2330-ipv6@ietf.org
> *Subject:* Re: Genart last call review of draft-ietf-ippm-2330-ipv6-04
>
>
>
> Hi, draft-ietf-ippm-2330-ipv6.all,
>
>
>
> On Fri, Apr 27, 2018 at 2:43 AM, Francesca Palombini <
> francesca.palomb...@ericsson.com> wrote:
>
> > [acm]
> > We can add the pre-5378 disclaimer as a catch-all, but I doubt the
> original
> > authors would make any fuss about the small amount of common text with
> > 2330.
> > Almes, Paxson, Mahdavi and Mathis are all gentlemen and the best of their
> > time.
> >
>
> I'm sure they are :) Just relaying what the id-nits told me.
>
>
>
> If I might make an observation - the discontinuity between pre-5379 and
> post-5370 copyright grants isn't going to get better (until all pre-5370
> RFCs are Historic), and we already have some running code from pre-5370 RFC
> authors becoming unreachable (in extreme cases, because they died).
>
>
>
> If you folks can contact the original authors and ask if they have any
> objections to use of the updated copyright boilerplate now, that may come
> in handy the next time IPPM needs to update 2330.
>
>
>
> If you can't, it's probably best to update the copyright disclaimer now.
>
>
>
> Thanks!
>
>
>
> Spencer
>
>
>
___
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-ippm-2330-ipv6-04

[Spencer Dawkins at IETF]

Hi, draft-ietf-ippm-2330-ipv6.all,

On Fri, Apr 27, 2018 at 2:43 AM, Francesca Palombini <
francesca.palomb...@ericsson.com> wrote:

> > [acm]
> > We can add the pre-5378 disclaimer as a catch-all, but I doubt the
> original
> > authors would make any fuss about the small amount of common text with
> > 2330.
> > Almes, Paxson, Mahdavi and Mathis are all gentlemen and the best of their
> > time.
> >
>
> I'm sure they are :) Just relaying what the id-nits told me.
>

If I might make an observation - the discontinuity between pre-5379 and
post-5370 copyright grants isn't going to get better (until all pre-5370
RFCs are Historic), and we already have some running code from pre-5370 RFC
authors becoming unreachable (in extreme cases, because they died).

If you folks can contact the original authors and ask if they have any
objections to use of the updated copyright boilerplate now, that may come
in handy the next time IPPM needs to update 2330.

If you can't, it's probably best to update the copyright disclaimer now.

Thanks!

Spencer
___
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-tram-stunbis-15

[Spencer Dawkins at IETF]

Dear Authors,

Now that Last Call for this draft has ended, could you folks take a look at
Dale's comments and respond?

Thanks!

Spencer, as responsible AD

On Mon, Feb 19, 2018 at 11:30 AM, Dale Worley  wrote:

> Reviewer: Dale Worley
> 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.
>
> Document:  draft-ietf-tram-stunbis-15
> Reviewer:  Dale R. Worley
> Review Date:  2018-02-19
> IETF LC End Date:  2018-02-20
> IESG Telechat date:  [unknown]
>
> Summary:
>
>This draft is on the right track but has open issues, described
>in the review.
>
> Overall, the draft is quite well organized and well written.  But
> there are a number of open issues that have substantial technical
> content.  I suspect that the intended design does not have these
> issues, and the issues that I see are just where the text hasn't been
> fully updated to match the intended design.
>
> Dale
>
> --
>
> There is an issue that shows up in several places:  The NAT may
> forward the request using an IP family that is different from the IP
> family that it received the request using.  This means that the
> "source IP family of the request" may depend on whether one is
> speaking of the client or the server.  The draft is cognizant of this,
> and mentions its consequences in sections 6.3.3 and 12.  But this also
> has consequences for ALTERNATE-SERVER:  Section 14.15 says "The IP
> address family MUST be identical to that of the source IP address of
> the request." even though that family might not be usable by the
> client.  The draft doesn't seem to explicitly say that this comes from
> address-switching by the NAT.  It would help if there was a
> higher-level discussion of this matter, pointing to the various
> consequences.
>
> The text contains these references to SHA algorithms (that it does not
> itself define).  Some should be corrected:
>
> HMAC-SHA1
> HMAC-SHA-1
> should be HMAC-SHA1 per RFC 2104
> HMAC-SHA256
> HMAC-SHA-256
> should be HMAC-SHA256 per RFC 6151, but HMAC-SHA-256 per RFC 6151!
> SHA1
> SHA-1
> It appears that the proper name of this function is SHA-1.
> SHA256
> SHA-256
> NIST calls this algorithm SHA-256.
>
> 3.  Terminology
>
> This section needs to be updated to reference RFC 8174.
>
> 4.  Definitions
>
> Although the definitions of STUN Client and STUN Server mention that
> they receive responses and requests (respectively), they don't mention
> that they also receive indications.
>
> 5.  STUN Message Structure
>
>All STUN messages MUST start with a 20-byte header followed by zero
>or more Attributes.
>
> It would be clearer, I think, to say "All STUN messages comprise a
> 20-byte header followed by zero or more Attributes."
>
> 6.2.2.  Sending over TCP or TLS-over-TCP
>
>The client MAY send multiple transactions over a single TCP (or TLS-
>over-TCP) connection, and it MAY send another request before
>receiving a response to the previous.
>
> s/the previous./the previous request./
>
> This section should also state whether or not a server is allowed to
> provide responses in a different order than it received the requests,
> if it receives further requests before sending a response.
>
>o   if multiplexing other application protocols over that port, has
>finished using that other application, and
>
> s/that other application/that other protocol/
>
> 6.3.4.  Processing an Error Response
>
> o  If the error code is 300 through 399, the client SHOULD consider
>the transaction as failed unless the ALTERNATE-SERVER extension is
>being used.  See Section 10.
>
> This syntax binds "section 10" to the entire preceding sentence, whose
> topic is error codes 300-399, whereas "section 10" only applies to
> ALTERNATE-SERVER.  A better syntax would be
>
> o  If the error code is 300 through 399, the client SHOULD consider
>the transaction as failed unless the ALTERNATE-SERVER extension
>(Section 10) is being used.
>
> 9.2.  Long-Term Credential Mechanism
>
>Note that the long-term credential mechanism cannot be used to
>protect indications, since indications cannot be challenged.  Usages
>utilizing indications must either use a short-term credential or omit
>authentication and message integrity for them.
>
> Alternatively, if there has been a recent request transaction between
> the client and the server, then a nonce have been established, and an
> indication can be sent securely using the long-term mechanism.
> (Although there is no mechanism for signaling if the nonce has become
> stale.)  It seems to me plausible that some usage may wish to exploit
> this possibility.
>
> 

Re: [Gen-art] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05

[Spencer Dawkins at IETF]

Just to end the suspense,

On Sep 2, 2017 13:37, "Spencer Dawkins at IETF" <
spencerdawkins.i...@gmail.com> wrote:

Hi, Brian,

On Fri, Sep 1, 2017 at 6:41 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 02/09/2017 09:45, Black, David wrote:
> > Brian,
> >
> > Thanks for the prompt review.
> >
> >> Comment: Very clear from the technical standpoint.
> >
> > Thank you!
> >
> >> I understand the desire for brevity, but this bothers me a bit. What is
> >> the reader to make of RFC3168 Section 20.2, for example? My feeling is
> >> that a short Appendix outlining the specific updates would be useful.
> >> There's already too much spaghetti to untangle.
> >
> > RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence would
> be
> > deleted. Request noted, I'll consult with the draft shepherd and
> responsible
> > AD to figure out whether to do this.
>
> Thanks. It's not intended as a blocking issue.
>
> >
> >> I see no reason why RFC3540 and RFC5622 need to be normative references
> >> (and therefore downrefs). They aren't required reading in order to
> >> understand this draft.
> >
> > OTOH, both are affected by this draft:
> >
> > In reverse order, this draft updates RFC 5622 - that seems to merit a
> > normative reference.This draft also provides the rationale for the
> > status change of RFC 3540 to Historic, which also seems to merit a
> > normative reference.
>
> Well, my understanding is that a normative reference is needed only
> when the citing document cannot be understood and implemented
> without reading the cited document.
>
> Again it's not a blocking comment - although there is a technical error
> in the Last Call message: it flags the downref to 5622, but not that to
> 3540.
> I don't know if that's a tool error or an AD error ;-).


As Bran is too polite to say, the AD sees the generated Last Call
announcement before it's sent.

I just regenerated the Last Call announcement, and it's still only naming
one draft as a normative downref. But the AD didn't notice that, so blaming
the tools was the wrong answer :-)

It's a 3-day weekend in the US, so any updated Last Call announcement won't
go out until Tuesday, anyway.

So, let's talk about that.

I just re-read the draft, focusing on the places where it refers to RFC
3540.

This draft explains the ECN Nonce experiment inline, although it cites 3540
as its reference, and explains that the experiment required ECT(0) and
ECT(1), but the experiment is over, and hasn't been deployed on the
Internet in any significant way, so we want ECT(1) back, for other
experiments.

It also refers to 3540 when it changes a registration in the Transmission
Control Protocol (TCP) Header Flags registry, but I believe this draft
explains the IANA actions requested well enough that IANA wouldn't need to
read 3540 to carry out the requested action.

I could be convinced that this draft explains why we want ECT(1) back well
enough that it's not necessary to actually read 3540, and since we're
declaring 3540 Historic, we actually kinda hope no one reads it in the
future except archaeologists in cyberspace.

But unless that reference really is informational, it remains a normative
downref that was omitted from the Last Call announcement.

David, I don't mind re-issuing the Last Call announcement if you think
still think the reference is normative, but you might want to take a look
at the text in the draft, and see how badly it needs to be normative,
before letting me know.

Spencer


Mirja and I talked this morning, and the score is

It's normative:2
It's informative:2

between me, Brian, David, and Mirja, so I took that as a sign that moving
that reference to Informative References isn't obviously ok.

I edited the Last Call text and re-issued the Last Call requests for both
the draft and the status change document, so they stay in sync.

The Secretariat was likely off today (US Labor Day), so it might take a day
for the Last Calls to pop out.

Thanks to everyone for your help.

Spencer
___
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-tsvwg-rfc5405bis

[Spencer Dawkins at IETF]

Jari has been living on IANA Transition Time. You're lucky he knows what
year it is. ;-)

Spencer

On Wed, Oct 5, 2016 at 10:20 AM, Black, David  wrote:

> Having an answer a week in advance is good ;-).  Thanks, --David
>
> > -Original Message-
> > From: Jari Arkko [mailto:jari.ar...@piuha.net]
> > Sent: Wednesday, October 05, 2016 11:13 AM
> > To: Black, David
> > Cc: Paul Kyzivat; draft-ietf-tsvwg-rfc5405bis@ietf.org; General
> Area Review
> > Team; Eggert, Lars
> > Subject: Re: [Gen-art] Gen-ART Last Call review of
> draft-ietf-tsvwg-rfc5405bis
> >
> > Yes, I was off by a week :-)
> >
> > Fortunately doing this a week too early, not late :-)
> >
> > (I still need an answer, but next week is fine.)
> >
> > Jari
> >
> > On 05 Oct 2016, at 11:03, Black, David  wrote:
> >
> > > Hi Jari,
> > >
> > >> The document
> > >> is on tomorrow's IESG telechat, now in version -18.
> > >
> > > Are you off by a week?  The datatracker indicates an October 13
> telechat date.
> > >
> > > Thanks, --David
> > >
> > >
> > >> -Original Message-
> > >> From: Jari Arkko [mailto:jari.ar...@piuha.net]
> > >> Sent: Wednesday, October 05, 2016 10:50 AM
> > >> To: Paul Kyzivat
> > >> Cc: draft-ietf-tsvwg-rfc5405bis@ietf.org; General Area Review
> Team;
> > Eggert,
> > >> Lars
> > >> Subject: Re: [Gen-art] Gen-ART Last Call review of
> draft-ietf-tsvwg-rfc5405bis
> > >>
> > >> Paul, all,
> > >>
> > >> Thanks for the review & efforts to change the document. Are we happy
> with
> > the
> > >> resolution of these issues, couple of months after the discussion? The
> > document
> > >> is on tomorrow's IESG telechat, now in version -18.
> > >>
> > >> Jari
> > >
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

[Spencer Dawkins at IETF]

I'll wait to see what Suresh thinks (we're discussing his Comment), but

On Tue, Sep 6, 2016 at 8:44 PM, Tirumaleswar Reddy (tireddy) <
tire...@cisco.com> wrote:

> *From:* Pete Resnick [mailto:presn...@qti.qualcomm.com]
> *Sent:* Tuesday, September 6, 2016 9:25 PM
> *To:* IESG 
> *Cc:* t...@ietf.org; draft-ietf-tram-turn-mobility@ietf.org; General
> Area Review Team 
> *Subject:* GenART post-telechat comment on draft-ietf-tram-turn-mobility-
> 08
>
>
>
> Greetings,
>
> 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
> participants comments.
>
> For more information, please see the FAQ at
>
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>
> Document: draft-ietf-tram-turn-mobility-03
> Reviewer: Pete Resnick
> Review Date: 2016-09-06
> IESG Telechat date: 2016-09-01
>
> Summary: This is an odd post-telechat review, but I think the draft has
> gone from "Ready" to "Ready with an issue" because of an IESG Eval change.
>
> Details:
>
> I did not get to my post-Last Call GenART review of
> draft-ietf-tram-turn-mobility until after the telechat. Had I done so,
> which would have been on version -05, I would have said "Looks fine to me".
> However, I happened to look at the latest version, figuring I would just
> confirm. I found that a change was made in response to an IESG Evaluation
> comment from Suresh https://mailarchive.ietf.org/arch/msg/tram/
> SYVAXc1dF6xUcm0OQ9xyuaknJco:
>
> --
> COMMENT:
>
>- Section 3.2.1
>
> The section on sending a Refresh when the IP address does not change
> needs a little bit more tightening. Given that the server would reject
> the request with a mobility ticket in this case, it would be good to put
> in an explicit restriction to not add the mobility ticket in the
> following statement
>
> OLD: If a client wants to refresh an existing allocation and update its
> time-to-expiry or delete an existing allocation, it will send a Refresh
> Request as described in Section 7.1 of [RFC5766]
>
> NEW:
> If a client wants to refresh an existing allocation and update its
> time-to-expiry or delete an existing allocation, it MUST send a Refresh
> Request as described in Section 7.1 of [RFC5766] and MUST NOT include a
> MOBILITY-TICKET attribute.
>
> I'm not sure if the "MUST NOT" in the latter part of the sentence is
> correct: Since the server will reject it anyway, I don't see the harm in
> including the attribute that the "MUST NOT" implies, but perhaps this is
> belt-and-braces protocol description. On this point, I can't complain too
> much.
>
> [TR] “MUST NOT” is required to prevent the client from sending the request
> with the ticket which will be rejected by the server and the client will
> have to again re-try the request without the ticket.
>
> However, I believe Suresh was incorrect in suggesting the first "MUST",
> and it should be removed. There is no harm being prevented here. "If a
> client wants X, it MUST send Y" is absolutely no different protocol-wise
> from "If a client wants X, it will send Y". The "MUST" is a misuse. I
> believe that this change should be undone before publication.
>
> [TR] I can the update the line; including Suresh to see if he has any
> objections
>

Given that we're usually in a minimize-the-number-of-round-trips
environment here, I'm more sympathetic to MUST as an optimization, and not
just belt-and-suspenders ("ask me no questions and I'll tell you no lies")
in this case than I would usually be.

Spencer


> -Tiru
>
> pr
> --
> Pete Resnick http://www.qualcomm.com/~presnick/
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
___
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-tsvwg-rfc5405bis

[Spencer Dawkins at IETF]

Hi, Paul,

On Tue, May 31, 2016 at 9:12 AM, Black, David  wrote:

> Paul,
>
> > > So, (as WG chair for this paragraph only), thank you for your input,
> but this is a
> > single draft for very good reasons.
> > > 
> >
> > Thanks for the explanation. The thing about genart reviews is that the
> > reviewer doesn't have the context that the authors do, and maybe not the
> > context that likely readers will have. I certainly won't second guess
> > you on that.
>
> And double-checking this sort of thing is one of the purposes of Gen-ART
> reviews (said as a long-time former Gen-ART reviewer), so thanks for
> bringing this topic up - if nothing else, we now have this concern and
> response documented in email archives for IESG review of this draft ;-).


David beat me to it, but I do want to say that (as another long-time former
Gen-ART reviewer) I'm very interested in FIRST guesses from reviewers who
haven't been involved in every discussion of every revision of the draft.

I'm sure there's a forest behind all these trees someplace :-)

Spencer
___
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-tram-stun-path-data-03

[Spencer Dawkins at IETF]

Dear Authors,

On Thu, Feb 11, 2016 at 5:09 PM, Wassim Haddad 
wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please see the FAQ at 
> 
>
> Document: draft-ietf-tram-stun-path-data-03
> Reviewer:  Wassim Haddad
> Review Date: 11 February 2016
> IETF LC End Date: 11 February 2016
> IETF Telechat Date: unknown
>
> Summary:  This draft is ready for publication as proposed RFC
>
> - Major Issues: None
>
> - Minor Issues: None
>
> Question: Would it make sense to highlight the mobility case (since the 
> document explicitly mentions 3G, 4G, WiFi) in which case, applying the 
> described mechanism would suggest to the mobile to use a different interface 
> after attaching to a different network…
>
>
I haven't seen a response to Wassim's question - did I miss it?

Thanks,

Spencer


> Regards,
>
> Wassim H.
>
>
>
___
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-ippm-2679-bis-03

[Spencer Dawkins at IETF]

And, for what it's worth, the responsible AD agrees with what Brian and Al
are cooking up, for this draft and for RFC2680bis.

Spencer

On Mon, Aug 3, 2015 at 9:02 AM, Guy Almes gal...@tamu.edu wrote:

 Al,
   I very much agree on moving toward treating IPv6 fully as these evolve.
 -- Guy


 On 8/2/15 1:45 PM, MORTON, ALFRED C (AL) wrote:

 Hi Brian,

 Thanks for your review.
 Please see replies and proposed resolutions below.

 regards,
 Al

 -Original Message-
 From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
 Sent: Friday, July 31, 2015 3:45 AM
 To: draft-ietf-ippm-2679-bis@ietf.org; General Area Review Team
 Subject: Gen-ART Last Call review of draft-ietf-ippm-2679-bis-03

 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-ippm-2679-bis-03.txt
 Reviewer: Brian Carpenter
 Review Date: 2015-07-31
 IETF LC End Date: 2015-08-11
 IESG Telechat date:

 Summary: Ready with issues
 

 Major issue:
 

 The draft does not mention the IP version.  RFC 2330 states that it
 applies to IPv4 only (section 15) and uses terminology that only applies
 to IPv4. At the very minimum, the current draft needs to state its
 limited applicability. I would be much happier if it explained how it
 applies to IPv6.

 [ACM]
 In this update, we added an explicit reference to Section 15 of RFC 2330
 on the requirements for standard-formed packets (note: most, but not all,
 usage of standard-formed in RFC2330 is hyphenated). I suggest that we
 note the limitation of the current reference in the text:

 + The packet is standard-formed, the default criteria for all metric
definitions defined in Section 15 of [RFC2330], otherwise the packet
will be deemed lost. Note: At this time, the definition of
 standard-formed
packets only applies to IPv4.

 Further, I propose that we begin the process of updating this section of
 RFC 2330 immediately. This way, the IPv6 coverage will extend to all
 IPPM RFCs, especially RFC2680bis which is also in IETF Last Call.



 Minor issues:
 -

 In sections 3.6 and 3.8.1 there are passing references to the diffserv
 code point. I think that the ECN bits should be mentioned too: their
 setting could also affect router processing time. ECN is a bit tricky as
 it might change on the fly.


 [ACM]
 So can DSCP if the packet is re-marked, as you know well.
 We can mention ECN in section 3.8.1 (the original text referred to the
 TOS field, so what you read was already updated), with further revisions
 below:

 The value of Type-P-One-way-Delay could change if the protocol (UDP or
 TCP),
 port number, size, or arrangement for special treatment (e.g., IP DS Field
 [RFC2780], ECN [RFC3168] or RSVP) changes. The exact Type-P used to make
 the measurements MUST be accurately reported.

 But...


 Along the same lines, should Router Alert be mentioned? And for IPv6
 applicability, any hop-by-hop options should certainly be mentioned.


 [ACM]
 RFC 2330, Section 13 says:
 A fundamental property of many Internet metrics is that the value of
 the metric depends on the type of IP packet(s) used to make the
 measurement.
 ...  some IPv4-centric examples, then  ...
 Because of this distinction, we introduce the generic notion of a
 packet of type P, where in some contexts P will be explicitly
 defined (i.e., exactly what type of packet we mean), partially
 defined (e.g., with a payload of B octets), or left generic.

 If we seek to identify several more distinctions for packets of Type-P,
 then I would prefer to update the RFC 2330 Framework Section 13 on
 this topic, so it's more widely applicable and less IPv4-centric.
 I'll take immediate steps to accomplish this update.


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

Re: [Gen-art] LC review of draft-ietf-rmcat-cc-requirements-05.txt

[Spencer Dawkins]

On 11/25/2014 09:50 AM, Jari Arkko wrote:

Thanks for the review. (Were the comments adopted by the authors? This review 
is from August, but I cannot see a response…)


So, just to update the RMCAT crew, this document was approved on today's 
telechat, pending comment disposition.


On the comments from Alexey's review - the term RMCAT doesn't appear in 
the text, but still appears in the short title on each page, so his 
comment on expanding/explaining RMCAT still applies. RTP and RTCP now do 
have references, so that comment has been handled.


In addition, there were IESG evaluation comments from several ADs. The 
comments from Brian and Barry were intended for me and the other ADs, so 
no action required, but the other comments at 
https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ballot/ should 
be considered. You should bask for a moment in the compliment Ted 
included in his ballot.


Please let me know if/when you have a revised ID, and I'll send the 
approval note to the secretariat.


And thanks for all your work on this.

Spencer, as responsible AD


Jari

On 03 Aug 2014, at 21:37, Alexey Melnikov alexey.melni...@isode.com 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-rmcat-cc-requirements-05
Reviewer: Alexey Melnikov
Review Date: 3-Aug-2014
IETF LC End Date: 13-Aug-2014
IESG Telechat date: N/A

Summary: This document is ready for publication as an Informational RFC [ready 
with comments]

Major issues: None
Minor issues:

In Section 1: RMCAT is not explained/expanded, when mentioned for the first 
time. Does this acronym need to be in the published RFC, e.g. would it be 
useful for readers reading this document 10 years later?

RTP and RTCP need references.

In general, I found this document not to be very friendly to people who don't 
follow RMCAT.

Nits/editorial comments: None

___
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

Re: [Gen-art] [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09

[Spencer Dawkins]

On 10/02/2014 07:16 AM, Jari Arkko wrote:

Thank you for your review, Robert. Much appreciated.


And thanks from me. I read 'em, too!

Spencer

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

Re: [Gen-art] Gen-ART LC Review of draft-eggert-successful-bar-bof-06

[Spencer Dawkins]

Lars,

For what it's worth, I have the same question as Ben - if this guidance 
applies to the kinds of informal meetings in restaurants and bars that the 
IESG is encouraging, even if they aren't publicized and aren't open to the 
community, is there any way for two or more IETF participants to talk to 
each other, that's NOT under NOTE WELL?


I think it DOES make sense to say that the kinds of informal meetings the 
IESG is discouraging - in IETF meeting rooms, with agendas, mailing lists, 
presentations, attendee lists, and minutes - should include NOTE WELL 
notifications.


But if I was sitting next to Adam Roach on a plane headed for the IETF 
(which has happened before) when he was editor of GIN and I was chair of 
MARTINI (this last part did not), and we started talking about proposed 
changes to the GIN draft, is that covered?


Color me confused ...

Spencer

-- Section 6 suggests side meetings should be (somehow informally) 
covered by NOTE WELL. I think this is a very dangerous suggestion. The 
rest of the document suggests that a side meeting has no official 
standing. That seems to me to mean it's no different than a group of 
people who coincidentally participate in the IETF having a dinner or bar 
meeting on any subject at any time. Or a hallway conversation, for that 
matter. By the logic of this section, I can't really figure out how 
informal a meeting would need to be before it no longer fell under 
NOTE WELL.


In an informal meeting, the participants should be able to follow any 
IPR policy they like. I can even imagine an informal meeting covered by 
an NDA, where the participants want to decide if they want to have 
further discussions of a subject under IETSF IPR rules or not.


I think the best we can hope to do is suggest that side meeting 
organizers and participants be explicit with their expectations on IPR 
and confidentiality, so there is less chance for down-stream surprises. 
If we want something stronger than that, then we really need to create a 
new category of official meeting.


We actually ran this question past the IETF legal counsel before adding 
that section to the document. It was his stated opinion that the Note 
Well applies. I therefore don't see what we could do here.




Did the counsel describe the triggers that causes Note Well to apply in 
general? Because if it automatically applies to an unofficial side 
meeting, then it's hard for me to see where it _doesn't_ apply when 2 or 
more IETF participants have a conversation. For example:


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

[Gen-art] Gen-ART review of draft-ietf-mipshop-transient-bce-pmipv6-06

[Spencer Dawkins]

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-mipshop-transient-bce-pmipv6-06
Reviewer: Spencer Dawkins
Review Date: 24 August 2010
IESG Telechat date: 26 August 2010

Summary: This specification is ready for publication as an Experimental RFC.

Comments: I have a small number of nits, forwarded for the convenience of 
any downstream editors.


Abstract

  This document specifies a mechanism which enhances Proxy Mobile IPv6
  protocol signaling to support the creation of a transient binding
  cache entry which is used to optimize the performance of dual radio
  handover, as well as single radio handover.  This mechanism is
  applicable to the mobile node's inter-MAG handover while using a
  single interface or different interfaces.  The handover problem space
  using the Proxy Mobile IPv6 base protocol is analyzed and the use of
  transient binding cache entries at the local mobility anchor is
  described.  The specified extension to the Proxy Mobile IPv6 protocol
  ensures optimized forwarding of downlink as well as uplink packets
  between mobile nodes and the network infrastructure and avoids
  superfluous packet forwarding delay or even packet loss.

Spencer (nit): or even packet loss? maybe there's a qualifier missing? :D

1.  Introduction

  According to the PMIPv6 base specification, an LMA updates a mobile
  node's (MN) Binding Cache Entry (BCE) and switches the forwarding
  tunnel after receiving a Proxy Binding Update (PBU) message from the
  mobile node's new MAG (nMAG).  At the same time the LMA disables the
  forwarding entry towards the mobile node's previous MAG (pMAG).  In
  case of an inter-technology handover, the mobile node's handover
  target interface must be configured according to the Router
  Advertisement being sent by the nMAG.  Address configuration as well
  as possible access technology specific radio bearer setup may delay
  the complete set up of the mobile node's new interface before it is
  ready to receive or send data packets.  In case the LMA performs
  operation according to [RFC5213] and forwards packets to the mobile
  node's new interface after the reception of the PBU from the nMAG,
  some packets may get lost or experience major packet delay.  The
  transient BCE extension, as specified in this document, increases
  handover performance (optimized packet loss and forwarding delay)
  experienced by MNs, which have multiple network interfaces
  implemented while handing over from one interface to the other.  The
  transient BCE extension increases also handover performance for

Spencer (nit): s/increases also/also increases/

  single radio MNs, which build on available radio layer forwarding
  mechanisms, hence re-use existing active handover techniques.

3.1.  Handover using a single interface

  In some active handover scenarios, it is necessary to prepare the
  nMAG as handover target prior to the completion of the link layer
  handover procedures.  Packets sent by the LMA to the nMAG before the
  completion of the link layer handover procedure will be lost or need
  to be buffered.

Spencer (nit): will be lost unless they are buffered?

  In some systems, the nMAG will be the recipient of uplink traffic
  prior to the completion of the procedure that would result in the
  PBU/PBA handshake.  These packets cannot be forwarded to the LMA.

3.3.  Need for a common solution

  This document specifies transient BCEs as an extension to the PMIPv6
  protocol.  Set up and configuration of a transient BCE can be
  performed by means of extended PMIPv6 signaling messages between the
  MAG and the LMA component using a new Transient Binding mobility
  option.  The transient BCE mechanism supports three clearly
  distinguished sequences of transient states to suit various handover
  scenarios and to improve handover performance for both, inter- and

Spencer (nit): s/both,/both/

  intra-technology handover.  As a result of using transient BCEs,
  excessive packet buffering at the nMAG during the MN's handover
  process is not necessary and packet losses and major jitter can be
  avoided.

4.8.  Protocol Stability

  Lost connection with pMAG during late path switch:  In case an MN
 looses connectivity to its pMAG during a transient BCE phase with

Spencer (nit): s/looses/loses/

 late path switch and the nMAG fails to initiate turning a
 transient BCE into an active BCE to perform the path switch to the
 nMAG, in a worst case downlink packets are lost until the chosen
 TIMEOUT_1 expires.  After TIMEOUT_1 seconds, the protocol
 operation has been recovered successfully.  However, this case is
 very unlikely for two reasons: If the connectivity to the pMAG is
 lost, the pMAG will send a deregistration PBU

Re: [Gen-art] Gen-ART Review of draft-c1222-transport-over-ip-03

[Spencer Dawkins]

Hi, Avygdor,


Mr Spencer,

Thank you for the remarks. I will try to respond inline with each of your 
comment below.


I hope I did not miss anything.

We shall produce an update shortly (04) that includes the solutions 
described below.


Thanks
Avygdor Moise


Thanks for responding while I can still remember what I was thinking when I 
wrote the review :-)


I deleted anything that we already agree on, below.


1.2. Definitions

  Active-listen UDP

 Active-listen UDP is a temporary process used by a local C12.22
 IP Node to expect and receive incoming C12.22 Messages from a
 foreign C12.22 IP Node using the UDP protocol.  The local C12.22
 IP Node SHALL solicit the incoming C12.22 Messages from the
 foreign C12.22 IP Node using the foreign C12.22 IP Node's
 registered Native IP Address.  The local C12.22 IP Node MAY exit
 Active-listen UDP process when it has received all of the
 expected C12.22 Messages or a C12.22 Message timeout has
 occurred.  The local C12.22 IP Node SHALL receive all C12.22
 Response Messages solicited from the foreign C12.22 IP Node that
 arrive at the local port number that matches the source port
 number used to solicit the C12.22 Messages from the foreign
 C12.22 IP Node.

Spencer (minor): I'm not accustomed to seeing normative text in 
definitions (and there are several instances in this section). If the ADs 
are OK with that, I'm OK (don't change it unless someone raises it as a 
comment in the tracker), but I wanted to make sure Russ noticed this.


Note: In response to another comment we replaced the terms Active-listen 
UDP and Passive-listen UDP with Active-Open UDP and  Passive-Open 
UDP


I agree with you that generally one does not place normative text in 
definitions. However, we applied the following editorial generalizations

1) Definitions are normative (i.e. they are binding)
2) If a definition describes a state (i.e. a condition that has an entry 
requirement and an exit requirement) and it can be summarized on a single 
paragraph then it does not merit the creation of a separate section for 
the elaborations
3) Removal of SHALLs and MAY words from definitions can lead to 
interoperability problem, so I place them anywhere were applicable.


So, I would rather leave this one alone and not apply a change.
I hope this does not cause problems


Yeah - like I said, I just wanted to call Russ's attention to this, because 
it's not a common situation. Whatever the ADs think is OK, is OK with me.



2.2. Native IP Address

  The IP address of the C12.22 IP Node SHOULD be configured before the
  C12.22 IP Node attempts to send or receive any C12.22 Message on its
  C12.22 IP Network Segment.  If the port number is not explicitly
  configured by the controlling application, it SHALL be set to the
  default port number, 1153 (see Section 2.4. Standardized Port
  Numbers).

Spencer (minor): SHOULD be configured? OK, but at a minimum, you should 
say something about when it's acceptable to send C12.22 application-level 
messages without a configured IP address, and how that works (source IP 
address is all zeros? something else? I'm confused here). I'm kind of 
expecting that other reviewers would say MUST...



Note: The last paragraph in section 2.2 was changes to read
It is beyond the scope of this specification to define the method of 
configuration, the configuration parameters, or any administrative 
controls that the system administrator may wish to implement to assign an 
IP address.


In regards to the paragraph in question it already states: The IP address 
of the C12.22 IP Node SHOULD be configured before the C12.22 IP Node 
attempts to send or receive any C12.22 Message on its C12.22 IP Network 
Segment.


So it is never acceptable (or possible) any C12.22 Messages if C12.22 Node 
is not on the IP Network.


Clearly I miss something here. Can you elaborate?


never acceptable sounds like this ought to be a MUST. If it's a MUST, 
implementations that don't do it, don't conform. If it's a SHOULD, 
implementations can decide not to do it, and still conform. If this is a 
SHOULD, I would expect you to say what the node uses as a source IP address, 
at a minimum, if it decides to send packets before configuring the IP 
address.


My rule (for myself) is that when you don't do things you MUST do, it's your 
fault when it doesn't work, but when you don't do things you SHOULD do, 
somebody needs to describe what the other end should do in response - if 
it's going to fail in all cases, it really was a MUST.


I'm confused because the IP address is a SHOULD, and the port number is a 
SHALL. I would have thought that they were equally important. I'm not an 
expert in this field, of course.



2.6. IP Multicast

  IPv6 C12.22 IP Nodes SHOULD use the minimum scope needed, when
  initiating IP multicast messages to reach another C12.22 IP Node on
  the C12.22 Network.  This practice is RECOMMENDED in order to limit

Re: [Gen-art] Gen-ART Review of draft-c1222-transport-over-ip-03

[Spencer Dawkins]

Hi, Avygdor,

We're very close (not that I have a ballot position, but :-) ...


Ah - in that case, I suggest that you delete the sentence While this 
mode of operation is not explicitly supported in the ANSI C12.22 
standard, it MAY be made possible through mutual operating agreements.


You don't need to say this, and you're just calling the reader's 
attention to an undesirable practice that MIGHT work - that's enough to 
make some product managers say oh, you can implement Uni-directional TCP 
for this, and tell people to make it work. :-(




Ok. Will delete the text
While this mode of operation is not explicitly supported in the ANSI 
C12.22 standard, it MAY be made possible through mutual operating 
agreements.  The means by which nodes are configured to enact the 
uni-directional use of TCP is not defined in this specification or in the 
ANSI C12.22 standard; it is left for future consideration.


You actually deleted two sentences - I wasn't sure about asking you to 
delete the second sentence, but if you're OK with it, I think that's fine.



3.4.2. Sending Large C12.22 APDUs Using UDP

  When sending a large C12.22 Message via UDP, whereby the ACSE PDU
  size exceeds the UDP datagram maximum data length (65527 bytes), the
  initiating C12.22 IP Node SHALL segment the ACSE PDU in accordance
  with ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such
  that each APDU segment fits within the UDP data field.

Spencer (minor): If you're matching something that's already deployed, 
fine, but if you have an opportunity to set a lower bound than 65527 
bytes for invoking application-level segmentation and reassembly, I'd 
suggest thinking about that. Losing fragments means you retransmit the 
entire IP packet (no surprise there), and more fragmentation means 
you're taking up more reassembly buffers on NATs, if this protocol is 
really intended to traverse the Internet...


This explains the upper limit that is imposed on to the Segmentation 
Algorithm of ANSI C12.22 by the IP Network. When a node pushes data 
above that size it must segment.
However, nodes may choose to segment a much lower limits (which may be 
negotiated between peers by the C12.22 Protocol).


I'm not an expert in the application space where you're working, but if 
it's anything like the open Internet, there are a lot of reasons to avoid 
IP fragmentation when you can do so.


To name two, some NATs drop packets that don't have port numbers 
(subsequent fragments don't), and when one fragment is lost for an 
application that can't lose packets, the entire IP packet has to be 
retransmitted. Assuming a 1500-byte-ish 802 link layer, you're saying 
that applications don't have to worry until the Message size is bigger 
than 65527 bytes - that's 44 fragments. If you've already lost one 
fragment due to congestion, throwing 44 more packets onto the path seems 
wrong.


You might wish to consider encouraging use of the C12.22 Protocol to 
negotiate lower limits (probably at SHOULD strength), unless you're sure 
that the current text won't lead to problems in your application space 
(and that your application won't be used on the open Internet).


I see the problem. We are caught between a rock and a hard place.
Most payloads are very small (less than 100 bytes). The reason for the 
number 65527 is to instruct the user not to trip on UDP.
The problem you indicate will need to be addressed in C12.22, since it 
originates there and if it is a defect in C12.22 then it will be common 
not just to IP but other transports that C12.22 may use as well.
I will bring this to the attention of ANSI SC17 and IEEE SCC31 (the 
committees) for correction.


I understand. You documented the limit that is KNOWN to fail :-)

I'm understanding from our conversation that you might be communicating with 
a C12.22 endpoint that won't negotiate downward before happily sending you 
maximum-length UDP packets whether you wish they would or not...


Ralph - I might be pushing too hard on this one - could you provide 
guidance?


Thanks again for the quick turnaround on this.

Spencer 


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

[Gen-art] Gen-ART Review of draft-c1222-transport-over-ip-03

[Spencer Dawkins]

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-c1222-transport-over-ip-03
Reviewer: Spencer Dawkins
Review Date: 2010-06-15
IETF LC End Date: 2010-07-01
IESG Telechat date: 2010-07-01

Summary: This draft is almost ready for publication as an Informational RFC. 
I have some minor questions, tagged in the review below.


1. Introduction

  The ANSI C12.22 standard [1] provides a set of application layer
  messaging services that are applicable for the enterprise and End
  Device components of an Advanced Metering Infrastructure (AMI) for
  the SmartGrid.  The messaging services are tailored for, but not
  limited to, the exchange of the data Tables Elements defined and co-
  published in ANSI C12.19 [2], IEEE P1377 [3], and MC12.19 [4].

Spencer (nit, clarity): If you could add a sentence about the relationship 
between [2], [3], and [4], that might be helpful to readers who are familiar 
with one of these, but not with the others. Even saying whether these are 
the same specification published by different SDOs would be helpful to me.


1.2. Definitions

  Active-listen UDP

 Active-listen UDP is a temporary process used by a local C12.22
 IP Node to expect and receive incoming C12.22 Messages from a
 foreign C12.22 IP Node using the UDP protocol.  The local C12.22
 IP Node SHALL solicit the incoming C12.22 Messages from the
 foreign C12.22 IP Node using the foreign C12.22 IP Node's
 registered Native IP Address.  The local C12.22 IP Node MAY exit
 Active-listen UDP process when it has received all of the
 expected C12.22 Messages or a C12.22 Message timeout has
 occurred.  The local C12.22 IP Node SHALL receive all C12.22
 Response Messages solicited from the foreign C12.22 IP Node that
 arrive at the local port number that matches the source port
 number used to solicit the C12.22 Messages from the foreign
 C12.22 IP Node.

Spencer (minor): I'm not accustomed to seeing normative text in definitions 
(and there are several instances in this section). If the ADs are OK with 
that, I'm OK (don't change it unless someone raises it as a comment in the 
tracker), but I wanted to make sure Russ noticed this.


2.2. Native IP Address

  The IP address of the C12.22 IP Node SHOULD be configured before the
  C12.22 IP Node attempts to send or receive any C12.22 Message on its
  C12.22 IP Network Segment.  If the port number is not explicitly
  configured by the controlling application, it SHALL be set to the
  default port number, 1153 (see Section 2.4. Standardized Port
  Numbers).

Spencer (minor): SHOULD be configured? OK, but at a minimum, you should 
say something about when it's acceptable to send C12.22 application-level 
messages without a configured IP address, and how that works (source IP 
address is all zeros? something else? I'm confused here). I'm kind of 
expecting that other reviewers would say MUST...


2.6. IP Multicast

  IPv6 C12.22 IP Nodes SHOULD use the minimum scope needed, when
  initiating IP multicast messages to reach another C12.22 IP Node on
  the C12.22 Network.  This practice is RECOMMENDED in order to limit

Spencer (minor): I don't think this is a 2119 RECOMMENDED - it's just a 
statement of fact. ... allows the sender to limit unnecessary propagation 
...?


  unnecessary propagation of C12.22 IP multicast Messages.

3.2.1. TCP and UDP Port Use

  General rules:

 5. A C12.22 IP Node that implements [CL=1] SHOULD set the source
   port number in outbound UDP C12.22 Messages to its registered
   port number.

 6. A C12.22 IP Node that implements [CL=1] MAY set the source
   port number in outbound UDP C12.22 Messages to a different UDP
   source port number if the target UDP C12.22 IP Node is
   reachable using direct messaging (as defined in [1]).

Spencer (nit, clarity): rule 6 explains why rule 5 is not a SHALL - it would 
be easier for this reader if the two were combined.


3.2.6. TCP and C12.22 Message Directionality

  Uni-directional use of TCP is a special mode of operation; it is NOT
  RECOMMENDED because multiple one-way channel communication is not
  described by ANSI C12.22, and it utilizes one-half of the TCP
  connection capability.  As a result it doubles the number of TCP
  connections used to communicate C12.22 Messages, and thus could
  become a burden when a large number of connections is required.
  While this mode of operation is not explicitly supported in the ANSI
  C12.22 standard, it MAY be made possible through mutual operating
  agreements.  The means by which nodes are configured to enact the
  uni-directional use of TCP is not defined in this specification or in
  the ANSI C12.22 standard; it is left for future consideration.

Spencer (nit, clarity

Re: [Gen-art] Gen art last call and telechat review ofdraft-ietf-dnsext-dns-tcp-requirements-03

[Spencer Dawkins]

Sorry to intrude (not my doc), but what I'm reading is making me think Ray's 
point, that the protocol processing doesn't change except for the order of 
transports you attempt, is true, but if you get a truncation indication using 
UDP, you know *when* to attempt TCP, and when you try TCP first, you don't 
actually know when to give up.

Have I got that right? If so ...

TCP connections will eventually reset if the attempt to establish a connection 
fails, but that's measured in terms of minutes, not seconds (I'm finding 75 
seconds on a couple of web pages, but I was remembering that it was more 
persistent than that - implementations could have changed since the last time I 
looked). So if the application developer thinks a shorter interval before 
attempting UDP is appropriate, the application can always run a timer and give 
up sooner.

If that's good enough, you can probably get away with pointing this out in 
the document.

Thanks,

Spencer
  - Original Message - 
  From: Avshalom Houri 
  To: Ray Bellis 
  Cc: General Area Review Team ; o...@ogud.com 
  Sent: Monday, June 14, 2010 6:56 PM
  Subject: Re: [Gen-art] Gen art last call and telechat review 
ofdraft-ietf-dnsext-dns-tcp-requirements-03


  I am OK with this explanation. Maybe it can be added as an explanatory  note 
to the draft. 

  tnx
  avshalom




  From:Ray Bellis ray.bel...@nominet.org.uk 
  To:Avshalom Houri/Haifa/i...@ibmil 
  Cc:General Area Review Team gen-art@ietf.org, o...@ogud.com 
   o...@ogud.com 
  Date:14/06/2010 01:44 PM 
  Subject:Re: Gen art last call and telechat review of 
draft-ietf-dnsext-dns-tcp-requirements-03 

--



   Minor issues: 
   
   Lines 246-250 
  That requirement is hereby relaxed.  A resolver SHOULD send a UDP 
  query first, but MAY elect to send a TCP query instead if it has good 
  reason to expect the response would be truncated if it were sent over 
  UDP (with or without EDNS0) or for other operational reasons, in 
  particular if it already has an open TCP connection to the server. 
   
   What should be the behavior here?  Try TCP and then revert to UDP? What 
should be the timeout for the TCP trial? Seems that this needs a bit of 
clarification. 

  I'm unsure how to address this.

  Can you please clarify what sort of timeouts you're thinking of?  Do you mean 
network level issues (e.g. blocked SYN) or simply those where the far end is 
slow to respond?

  In the latter case no text should be necessary (IMHO).  This document doesn't 
change the protocol processing.  This particular section merely permits TCP 
first in _some_ cases, relaxing §6.1.3.2 of RFC 1123.

   Line 229 
 so that the do not prevent large responses from a TCP-capable 
   -   so that they do not prevent large responses from a TCP-capable 

  Thanks - already reported and fixed :)

  kind regards,

  Ray





--


  ___
  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

Re: [Gen-art] Gen-ART review of draft-freed-sieve-notary-08

[Spencer Dawkins]

The text I commented on from -07 no longer exists in -08, so my only 
previous comment no longer applies.


There is a fair amount of new text in -08, but I didn't see anything that 
required attention, so I'm going with ready for publication as a proposed 
standard.


Thanks,

Spencer



Document: draft-freed-sieve-notary-07
Reviewer: Spencer Dawkins
Review Date: 2010-04-05
IESG Telechat date: 2010-04-08

Summary: This draft is roughly ready for publication as a Proposed 
Standard. I found one minor problem which MIGHT just be a cut-and-paste 
error, but someone needs to look at it...


Thanks,

Spencer

7.  redirect-deliverby extension

  :bytime specifies the number of seconds within which the message
  should be delivered. :bymode specifies whether a notification should
  be sent or the message simply returned if the time limit is exceeded.
  The default is return if :bymode is not specified.  See The
  semantics of delivery time limits are specified and discussed at
  length in [RFC2852].

Spencer (minor): I'm not sure if this is a cut-and-paste error or if you 
really meant to say something that got left out, but someone smarter than 
I am needs to look at the See The here.

___
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

Re: [Gen-art] Gen-ART review of draft-ietf-isms-dtls-tm-09

[Spencer Dawkins]

Wes,

Awesome turnaround. I can still remember what I was thinking...

Deleting stuff that's done. Please see inline.

Thanks,

Spencer


2 WONTDO 3.1.1.  Threats
~

 (D)TLS provides protection against the disclosure of information
 to unauthorized recipients or eavesdroppers by allowing for
 encryption of all traffic between SNMP engines.  A TLS Transport
 Model implementation SHOULD support the message encryption to
 protect sensitive data from eavesdropping attacks.

 + Spencer (minor): OK, I'm completely out of my depth here,
   but I'm confused by the SHOULD. Is this saying that an
   implementation SHOULD support at least one non-NULL
   encryption TLS cipher suite? Or something else? If not,
   color me clueless, of course. But if so ... I don't think
   this is a 2119 SHOULD, because IIUC, you're basically
   saying, if you don't support message encryption, then any
   eavesdropper can read the messages, right?

 + WH: Your guess is correct.  The SHOULD is saying you
   SHOULD support a non-NULL encryption algorithm.  But I'm
   not sure why you're saying the SHOULD is out of place or
   being used incorrectly.  The first half of the paragraph
   is really there to justify the SHOULD in the first place:
   you SHOULD implement encryption so that bad things can't
   happen.

   Feel free to clarify your comment further as to why you
   think the sentence should be deleted, but I don't (yet?) see
   a reason to delete it.


Oh, I agree that you shouldn't delete it, especially since you confirmed 
that it's normative. I was hoping for something a little more precise (like, 
naming a mandatory-to-implement non-NULL encryption cipher suite :-) and I'm 
now wondering why it's not a MUST/MUST unless X. But do the right thing ;-).



5 WONTDO 2)

   The client selects the appropriate certificate and cipher_suites
   for the key agreement based on the tmSecurityName and the
   tmRequestedSecurityLevel for the session.  For sessions being
   established as a result of a SNMP-TARGET-MIB based operation, the
   certificate will potentially have been identified via the
   tlstmParamsTable mapping and the cipher_suites will have to be
   taken from system-wide or implementation-specific configuration.
   If no row in the tlstmParamsTable exists then implementations MAY
   choose to establish the connection using a default client
   certificate available to the application.  Otherwise, the
   certificate and appropriate cipher_suites will need to be passed
   to the openSession() ASI as supplemental information or
   configured through an implementation-dependent mechanism.  It is
   also implementation-dependent and possibly policy-dependent how
   tmRequestedSecurityLevel will be used to influence the security
   capabilities provided by the (D)TLS connection.  However this is
   done, the security capabilities provided by (D)TLS MUST be at
   least as high as the level of security indicated by the
   tmRequestedSecurityLevel parameter.  The actual security level of
   the session is reported in the tmStateReference cache as
   tmSecurityLevel.  For (D)TLS to provide strong authentication,
   each principal acting as a command generator SHOULD have its own
   certificate.

   + Spencer (minor): again, this doesn't sound like 2119
 language to me - it sounds like a statement of fact. Are you
 saying something like If multiple principals acting as
 command generators share a certificate, (D)TLS cannot
 provide strong authentication?

   + Functionally, yes.  We're saying you SHOULD use separate
 certificates for each command generator principal to achieve
 stronger security.  It's important that implementations
 support this so that the protocol can be used securely.


This is kind of the same comment as the previous one - what I think you're 
saying, in 2119-ese, is something like Each principal acting as a command 
generator MUST have its own certificate, unless the principal is not relying 
on (D)TLS to provide strong authentication. But again, do the right thing.



6 DONE 2) continued:
~
   If the connection is being established for reasons other than
   configuration found in the SNMP-TARGET-MIB then configuration and
   procedures outside the scope of this document should be followed.

   + Spencer (clarity): I couldn't parse reasons other than 
connection

 found in the SNMP-TARGET-MIB at all - not enough to make a
 suggestion. Is connection found in the SNMP-TARGET-MIB a 
reason?

 If so, I'd suggest putting it in quotes.

   + WH: this was recently changed to the 

Re: [Gen-art] Gen-ART review of draft-ietf-isms-dtls-tm-09

[Spencer Dawkins]

Hi, Wes,

All of these work for me - and thanks for the explanations.

Thanks especially for the change to 6 - I was thinking gotta get my eyes 
checked! ...


Spencer


2 WONTDO 3.1.1.  Threats
~


SD Oh, I agree that you shouldn't delete it, especially since you
SD confirmed that it's normative. I was hoping for something a little
SD more precise (like, naming a mandatory-to-implement non-NULL
SD encryption cipher suite :-) and I'm now wondering why it's not a
SD MUST/MUST unless X. But do the right thing ;-).

The idea was to leave algorithm requirements up to the base-protocols.
SNMP has a long history of not mandating encryption (for reasons that
are historic and probably no longer valid), and we didn't want to change
that.  Hence the SHOULD.

Anyway, I'll leave it as is and consider this closed.  Thanks!

[similarly for the 2119 issue]


6 DONE 2) continued:
~

If the connection is being established for reasons
other than configuration found in the SNMP-TARGET-MIB
then configuration and procedures outside the scope of
this document should be followed.  Configuration


SD I'm easily confused, but isn't this sentence word-for-word what the
SD original text said? :D

Um, whoops.  Wrong copy/paste apparently.  I should have quoted this:

  If the connection is being established from configuration based
  on SNMP-TARGET-MIB configuration, then the snmpTlstmAddrTable
  DESCRIPTION clause describes how the verification is done (using
  either a certificate fingerprint, or an identity authenticated
  via certification path validation).

Which spells out more clearly configuration based on instead of
reasons.

SD If this is clear to those skilled in the art, no problem. I'm just
SD telling you I can't parse it!

No, I'm sure it's confusing to anyone without a strong background in how
the SNMP-TARGET-MIB works in SNMP.  We've tried to make it clean but I'm
more than certain to someone without knowledge of how the
SNMP-TARGET-MIB works you'd get quickly lost.

--
Wes Hardaker
Cobham Analytic Solutions 


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

[Gen-art] Gen-ART review of draft-freed-sieve-notary-07

[Spencer Dawkins]

Document: draft-freed-sieve-notary-07
Reviewer: Spencer Dawkins
Review Date: 2010-04-05
IESG Telechat date: 2010-04-08

Summary: This draft is roughly ready for publication as a Proposed Standard. 
I found one minor problem which MIGHT just be a cut-and-paste error, but 
someone needs to look at it...


Thanks,

Spencer

7.  redirect-deliverby extension

  :bytime specifies the number of seconds within which the message
  should be delivered. :bymode specifies whether a notification should
  be sent or the message simply returned if the time limit is exceeded.
  The default is return if :bymode is not specified.  See The
  semantics of delivery time limits are specified and discussed at
  length in [RFC2852].

Spencer (minor): I'm not sure if this is a cut-and-paste error or if you 
really meant to say something that got left out, but someone smarter than I 
am needs to look at the See The here. 


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

[Gen-art] Gen-ART review for draft-ietf-ipsecme-esp-null-heuristics-06.txt (was: Re: Gen-ART review for draft-ietf-ipsecme-esp-null-heuristics-05.txt)

[Spencer Dawkins]

Hi, Tero,

Thank you for fixing my suggested text (writing text is hard :-)

Russ,

-06 addresses all of my review comments from -05. It's ready for
publication as an Informational RFC, from a Gen-ART perspective. I did spot
one This heuristics in new text that should be This heuristic, but 
that's an RFC

Editor note, not a draft respin.

Thanks,

Spencer



Spencer Dawkins writes:

I don't feel strongly about this, but do suggest s/uses the same
policy/uses
the same policy, and that changes to that single policy can be
coordinated
throughout the administrative domain/, to capture what you said in your
response, which I found helpful.


Changed that sentence as you suggested and the full sentence is now:

   Also, such a solution might require some kind of centralized
   policy management to make sure everybody in an administrative
   domain uses the same policy, and that changes to that single
   policy can be coordinated throughout the administrative
   domain.


I saw that this isn't a 2119 document, but it's hard for people who are
familiar with 2119 language to ignore the words when they are in lower
case
:D

I really liked the explanation you gave in your response here. I suggest
picking one of can/will/should, probably can, and including your
response in the document.

The resulting text (with some additional edits) might look something like
As ESP-NULL heuristics need to know the same protocols as a deep
inspection
device, an ESP-NULL instance of an unknown protocol can be handled the
same
way as a cleartext instance of the same unknown protocol.


Changed to the text you suggested.


OK, that's the part that was missing for me. I would suggest the packet
has
already transited a NAT box which changed the IP addresses but assumed
any
ESP payload was encryped and did not recalculate the transport checksums
with the new IP addresses. Thus


Made the changes you requested, but used fix instead recalculate
as most of the nats do not recalculate checksum, but do incremental
update on it. The whole text section is now:

 The most obvious field, TCP checksum, might not be usable, as it
 is possible that the packet has already transited a NAT box
 which changed the IP addresses but assumed any ESP payload was
 encrypted and did not fix the transport checksums with the new
 IP addresses. Thus the IP numbers used in the checksum are
 wrong, thus the checksum is wrong.


This explanation is helpful. I'd suggest adding This hueristic is most
helpful when only one packet is outstanding. For example, if a TCP SYN
packet is lost, the next packet would always be a retransmission of the
SYN
packet.


Changed (with minor edits) as you suggested. The full text is now:

 One good method of detection is if a packet is dropped then the
 next packet will most likely be a retransmission of the previous
 packet. Thus if two packets are received with the same source,
 and destination port numbers, and where sequence numbers are
 either same or right after each other, then it's likely a TCP
 packet has been correctly detected. This heuristics is most
 helpful when only one packet is outstanding. For example, if a
 TCP SYN packet is lost (or dropped because of policy), the next
 packet would always be a retransmission of the same TCP SYN
 packet.


Your explanation was very helpful. I'd suggest

Forcing use of ESP-NULL everywhere inside the enterprise, so that
accounting, logging, network monitoring, and intrusion detection all
work,
increases the risk of sending confidential information where
eavesdroppers
can see it


Changed to use your text.

I updated the draft and submitted 06 version which includes these
changes.
--
kivi...@iki.fi


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

[Gen-art] Gen-ART review of draft-ietf-geopriv-lis-discovery-13

[Spencer Dawkins]

Document: draft-ietf-geopriv-lis-discovery-13
Reviewer: Spencer Dawkins
Review Date: 2010-02-16
IESG Telechat date: 2010-02-18

Summary: This document is ready for publication as a Proposed Standard. My 
question on -11 has been addressed to my satisfaction, and I have no 
concerns or suggestions on text that has been added since -11.


Martin, thanks for taking my last call question into account.

Thanks,

Spencer

I have been selected as the General Area Review Team (Gen-ART)reviewer for 
this draft (for background on Gen-ART, please 
seehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).Please resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-geopriv-lis-discovery-11
Reviewer: Spencer Dawkins
Review Date: 2009-10-21
IETF LC End Date: 2009-10-29
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed 
Standard.


I have one minor question, as follows:

2.2.  Virtual Private Networks (VPNs)

  LIS discovery over a VPN network interface SHOULD NOT be performed.
  A LIS discovered in this way is unlikely to have the information
  necessary to determine an accurate location.

Spencer (minor): I'm having a difficult time imagining why this is a 
SHOULD and not a MUST. When is LIS discovery over a VPN would be the 
*right* thing to do? I note that the related text in the following 
paragraph is MUST NOT unless - I'd be more comfortable seeing similar 
text here.


  Not all interfaces connected to a VPN can be detected by devices or
  the software running on them.  A LIS MUST NOT provide location
  information in response to requests that it can identify as
  originating from a device on the remote end of a VPN tunnel, unless
  it is able to accurately determine location.  The notLocatable HELD
  error code can be used to indicate to a device that discovery has
  revealed an unsuitable LIS.  This ensures that even if a device
  discovers a LIS over the VPN, it does not rely on a LIS that is
  unable to provide accurate location information.
___
Ietf mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
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 for draft-ietf-ipsecme-esp-null-heuristics-05.txt

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-ipsecme-esp-null-heuristics-05.txt
Reviewer: Spencer Dawkins
Review Date: 2010-02-15 (sorry!)
IETF LC End Date: 2010-02-10
IESG Telechat date: (not known)
Summary:

1.2.  Terminology

  IPsec Flow

 An IPsec flow is a stream of packets sharing the same source IP,
 destination IP, protocol (ESP/AH) and SPI.  Strictly speaking, the
 source IP does not need to be as part of the flow identification,
 but as it can be there depending on the receiving implementation
 it is safer to assume it is always part of the flow
 identification.

Spencer (clarity): Last sentence is difficult to parse. My suggestion is to
use something like

An IPsec flow is a stream of packets sharing the same source IP, destination
IP, protocol (ESP/AH) and SPI.  Strictly speaking, the source IP does not
need to be as part of the flow identification, but it can be. For this
reason, it is safer to assume that the source IP is always part of the flow
indentification.

2.1.  AH

  The another problem is that in the new IPsec Architecture [RFC4301]

Spencer (clarity): The second problem or Another Problem here...

  the support for AH is now optional, meaning not all implementations
  support it.  ESP-NULL has been defined to be mandatory to implement
  by the Cryptographic Algorithm Implementation Requirements for
  Encapsulating Security Payload (ESP) document [RFC4835].

  AH has also quite complex processing rules compared to ESP when
  calculating the ICV, including things like zeroing out mutable
  fields, also as AH is not as widely used than ESP, the AH support is
  not as well tested in the interoperability events.

Spencer (clarity): I think there needs to be a semicolon or other break
before also.

2.2.  Mandating by Policy

  Another easy way to solve this problem is to mandate the use of ESP-
  NULL with common parameters within an entire organization.  This
  either removes the need for heuristics (if no ESP encrypted traffic
  is allowed at all) or simplifies them considerably (only one set of
  parameters needs to be inspected, e.g. everybody in the organization
  who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity
  algorithm).  This does not work unless one of a pair of communicating
  machines is not under the same administrative domain as the deep

Spencer (minor): I don't understand. I expected this to say DOES work
unless. The text says that's the only situation where it fails!

  inspection engine.  (IPsec Security Associations must be satisfactory
  to all communicating parties, so only one communicating peer needs to
  have a sufficiently narrow policy.)  Also, such a solution might
  require some kind of centralized policy management to make sure
  everybody in an administrative domain uses the same policy.

Spencer (minor): Is it fair to point out that this type of heuristic will
make changing the common attribute value you're looking for more difficult?
If you decide to move away from HMAC-SHA-1-96, for instance...

3.  Description of Heuristics

  As described in section 7, UDP encapsulated ESP traffic may also have
  have NAPT applied to it, and so there is already a 5-tuple state in
  the stateful inspection gateway

Spencer (nit): missing period for this sentence.

4.  IPsec flows

  ESP is a stateful protocol, meaning there is state stored in the both

Spencer (nit): s/the both/both/

  end nodes of the ESP IPsec SA, and the state is identified by the
  pair of destination IP and SPI.  End nodes also often fix the source
  IP address in an SA unless the destination is a multicast group.
  Typically most (if not all) flows of interest to an intermediate
  device are unicast, so it is safer to assume the receiving node also
  uses a source address, and the intermediate device should therefore
  do the same.  In some cases this might cause extraneous cached ESP
  IPsec SA flows, but by using the source address two distinct flows
  will never be mixed.  For sites which heavily use multicast, such
  traffic is deterministically identifiable (224.0.0.0/4 for IPv4 and
  ff00::0/8 for IPv6), and an implementation can save the space of
  multiple cache entries for a multicast flow by checking the
  destination address first.

  There are several reasons why a single packet might not be enough to
  detect type of flow.  One of them is that the next header number was
  unknown, i.e. if heuristics do not know about the protocol for the
  packet, it cannot verify it has properly detected ESP-NULL
  parameters, even when the packet otherwise looks like ESP-NULL.  If
  the packet does not look like ESP-NULL at all, then encrypted ESP
  status can be returned quickly.  As ESP-NULL heuristics should

Re: [Gen-art] Gen-ART review fordraft-ietf-ipsecme-esp-null-heuristics-05.txt

[Spencer Dawkins]

(snort) And now, for the high-order bit :D



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 resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-ipsecme-esp-null-heuristics-05.txt
Reviewer: Spencer Dawkins
Review Date: 2010-02-15 (sorry!)
IETF LC End Date: 2010-02-10
IESG Telechat date: (not known)
Summary:


This document is almost ready for publication as an Informational RFC. I do 
have a small number of minor questions, provided in my review, but none are 
show-stoppers. I also have noted a small number of nits and suggestions for 
improved clarity, which are not part of the Gen-ART review, but are offered 
to the document editor for possible inclusion. 


___
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-behave-turn-uri-08

[Spencer Dawkins]

Russ asked me if -08 addressed my comments - it does, and does not introduce 
any new text that I needed to comment on. Ready for publication as Proposed 
Standard, in my opinion.


Thanks!

Spencer



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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-behave-turn-uri-05
Reviewer: Spencer Dawkins
Review Date: 2010-01-11
IETF LC End Date: 2010-01-13
IESG Telechat date: (not known)

Summary: This draft is almost ready for publication as a Proposed 
Standard. I have a couple of minor questions, shown below in sections 3 
and 6.1.


Nits and readability comments aren't actually part of the review - they're 
for the author and editors...


Spencer

1.  Introduction

  The TURN specification [I-D.ietf-behave-turn] defines a process for a
  TURN client to find TURN servers by using DNS SRV resource records,
  but this process does not let the TURN server administrators
  provision the preferred TURN transport protocol between the client
  and the server and for the TURN client to discover this preference.

Spencer (readability): s/for/does not allow/ ?

  This document defines an S-NAPTR application [RFC3958] for this
  purpose.  This application defines RELAY as an application service
  tag and turn.udp, turn.tcp, and turn.tls as application
  protocol tags.

  Another usage of the resolution mechanism described in this document
  would be Remote Hosting as described in [RFC3958] section 4.4.  For
  example a VoIP provider who does not want to deploy TURN servers
  could use the servers deployed by another company but could still
  want to provide configuration parameters to its customers without
  explicitly showing this relationship.  The mechanism permits one to
  implement this indirection, without preventing the company hosting
  the TURN servers from managing them as it see fit.

Spencer (nit): s/see/sees/

  [I-D.petithuguenin-behave-turn-uri-bis] can be used as a convenient
  way of carrying the four components needed by the resolution
  mechanism described in this document.

3.  Resolution Mechanism

  An Allocate error response as specified in section 6.4 of
  [I-D.ietf-behave-turn] is processed as a failure as specified by
  [RFC3958] section 2.2.4.  The resolution stops when a TURN client
  gets a successful Allocate response from a TURN server.  After an
  allocation succeeds or all the allocations fail, the resolution
  context MUST be discarded and the resolution algorithm MUST be
  restarted from the beginning for any subsequent allocation.  Servers
  blacklisted as described in section 6.4 of [I-D.ietf-behave-turn]
  SHOULD NOT be used for the specified duration even if returned by a

Spencer (minor): I'm not sure why SHOULD NOT is appropriate here. If this 
isn't MUST NOT, I'm not sure it should be 2119 language. Is this just 
saying if you include blacklisted servers, good things will probably not 
happen?


  subsequent resolution.

  First the resolution algorithm checks that the parameters can be
  resolved with the list of TURN transports supported by the
  application:

Spencer (readability): I'm surprised that the following information is not 
shown as a table - Table 1 is showing something a lot more straightfoward, 
so I know you guys know how to create tables!


  o  If secure is false and transport is defined as udp but the
 list of TURN transports supported by the application does not
 contain UDP then the resolution MUST stop with an error.
  o  If secure is false and transport is defined as tcp but the
 list of TURN transports supported by the application does not
 contain TCP then the resolution MUST stop with an error.
  o  If secure is true and transport is defined as udp then the
 algorithm MUST stop with an error.
  o  If secure is true and transport is defined as tcp but the
 list of TURN transports supported by the application does not
 contain TLS then the resolution MUST stop with an error.
  o  If secure is true and transport is not defined but the list of
 TURN transports supported by the application does not contain TLS
 then the resolution MUST stop with an error.
  o  If transport is defined but unknown then the resolution MUST
 stop with an error.

  5.  If the first NAPTR query in the previous step does not return any
  result then the SRV algorithm defined in [RFC2782] is used to
  generate a list of IP address and port tuples.  The SRV algorithm
  is applied by using each transport in the filtered list of TURN
  transports supported by the application for the Protocol, host
  for the Name, turn for the Service if secure is false or
  turns for the Service if secure is true.  The same transport
  that was used to generate a list of tuples is used with each

Re: [Gen-art] Gen-ART Review of draft-ietf-behave-turn-uri-05

[Spencer Dawkins]

Hi, Marc...

Works for me, and thank you for grokking what I was asking about (not 
replacing this document before PUBLICATION, but after publication and 
before creating the registry entry).


Thanks,

Spencer

- Original Message - 
From: Marc Petit-Huguenin m...@petit-huguenin.org

To: Spencer Dawkins spen...@wonderhamster.org
Cc: draft-ietf-behave-turn-...@tools.ietf.org; i...@ietf.org; General 
Area Review Team gen-art@ietf.org

Sent: Tuesday, January 12, 2010 12:19 PM
Subject: Re: Gen-ART Review of draft-ietf-behave-turn-uri-05



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Spencer,

Thanks for the review.  See below for my comments.

On 01/11/2010 03:07 PM, Spencer Dawkins 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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-behave-turn-uri-05
Reviewer: Spencer Dawkins
Review Date: 2010-01-11
IETF LC End Date: 2010-01-13
IESG Telechat date: (not known)

Summary: This draft is almost ready for publication as a Proposed
Standard. I have a couple of minor questions, shown below in sections 3
and 6.1.

Nits and readability comments aren't actually part of the review -
they're for the author and editors...

Spencer

1.  Introduction

  The TURN specification [I-D.ietf-behave-turn] defines a process for a
  TURN client to find TURN servers by using DNS SRV resource records,
  but this process does not let the TURN server administrators
  provision the preferred TURN transport protocol between the client
  and the server and for the TURN client to discover this preference.

Spencer (readability): s/for/does not allow/ ?


Applied.



  This document defines an S-NAPTR application [RFC3958] for this
  purpose.  This application defines RELAY as an application service
  tag and turn.udp, turn.tcp, and turn.tls as application
  protocol tags.

  Another usage of the resolution mechanism described in this document
  would be Remote Hosting as described in [RFC3958] section 4.4.  For
  example a VoIP provider who does not want to deploy TURN servers
  could use the servers deployed by another company but could still
  want to provide configuration parameters to its customers without
  explicitly showing this relationship.  The mechanism permits one to
  implement this indirection, without preventing the company hosting
  the TURN servers from managing them as it see fit.

Spencer (nit): s/see/sees/


Applied.



  [I-D.petithuguenin-behave-turn-uri-bis] can be used as a convenient
  way of carrying the four components needed by the resolution
  mechanism described in this document.

3.  Resolution Mechanism

  An Allocate error response as specified in section 6.4 of
  [I-D.ietf-behave-turn] is processed as a failure as specified by
  [RFC3958] section 2.2.4.  The resolution stops when a TURN client
  gets a successful Allocate response from a TURN server.  After an
  allocation succeeds or all the allocations fail, the resolution
  context MUST be discarded and the resolution algorithm MUST be
  restarted from the beginning for any subsequent allocation.  Servers
  blacklisted as described in section 6.4 of [I-D.ietf-behave-turn]
  SHOULD NOT be used for the specified duration even if returned by a

Spencer (minor): I'm not sure why SHOULD NOT is appropriate here. If
this isn't MUST NOT, I'm not sure it should be 2119 language. Is this
just saying if you include blacklisted servers, good things will
probably not happen?


Hmmm.  The purpose of this text is to prevent a client to continuously try 
to
reach a crashed TURN server when the DNS cache will still continue to 
return the

RRs for the duration of the TTL.  I am not sure that this count as an
interoperability issue but I think that this is something that must be 
prevented

so unless someone complain I will change the SHOULD NOT to a MUST NOT.



  subsequent resolution.

  First the resolution algorithm checks that the parameters can be
  resolved with the list of TURN transports supported by the
  application:

Spencer (readability): I'm surprised that the following information is
not shown as a table - Table 1 is showing something a lot more
straightfoward, so I know you guys know how to create tables!

  o  If secure is false and transport is defined as udp but the
 list of TURN transports supported by the application does not
 contain UDP then the resolution MUST stop with an error.
  o  If secure is false and transport is defined as tcp but the
 list of TURN transports supported by the application does not
 contain TCP then the resolution MUST stop with an error.
  o  If secure is true and transport is defined as udp then the
 algorithm MUST stop with an error.
  o  If secure is true and transport is defined as tcp but the
 list of TURN transports supported

Re: [Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18

[Spencer Dawkins]

Hi, Simon (and dropping i...@ietf.org)...

I agree with your responses to me, to Nicholas, and to Alexey.

Thanks!

Spencer

- Original Message - 
From: Simon Josefsson si...@josefsson.org

To: Alexey Melnikov alexey.melni...@isode.com
Cc: General Area Review Team gen-art@ietf.org; 
draft-ietf-sasl-...@tools.ietf.org; i...@ietf.org; Nicolas Williams 
nicolas.willi...@sun.com

Sent: Friday, January 08, 2010 6:25 AM
Subject: Re: Gen-ART review of draft-ietf-sasl-gs2-18



Alexey Melnikov alexey.melni...@isode.com writes:


The I-D says:

   The original
  GSS-API-SASL mechanism bridge was specified by [RFC], now
  [RFC4752]; we shall sometimes refer to the original bridge as GS1 in
  this document.

I don't see anything wrong with that.


Very well. I forgot about that.


There's good reason, even, to want to use GS1 to refer to RFC4572:
RFC/4572's use of GSSAPI to refer to the Kerberos V5 GSS-API
mechanism is wrong and confusing.  Avoiding confusion is a good thing.



Personally I dislike unnecessary indirection, as it allows for extra
confusion as well. There is only 1 mechanism in GS1 family (ignoring
GSS-SPNEGO), it is called GSSAPI. So I think the original text is
actually better, if we add a reference and change prefer to use:

 If the application requires SASL security layers then it MUST use the
 SASL GSSAPI mechanism [RFC4572] instead of GS2-KRB5 or 
GS2-KRB5-PLUS.


Opinions?


I used this text too.

/Simon
___
Ietf mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf 


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

[Gen-art] Fw: Gen-ART review of draft-ietf-fecframe-interleaved-fec-scheme-05

[Spencer Dawkins]

Sent from my non-subscribed e-mail address - just for the archives...

Spencer

- Original Message - 
From: Spencer Dawkins spen...@mcsr-labs.org

To: draft-ietf-fecframe-interleaved-fec-sch...@tools.ietf.org
Cc: General Area Review Team gen-art@ietf.org
Sent: Tuesday, January 05, 2010 7:16 PM
Subject: Gen-ART review of draft-ietf-fecframe-interleaved-fec-scheme-05



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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-fecframe-interleaved-fec-scheme-05
Reviewer: Spencer Dawkins
Review Date: 2010-01-05 (way late)...
IETF LC End Date: 2009-12-11
IESG Telechat date: 2010-12-07

Summary: This draft is almost ready for publication as a Proposed 
Standard. In my review, I found a few uses of 2119 language that did not 
seem to be justified (identified below as Spencer (minor):). The ADs 
should consider whether these uses should be changed or left alone.


Abstract

  This document defines a new RTP payload format for the Forward Error
  Correction (FEC) that is generated by the 1-D interleaved parity code
  from a source media encapsulated in RTP.  The 1-D interleaved parity
  code is a systematic code, where a number of repair symbols are
  generated from a set of source symbols and sent in a repair flow
  separate from the source flow that carries the source symbols.  The
  1-D interleaved parity code offers a good protection against bursty
  packet losses at a cost of decent complexity.  The new payload format

Spencer (nit): decent doesn't seem entirely clear here. additional?
reasonable?

  defined in this document is used (with some exceptions) as a part of
  the DVB Application-layer FEC specification.

1.  Introduction

  Note that the source and repair packets belong to different source
  and repair flows, and the sender MUST provide a way for the receivers
  to demultiplex them, even in the case they are sent in the same

Spencer (minor): I'm not used to seeing normative statements in
Introductions, and this MUST appears prior to the requirements conventions
in section 2, but ignoring that - isn't this a statement about the 
mechanism

in this draft, and not (so much) a statement about what a sender MUST do?
(If you use the mechanism described in this draft, doesn't that satisfy 
the

MUST?) I'd suggest something like ... and the sender needs to use a
mechanism that provides a way ..., punting on the 2119 language 
completely.


  transport flow (i.e., same source/destination address/port with UDP).
  This is required to offer backward compatibility (See Section 4).  At
  the receiver side, if all of the source packets are successfully
  received, there is no need for FEC recovery and the repair packets
  are discarded.  However, if there are missing source packets, the
  repair packets can be used to recover the missing information.  Block
  diagrams for the systematic parity FEC encoder and decoder are
  sketched in Figure 1 and Figure 2, respectively.

1.1.  Use Cases

  We generate one interleaved FEC packet out of D non-consecutive
  source packets.  This repair packet can provide a full recovery of
  the missing information if there is only one packet missing among the
  corresponding source packets.  This implies that 1-D interleaved FEC
  protection performs well under bursty loss conditions provided that L
  is chosen large enough, i.e., L-packet duration SHOULD NOT be shorter
  than the duration of the burst that is intended to be repaired.

Spencer (minor): again, I don't think this is a 2119 SHOULD (NOT) - isn't 
it a definition?


  For example, consider the scenario depicted in Figure 4 where the
  sender generates interleaved FEC packets and a bursty loss hits the
  source packets.  Since the number of columns is larger than the
  number of packets lost due to the bursty loss, the repair operation
  succeeds.

1.3.3.  ETSI TS 102 034

  The Annex E of [ETSI-TS-102-034] defines an optional protocol for
  Application-layer FEC (AL-FEC) protection of streaming media for
  DVB-IP services carried over RTP [RFC3550] transport.  AL-FEC
  protocol uses two layers for protection:  a base layer that is
  produced by a packet-based interleaved parity code, and an
  enhancement layer that is produced by a Raptor code.  While the use

Spencer (nit): could you provide a reference for Raptor code, or at 
least include a definition for it?


  of the enhancement layer is optional, the use of the base layer is
  mandatory wherever AL-FEC is used.  The DVB AL-FEC protocol is also
  described in [I-D.ietf-fecframe-dvb-al-fec].

2.  Requirements Notation

  The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
  SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
  document are to be interpreted as described in [RFC2119].

Spencer (nit): boy

[Gen-art] Gen-ART Review of draft-ohba-802dot21-basic-schema-07

[Spencer Dawkins]

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-ohba-802dot21-basic-schema-07

Reviewer: Spencer Dawkins

Review Date: 05 Jan 2010

IESG Telechat date: 07 Jan 2010

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


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

[Gen-art] testing...

[Spencer Dawkins]

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

[Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sasl-gs2-18
Reviewer: Spencer Dawkins
Review Date: 2009-11-30
IETF LC End Date: 2009-11-18 (oops!)
IESG Telechat date: 2009-12-03

Summary: This document is almost ready for publication as a Proposed 
Standard. I did have one minor question about 13.3 (in my LATE review), but 
it should not be difficult to resolve, if an AD agrees with my question.


I did tag a fair number of nits, but these aren't part of the Gen-ART 
review, and are simply included as a convenience for anyone else who edits 
the document.


1.  Introduction

  The GS1 bridge failed to gain wide deployment for any GSS-API
  mechanism other than The Kerberos V5 GSS-API mechanism [RFC1964]

Spencer (nit): s/The Kerberos/The Kerberos/

  [RFC4121], and has a number of problems that lead us to desire a new

Spencer (nit): s/lead/led/

  bridge.  Specifically: a) GS1 was not round-trip optimized, b) GS1
  did not support channel binding [RFC5056].  These problems and the
  opportunity to create the next SASL password-based mechanism, SCRAM

Spencer (nit): please expand SCRAM on first use.

  [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL
  applications via GS2, provide the motivation for GS2.

  In particular, the current consensus of the SASL community appears to
  be that SASL security layers (i.e., confidentiality and integrity
  protection of application data after authentication) are too complex
  and, since SASL applications tend to have an option to run over a
  Transport Layer Security (TLS) [RFC5246] channel, redundant and best
  replaced with channel binding.

Spencer (nit): it's a LONG way from too complex to redundant in this 
sentence ;-) suggest moving redundant before the subclause, just for 
readability.


3.3.  Examples

  The last step translate each decimal value using table 3 in Base32

Spencer (nit): s/translate/translates/?

  [RFC4648].  Thus the SASL mechanism name for the SPKM-1 GSSAPI
  mechanism is GS2-DT4PIK22T6A.

8.  GSS-API Parameters

  The mutual_req_flag MUST be set.  If channel binding is used then the
  client MUST check that the corresponding ret_flag is set when the
  context is fully establish, else authentication MUST fail.

Spencer (nit): s/establish/established/

  Use or non-use of deleg_req_flag and anon_req_flag is an
  implementation-specific detail.  SASL and GS2 implementors are
  encouraged to provide programming interfaces by which clients may
  choose to delegate credentials and by which servers may receive them.
  SASL and GS2 implementors are encouraged to provide programming
  interfaces which provide a good mapping of GSS-API naming options.

11.  GSS_Inquire_mech_for_SASLname call

  To allow SASL clients to more efficiently identify which GSS-API
  mechanism a particular SASL mechanism name refers to we specify a new
  GSS-API utility function for this purpose.

Spencer (nit): whew! hard to parse. Suggest We specify a new GSS-API 
utility function to allow SASL clients to more efficiently identify the 
GSS-API mechanism that a particular SASL mechanism name refers to, or 
something like that?


13.3.  Additional Recommendations

  If the application requires security layers then it MUST prefer the
  SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS.

Spencer (minor): If prefer the mechanism is the right way to describe 
this, I apologize, but I don't know what the MUST means in practice - if 
this needs to be at MUST strength, I'd expect text like MUST use X and MUST 
NOT use Y or Z, or MUST use X unless the server doesn't support X.


14.  GSS-API Mechanisms that negotiate other mechanisms

  A GSS-API mechanism that negotiate other mechanisms interact badly

Spencer (nit): s/negotiate/negotiates/, and probably s/interact/will 
interact/ ?


  with the SASL mechanism negotiation.  There are two problems.  The
  first is an interoperability problem and the second is a security
  concern.  The problems are described and resolved below.

14.1.  The interoperability problem

  If a client implement GSS-API mechanism X, potentially negotiated
  through a GSS-API mechanism Y, and the server also implement GSS-API

Spencer (nit): s/implement/implements/

  mechanism X negotiated through a GSS-API mechanism Z, the
  authentication negotiation will fail.

14.2.  Security problem

  If a client's policy is to first prefer GSSAPI mechanism X, then non-
  GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
  mechanisms Y and Z but not X, then if the client attempts to
  negotiate mechanism X by using a GSS-API mechanism that negotiate

Spencer (nit): s/negotiate/negotiates/

  other mechanisms (such as SPNEGO), it may end up using mechanism Z

Spencer (nit): you provide

Re: [Gen-art] Gen-ART review of draft-reschke-rfc2731bis-04

[Spencer Dawkins]

Version -04 resolves all my previous comments (and adds no new ones ;-)

Thanks,

Spencer

- Original Message - 
From: Spencer Dawkins spen...@wonderhamster.org

To: draft-reschke-rfc2731...@tools.ietf.org
Cc: General Area Review Team gen-art@ietf.org
Sent: Wednesday, September 30, 2009 5:43 PM
Subject: [Gen-art] Gen-ART review of draft-reschke-rfc2731bis-02



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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-reschke-rfc2731bis-02
Reviewer: Spencer Dawkins
Review Date: 2009-10-01
IETF LC End Date: 2009-10-07
IESG Telechat date: (not known)

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


I have three comments on this short draft...

I wish the IETF community had a clearer understanding of the relationship 
between Historic and Obsolete than we have, but that's a comment for IESG 
action, not a comment that can be reasonably made in response to Last Call 
for this document. Having said that, I THINK this document should be doing 
both (setting RFC 2731 to Historic AND Obsolete in the RFC Editor 
database). The title says one, and the text says the other - both should 
mention both actions, because neither is a superset of the other.


I agree with David Harrington's Last Call comment that including the name 
of the RFC being declared Obsolete/Historic in the title of this draft 
would be appropriate. I don't expect most members of the IETF community 
would remember what RFC 2731 was about (sure, you can actually open the 
document, but most of us probably wouldn't need to do that).


Julian pointed out in Last Call discussion that the Dublin Initiative has 
been maintaining this specification for nearly 10 years. It would probably 
be helpful if the document provided this timestamp - perhaps something 
like


  [RFC2731] defines Encoding Dublin Core Metadata in HTML.  Newer
  specifications published by the Dublin Core Metadata Initiative [1]
  (DCMI) over the past decade, in particular Expressing Dublin Core 
metadata using HTML/

  ^^^  ^^
  XHTML meta and link elements (DC-HTML,
  http://dublincore.org/documents/dc-html/), have obsoleted this
  work.

Thanks,

Spencer


___
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

Re: [Gen-art] Gen-ART review of draft-ietf-geopriv-lbyr-requirements-09

[Spencer Dawkins]

Hi, Richard,

Yes, -09 does address all the comments I sent on -07.

Thanks for your quick response!

Spencer

- Original Message - 
From: Richard Barnes rbar...@bbn.com

To: Spencer Dawkins spen...@wonderhamster.org
Cc: draft-ietf-georpiv-lbyr-requireme...@tools.ietf.org
Sent: Monday, November 30, 2009 4:39 PM
Subject: Re: Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07



Spencer,

-09 is out now:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-lbyr-requirements-09.txt

Does these changes address your concerns?

--Richard



On Oct 21, 2009, at 8:30 PM, Spencer Dawkins wrote:


Hi, Russ,

I'm sorry, but I don't see text changes based on my comments in 
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lbyr-requirements/draft-ietf-geopriv-lbyr-requirements-08-from-07.diff.html .


Some of them were nits, which aren't actually part of the Gen-ART 
review, but my concerns about 2119 language and a couple of  sentences 
that didn't parse probably are worth looking at (just  search for pars 
in my review).


Thanks,

Spencer



Spencer:

Draft -08 is on the telechat agenda for tomorrow.  Does it resolve  your 
concerns?


Russ

At 06:47 PM 6/3/2009, Spencer Dawkins 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 resolve these comments along with any other Last Call  comments
you may receive.

Document: draft-ietf-geopriv-lbyr-requirements-07
Reviewer: Spencer Dawkins
Review Date: 2009-06-03
IETF LC End Date: 2009-06-09
IESG Telechat date: (not known)

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


Comments: Most of my notes below involve text clarity. I did  question 
one 2119 keyword use in Section 4.1, as well.



1.  Introduction

 Location determination, different than location configuration or

Spencer (clarity): Is this s/different than/as distinct from/ ?  but 
this sentence didn't parse for me.


 dereferencing, often includes topics related to manual provisioning
 processes, automated location calculations based on a variety of
 measurement techniques, and/or location transformations, (e.g.,  geo-
 coding), and is beyond the scope of this document.

 The issues around location configuration protocols have been
 documented in a location configuration protocol problem statement  and
 requirements document [I-D.ietf-geopriv-l7-lcp-ps].  There are
 currently several examples of a location configuration protocols
 currently proposed, including, DHCP
 [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD

Spencer (clarity): got a reference for LLDP-MED here?

 [I-D.ietf-geopriv-http-location-delivery] protocols.


2.  Terminology

 Location Configuration Protocol:  A protocol which is used by a
client to acquire either location or a location URI from a

Spencer (clarity): I'm guessing here that you mean s/either 
location/either a location object/


location configuration server, based on information unique to  the
client.

3.3.  Location URI Authorization

 Location URIs manifest themselves in a few different forms.  The
 different ways that a location URI can be represented is based on
 local policy, and are depicted in the following four scenarios.

 1. No specific information at all:  As is typical, a location URI  is

Spencer (clarity): could this be something more like No location 
information included in the URI:?


used to get location information.  However, in this case, the  URI
representation itself does not need to reveal any specific
information at all.  Location information is acquired by the
dereferencing operation a location URI.

 2. No user specific information:  By default, a location URI MUST  NOT

Spencer (clarity): could this be URI does not identify a user:?

reveal any information about the Target other than location
information.  This is true for the URI itself, (or in the  document
acquired by dereferencing), unless policy explicitly permits
otherwise.

3.4.  Location URI Construction

 Depending on local policy, a location URI may be constructed in  such
 a way as to make it difficult to guess.  Accordingly, the form of  the
 URI is then constrained by the degree of randomness and uniqueness
 applied to it.  In this case, it may be important to protect the
 actual location information from inspection by an intermediate  node.

Spencer (clarity): is this section applicable to all of the  scenarios 
in the previous section, or just to possession  authorization model? 
If not applicable to all, you might point  that out here.


 Construction of a location URI in such a way as to not reveal any
 domain, user, or device specific information, with the goal of  making
 the location URI appear bland, uninteresting, and generic, may be
 helpful to some degree in order to keep location information more
 difficult to detect.  Thus

[Gen-art] Fw: Gen-ART review of draft-ietf-geopriv-lis-discovery-11

[Spencer Dawkins]

OK, I'm an idiot. I forgot to copy gen-art on my review... fixing that now. 
Sorry!


Spencer


I have been selected as the General Area Review Team (Gen-ART)reviewer for 
this draft (for background on Gen-ART, please 
seehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).Please resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-geopriv-lis-discovery-11
Reviewer: Spencer Dawkins
Review Date: 2009-10-21
IETF LC End Date: 2009-10-29
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed 
Standard.


I have one minor question, as follows:

2.2.  Virtual Private Networks (VPNs)

  LIS discovery over a VPN network interface SHOULD NOT be performed.
  A LIS discovered in this way is unlikely to have the information
  necessary to determine an accurate location.

Spencer (minor): I'm having a difficult time imagining why this is a 
SHOULD and not a MUST. When is LIS discovery over a VPN would be the 
*right* thing to do? I note that the related text in the following 
paragraph is MUST NOT unless - I'd be more comfortable seeing similar 
text here.


  Not all interfaces connected to a VPN can be detected by devices or
  the software running on them.  A LIS MUST NOT provide location
  information in response to requests that it can identify as
  originating from a device on the remote end of a VPN tunnel, unless
  it is able to accurately determine location.  The notLocatable HELD
  error code can be used to indicate to a device that discovery has
  revealed an unsuitable LIS.  This ensures that even if a device
  discovers a LIS over the VPN, it does not rely on a LIS that is
  unable to provide accurate location information.
___
Ietf mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf 


___
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-vpn-option-11.txt

[Spencer Dawkins]

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

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

Document: draft-ietf-dhc-vpn-option-11.txt
Reviewer: Spencer Dawkins
Review Date: 2009-10-21
IETF LC End Date: 2009-10-16 (sorry!)
IESG Telechat date: 2009-10-22 (double-sorry!)

Summary: This draft is almost ready for publication as a Proposed Standard. 
I had two questions about 2119 language in section 5, as follows:


5.  Relay Agent Behavior

  A DHCPv4 relay agent SHOULD include a DHCPv4 VSS sub-option in a
  relay-agent-information option [RFC3046], while a DHCPv6 relay agent
  SHOULD include a DHCPv6 VSS option in the Relay-forward message.

Spencer (minor): is this functionality supposed to work if either SHOULD is 
violated? I'm wondering why these are not MUSTs.


  The value placed in the Virtual Subnet Selection sub-option or option
  SHOULD be sufficient for the relay agent to properly route any DHCP

Spencer (minor): I don't think this is a 2119 SHOULD. I'm thinking more 
like a statement of fact - perhaps will be sufficient? If it's really 
2119, why isn't it a MUST?


  reply packet returned from the DHCP server to the DHCP client for
  which it is destined.


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

[Gen-art] Gen-ART review of draft-reschke-rfc2731bis-02

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-reschke-rfc2731bis-02
Reviewer: Spencer Dawkins
Review Date: 2009-10-01
IETF LC End Date: 2009-10-07
IESG Telechat date: (not known)

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


I have three comments on this short draft...

I wish the IETF community had a clearer understanding of the relationship 
between Historic and Obsolete than we have, but that's a comment for IESG 
action, not a comment that can be reasonably made in response to Last Call 
for this document. Having said that, I THINK this document should be doing 
both (setting RFC 2731 to Historic AND Obsolete in the RFC Editor database). 
The title says one, and the text says the other - both should mention both 
actions, because neither is a superset of the other.


I agree with David Harrington's Last Call comment that including the name of 
the RFC being declared Obsolete/Historic in the title of this draft would be 
appropriate. I don't expect most members of the IETF community would 
remember what RFC 2731 was about (sure, you can actually open the document, 
but most of us probably wouldn't need to do that).


Julian pointed out in Last Call discussion that the Dublin Initiative has 
been maintaining this specification for nearly 10 years. It would probably 
be helpful if the document provided this timestamp - perhaps something like


  [RFC2731] defines Encoding Dublin Core Metadata in HTML.  Newer
  specifications published by the Dublin Core Metadata Initiative [1]
  (DCMI) over the past decade, in particular Expressing Dublin Core 
metadata using HTML/

  ^^^  ^^
  XHTML meta and link elements (DC-HTML,
  http://dublincore.org/documents/dc-html/), have obsoleted this
  work.

Thanks,

Spencer


___
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-l3vpn-2547bis-mcast-bgp-07

[Spencer Dawkins]

Hi, Yakov,

Thanks for the quick response (I can still remember what I was thinking).

Thanks also for the explanation that you're not able to tighten a couple of 
SHOULDs to MUSTs because of previous specifications. Makes sense to me 
(should be flogging the OTHER document).


I think we're agreeing on everything else, so that's fine.

We should be good to go with a revised draft with these changes, from my 
perspective.


Spencer



Spencer,


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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-l3vpn-2547bis-mcast-bgp-07
Reviewer: Spencer Dawkins
Review Date: 2009-09-17 (oops!)
IETF LC End Date: 2009-09-08
IESG Telechat date: (not known)

Summary: This draft is almost ready for publication as a Proposed 
Standard.
I have some comments, mostly 2119 language plus some sentences that 
didn't

parse and seemed important.


Many thanks for your review and comments.

Response to your comments in-line...



Abstract

   This document describes the BGP encodings and procedures for
   exchanging the information elements required by Multicast in MPLS/BGP
   IP VPNs, as specified in [MVPN].

Spencer (nit): I'd expect the RFC Editor to remove a reference in the
Abstract section.

2. Introduction

   This document describes the BGP encodings and procedures for
   exchanging the information elements required by Multicast in MPLS/BGP
   IP VPNs, as specified in [MVPN]. This document assumes a thorough
   familiarity with procedures, concepts and terms described in [MVPN].

   This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI

Spencer (nit): I'd expect the RFC Editor to ask that abbreviations be
expanded on first use.

   is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel
   binding, advertising (C-S, C-G) to S-PMSI tunnel binding, VPN
   customer multicast routing information exchange among PEs, choosing a
   single forwarder PE, and for procedures in support of co-locating a
   C-RP on a PE.

5. PMSI Tunnel attribute

   When a router that receives a BGP Update that contains the PMSI
   Tunnel attribute with its Partial bit set determines that the
   attribute is malformed, the router SHOULD treat this Update as though
   all the routes contained in this Update had been withdrawn.

Spencer (minor): why SHOULD in this case, and not MUST? (Note that 
similar

text occurs throughout this section)


This is to be consistent with draft-ietf-idr-optional-transitive-00.txt:

Instead, when such an attribute is determined to be
  malformed, the UPDATE message containing that attribute SHOULD be
  treated as though all contained routes had been withdrawn just as if
  they had been listed in the WITHDRAWN ROUTES field of the UPDATE
  message, thus causing them to be removed from the Adj-RIB-In
  according to the procedures of [RFC4271].


   An implementation MUST provide debugging facilities to permit issues
   caused by malformed PMSI Tunnel attribute to be diagnosed. At a
   minimum, such facilities SHOULD include logging an error when such an
   attribute is detected.

Spencer (minor): If debugging facilities are a MUST, shouldn't the 
minimum

debugging facility be a MUST? :-) Or are there well-understood reasons
(MUST do X unless) that could be provided? (Note that similar text 
occurs

elsewhere in the draft)


We'll change it to MUST include logging.

Btw, we will apply the same fix to the similar text in Section 8.


   The PMSI Tunnel attribute is used in conjunction with Intra-AS I-PMSI
   A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf
   A-D routes.


7. VRF Route Import Extended Community

   If a PE uses Route Target Constrain [RT-CONSTRAIN], the PE SHOULD
   advertise all such C-multicast Import RTs using Route Target
   Constrains (note that doing this requires just a single Route Target
   Constraint advertisement by the PE). This allows each C-multicast
   route to reach only the relevant PE. To constrain distribution of the
   Route Target Constrain routes to the AS of the advertising PE these
   routes SHOULD carry the NO_EXPORT Community ([RFC1997]).

Spencer (minor): I'm not sure I understand why these are SHOULDs and not
MUSTs. (Note that similar text occurs elsewhere in the draft) I note that
you give reasons why the similar text in Section 8 is not a MUST, using 
this

explanation:


The SHOULD is because use of Route Target Constrain in this case
is an optimization (as indicated in the second sentence in the above
paragraph).


Note that if non-segmented inter-AS P-tunnels are being used, then
   the Intra-AS I-PMSI routes need to be distributed to other ASes and
   MUST NOT carry the NO_EXPORT community.

8. PE Distinguisher Labels Attribute

   The Next Hop field of the MP_REACH_NLRI attribute

Re: [Gen-art] New Version Notification - draft-ietf-pcn-baseline-encoding-07.txt

[Spencer Dawkins]

Hi, Toby,

I've been there ;-)

Like I said, I'm good either way, and thanks for the quick response.

Spencer

- Original Message - 
From: toby.moncas...@bt.com

To: spen...@wonderhamster.org; hous...@vigilsec.com
Cc: draft-ietf-pcn-baseline-encod...@tools.ietf.org; gen-art@ietf.org
Sent: Monday, September 28, 2009 7:40 PM
Subject: RE: New Version Notification - 
draft-ietf-pcn-baseline-encoding-07.txt



Oh bugger! I phrased that rather clumsily didn't I...

I am certain that the outermost in the third paragraph can be removed 
without in any way affecting the meaning. After all, unless you are 
explicitly referring to tunnelled packets then it is taken as read that you 
are talking about the outermost header!


So in summary, I am completely OK to remove this mention of outermost and 
will try and re-boot my brain out of thinking about everything in terms of 
tunnels (which seem to keep cropping up in my work at the moment!). Do you 
need me to explicitly remove this in a new revision or can we get the RFC 
Editor to do so when the document advances?


Toby


Toby Moncaster, Senior Researcher, Network Infrastructure Practise
B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 7918 901170




-Original Message-
From: Spencer Dawkins [mailto:spen...@wonderhamster.org]
Sent: 26 September 2009 04:18
To: Russ Housley
Cc: draft-ietf-pcn-baseline-encod...@tools.ietf.org; General Area
Review Team
Subject: Re: New Version Notification - draft-ietf-pcn-baseline-
encoding-07.txt

Hi, Russ,

Addng The Usual Suspects for our conversation...

 Was your comment about outermost IP resolved?

At least sort of. My biggest concern with 05 was that this qualifier
was
introduced suddenly, at the end of section 4, with no explanation. That
usage has gone away in 07, but there's a NEW usage that was added in
07, in
section 6, which now says

(second paragraph)

   On its own, this baseline encoding cannot support both ECN marking
   end to end and PCN marking within a PCN-domain.  It is possible to
do
   this by carrying e2e ECN across a PCN domain within the inner header
   of an IP in IP tunnel, or by using a richer encoding such as the
   proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding].

(third paragraph)

   In any PCN deployment, traffic can only enter the PCN-Domain through
   PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
   nodes ensure that any packets entering the PCN- domain have the ECN-
- field in their outermost IP header set to the appropriate PCN
   codepoint. PCN-egress-nodes then guarantee that the ECN-field of any
   packet leaving the PCN-domain has the correct ECN semantics. This
   prevents leakage of ECN marks into or out of the PCN-domain and thus
   reduces backward compatibility issues.

If the third paragraph is about tunneled packets, I'd prefer it to say
any
tunnelled packets entering the PCN-domain. If the third paragraph is
about
all packets (whether tunneled or not), I'd prefer s/outermost//.

You guys are the ones who get to say whether this preference matters,
of
course :-)

Since most of this text is new, I should also ask - 05 called out both
IP-in-IP and IPsec tunnels, while 07 calls out only IP-in-IP (plus the
experimental encoding that was added). Was that change intentional? I'm
just
asking about the difference, I don't have a preference ...

Spencer


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

Re: [Gen-art] New Version Notification - draft-ietf-pcn-baseline-encoding-07.txt

[Spencer Dawkins]

Hi, Russ,

Addng The Usual Suspects for our conversation...


Was your comment about outermost IP resolved?


At least sort of. My biggest concern with 05 was that this qualifier was
introduced suddenly, at the end of section 4, with no explanation. That 
usage has gone away in 07, but there's a NEW usage that was added in 07, in 
section 6, which now says


(second paragraph)

  On its own, this baseline encoding cannot support both ECN marking
  end to end and PCN marking within a PCN-domain.  It is possible to do
  this by carrying e2e ECN across a PCN domain within the inner header
  of an IP in IP tunnel, or by using a richer encoding such as the
  proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding].

(third paragraph)

  In any PCN deployment, traffic can only enter the PCN-Domain through
  PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
  nodes ensure that any packets entering the PCN- domain have the ECN-
- field in their outermost IP header set to the appropriate PCN
  codepoint. PCN-egress-nodes then guarantee that the ECN-field of any
  packet leaving the PCN-domain has the correct ECN semantics. This
  prevents leakage of ECN marks into or out of the PCN-domain and thus
  reduces backward compatibility issues.

If the third paragraph is about tunneled packets, I'd prefer it to say any 
tunnelled packets entering the PCN-domain. If the third paragraph is about 
all packets (whether tunneled or not), I'd prefer s/outermost//.


You guys are the ones who get to say whether this preference matters, of 
course :-)


Since most of this text is new, I should also ask - 05 called out both 
IP-in-IP and IPsec tunnels, while 07 calls out only IP-in-IP (plus the 
experimental encoding that was added). Was that change intentional? I'm just 
asking about the difference, I don't have a preference ...


Spencer

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

[Gen-art] Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-06

[Spencer Dawkins]

Version 06 addresses all of my comments on 05, and other changes from 05 
look fine. Ready for publication as a Proposed Standard.


Spencer



Hi, Cyrus,

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-vcarddav-webdav-mkcol-05
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-08-17
Review Date: 2009-08-07
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed 
Standard. I have some minor comments (identified as Spencer (minor) in 
the following text, but nothing that should slow document approval. In 
particular, I'm pretty sure I identified an error in the title for Section 
3.5 below.


Comments identified as Spencer (clarity) are provided for editors, but 
are not part of the Gen-ART review.


Abstract

  This specification extends the Web Distributed Authoring and
  Versioning (WebDAV) MKCOL method to allow collections of arbitrary
  resourcetype to be created and to allow properties to be set at the
  same time.

Spencer (clarity): I know that RFC 4918 didn't provide an expansion for 
MKCOL until about page 46 (or maybe 25, in passing), but since MKCOL 
appears in the abstract for this document, it might be helpful to 
s/MKCOL/MKCOL (Make Collection)/ here. MKCOL is defined at first use in 
the Introduction, so that's fine - this is only a suggestion about the 
abstract.


3.  WebDAV extended MKCOL

  The WebDAV MKCOL request is extended to allow the inclusion of a
  request body.  The request body is an XML document containing a
  single DAV:mkcol XML element as the root element.  The Content-Type

Spencer (minor): if I'm reading this paragraph correctly, I'd suggest The 
request body is an XML document that MUST contain a single DAV:mkcol XML 
element as the root element here - the last sentence in this paragraph 
makes me think the requirement is normative, but it doesn't look normative 
to 2119 scanners :-)


  request header MUST be set appropriately for an XML body (e.g., set
  to text/xml or application/xml).  XML-typed bodies for an MKCOL
  request that do not have DAV:mkcol as the root element are reserved
  for future usage.

  As per the PROPPATCH method ([RFC4918], Section 9.2), servers MUST
  process any DAV:set instructions in document order (an exception to
  the normal rule that ordering is irrelevant).  Instructions MUST
  either all be executed or none executed.  Thus, if any error occurs

Spencer (clarity): this sentence reads roughly to me, and it's 2119 
language, so needs to be clear. I suggest The set of instructions MUST be 
executed atomically; either all are executed or none are executed.


  during processing, all executed instructions MUST be undone and a
  proper error result returned.  Failure to set a property value on the
  collection MUST result in a failure of the overall MKCOL request -
  i.e. the collection is not created.

3.5.  Example: Successful Extended MKCOL Request

Spencer (minor): Perhaps this should be s/Successful/Unsuccessful/? It's 
returning a 403/424 :D


4.  Replacing Existing MKxxx Methods

Spencer (clarity): Hmm. This section (and 4.1, and 4.1.1) aren't quite 
about REPLACING existing MKxxx methods, but more like Providing MKxxx 
functionality using extended MKCOL. Would that be clearer? The current 
text in 4.1 sent me looking to see whether replacement meant 
deprecation (it doesn't, if I'm reading clearly), for example.


  One of the goals of this extension is to eliminate the need for other
  extensions to define their own variant of MKCOL to create the special
  collections they need.  This extension can be used to replace
  existing MKxxx methods in other extensions as detailed below.  If a
  server supports this extension and the other extension listed, then
  the server MUST support use of the extended MKCOL method to achieve
  the same result as the MKxxx method of the other extension.
___
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

Re: [Gen-art] Gen-ART Review of draft-ietf-dime-pmip6-02.txt

[Spencer Dawkins]

Hi, Julian,

If this is a concern, I would be FINE with text that says

Whenever the MAG sends a Diameter request message to the HAAA, the 
User-Name SHOULD contain the MN's identity unless the identity is being 
suppressed for policy reasons - for example, when identity hiding is in 
effect.


Does that help?

Thanks,

Spencer

- Original Message - 
From: julien.bourne...@orange-ftgroup.com

To: spen...@wonderhamster.org; jouni.nos...@gmail.com
Cc: draft-ietf-dime-pm...@tools.ietf.org; gen-art@ietf.org
Sent: Monday, August 17, 2009 7:57 AM
Subject: RE: Gen-ART Review of draft-ietf-dime-pmip6-02.txt


Hello,

thanks for your Gen-ART review... one comment below:


-Message d'origine-
De : Spencer Dawkins [mailto:spen...@wonderhamster.org]
Envoyé : lundi 10 août 2009 00:31
À : jouni korhonen
Cc : draft-ietf-dime-pm...@tools.ietf.org; General Area Review Team
Objet : Re: Gen-ART Review of draft-ietf-dime-pmip6-02.txt

i think we're down to one item...

 5.1.  MAG-to-HAAA Interface

 Whenever the MAG sends a Diameter request message to the
HAAA the
 User-Name AVP SHOULD contain the MN's identity.  The MN
identity,
 if

 Spencer (minor): what is this SHOULD conditional on?

 In case of identity hiding is applied, the User-Name can
be absent.

 Ah - if my understanding is correct, the text might be clearer as
 Whenever the MAG sends a Diameter request message to the HAAA and
 identity hiding is not in effect, the User-Name MUST contain the
 MN's identity.

 I am still a bit hesitant with the MUST here. Anyway, if
other authors
 don't disagree I am ok with the proposed change.

I would be OK with a SHOULD - you've provided at least one
reason why it's not an unconditional MUST - but please check
with other authors and doc shepherd.



I'm ok with the proposed text. I just hope there's no other case where the 
User-Name may not be available.


Regards,

Julien



thanks for the quick responses!

spencer

 available, MUST be in Network Access Identifier (NAI) [RFC4282]
 format.  At minimum the home realm of the MN MUST be
available at
 the MAG when the network access authentication takes place.
 Otherwise the MAG is not able to route the Diameter request
 messages towards the correct HAAA.  The MN identity used on the
 MAG-to-HAAA interface and in the User-Name AVP MAY entirely be
 related to the network access authentication, and therefore not
 suitable to be used as the MN-ID mobility option value in the
 subsequent PBU/PBA messages.  See the related discussion on MN's
 identities in Section 4.6 and in Section 5.2.1




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

[Gen-art] Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-05

[Spencer Dawkins]

Hi, Cyrus,

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-vcarddav-webdav-mkcol-05
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-08-17
Review Date: 2009-08-07
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed 
Standard. I have some minor comments (identified as Spencer (minor) in the 
following text, but nothing that should slow document approval. In 
particular, I'm pretty sure I identified an error in the title for Section 
3.5 below.


Comments identified as Spencer (clarity) are provided for editors, but are 
not part of the Gen-ART review.


Abstract

  This specification extends the Web Distributed Authoring and
  Versioning (WebDAV) MKCOL method to allow collections of arbitrary
  resourcetype to be created and to allow properties to be set at the
  same time.

Spencer (clarity): I know that RFC 4918 didn't provide an expansion for 
MKCOL until about page 46 (or maybe 25, in passing), but since MKCOL appears 
in the abstract for this document, it might be helpful to s/MKCOL/MKCOL 
(Make Collection)/ here. MKCOL is defined at first use in the 
Introduction, so that's fine - this is only a suggestion about the abstract.


3.  WebDAV extended MKCOL

  The WebDAV MKCOL request is extended to allow the inclusion of a
  request body.  The request body is an XML document containing a
  single DAV:mkcol XML element as the root element.  The Content-Type

Spencer (minor): if I'm reading this paragraph correctly, I'd suggest The 
request body is an XML document that MUST contain a single DAV:mkcol XML 
element as the root element here - the last sentence in this paragraph 
makes me think the requirement is normative, but it doesn't look normative 
to 2119 scanners :-)


  request header MUST be set appropriately for an XML body (e.g., set
  to text/xml or application/xml).  XML-typed bodies for an MKCOL
  request that do not have DAV:mkcol as the root element are reserved
  for future usage.

  As per the PROPPATCH method ([RFC4918], Section 9.2), servers MUST
  process any DAV:set instructions in document order (an exception to
  the normal rule that ordering is irrelevant).  Instructions MUST
  either all be executed or none executed.  Thus, if any error occurs

Spencer (clarity): this sentence reads roughly to me, and it's 2119 
language, so needs to be clear. I suggest The set of instructions MUST be 
executed atomically; either all are executed or none are executed.


  during processing, all executed instructions MUST be undone and a
  proper error result returned.  Failure to set a property value on the
  collection MUST result in a failure of the overall MKCOL request -
  i.e. the collection is not created.

3.5.  Example: Successful Extended MKCOL Request

Spencer (minor): Perhaps this should be s/Successful/Unsuccessful/? It's 
returning a 403/424 :D


4.  Replacing Existing MKxxx Methods

Spencer (clarity): Hmm. This section (and 4.1, and 4.1.1) aren't quite about 
REPLACING existing MKxxx methods, but more like Providing MKxxx 
functionality using extended MKCOL. Would that be clearer? The current text 
in 4.1 sent me looking to see whether replacement meant deprecation (it 
doesn't, if I'm reading clearly), for example.


  One of the goals of this extension is to eliminate the need for other
  extensions to define their own variant of MKCOL to create the special
  collections they need.  This extension can be used to replace
  existing MKxxx methods in other extensions as detailed below.  If a
  server supports this extension and the other extension listed, then
  the server MUST support use of the extended MKCOL method to achieve
  the same result as the MKxxx method of the other extension. 


___
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-rmt-bb-lct-revised-10

[Spencer Dawkins]

This revised draft addresses all of my comments from v09, and has a much 
stronger Security Considerations section than v09. Ready for publication as 
Proposed Standard.


Thanks,

Spencer



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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-rmt-bb-lct-revised-09
Reviewer: Spencer Dawkins
Review Date: 2009-04-27
IETF LC End Date: 2009-04-15 (sorry! along with any other LATE Last Call 
comments...)

IESG Telechat date: (not known)

Summary: This specification is almost ready for publication as a Proposed 
Standard. I have a couple of minor questions (below). I've also included a 
small number of nits, but this draft is very clean on that score.


Comments:

Abstract

  Layered Coding Transport (LCT) provides transport level support for
  reliable content delivery and stream delivery protocols.  LCT is
  specifically designed to support protocols using IP multicast, but
  also provides support to protocols that use unicast.  LCT is
  compatible with congestion control that provides multiple rate
  delivery to receivers and is also compatible with coding techniques
  that provide reliable delivery of content.  This document obsoletes
  RFC3451

Spencer (nit): it would be great if the abstract used the word building 
block... OBTW, there's a missing period after RFC3451.


1.  Introduction

  Layered Coding Transport provides transport level support for

Spencer (nit): it would be good to provide Layered Coding Transport 
(LCT) somewhere around here - the next section of the document just 
starts using the abbreviation with no expansion...


  reliable content delivery and stream delivery protocols.  Layered
  Coding Transport is specifically designed to support protocols using
  IP multicast, but also provides support to protocols that use
  unicast.  Layered Coding Transport is compatible with congestion
  control that provides multiple rate delivery to receivers and is also
  compatible with coding techniques that provide reliable delivery of
  content.

  RFC3451 [RFC3451], which is obsoleted by this document, contained a
  previous versions of the protocol.  RFC3451 was published in the

Spencer (nit): s/versions/version/? but this section of the document 
wobbles back and forth between singular (this document) and plural 
(these specifications) - maybe clear to someone who's followed the 
working group for a while, but less clear to me...


  Experimental category.  It was the stated intent of the RMT working
  group to re-submit these specifications as an IETF Proposed Standard
  in due course.

4.  Applicability

  Before joining a session, the receivers MUST obtain enough of the
  session description to start the session.  This MUST include the

Spencer (minor): I don't think this two are 2119 MUSTs ... based on the 
previous sentence, I'd just s/MUST// the first one completely, but they 
should be at least lower-cased...


  relevant session parameters needed by a receiver to participate in
  the session, including all information relevant to congestion
  control.  The session description is determined by the sender, and is
  typically communicated to the receivers out-of-band.  In some cases,
  as described later, parts of the session description that are not
  required to initiate a session MAY be included in the LCT header or
  communicated to a receiver out-of-band after the receiver has joined
  the session.

4.1.  Environmental Requirements and Considerations

  LCT channels and SSM channels coincide, and thus the receiver will
  only receive packets sent to the requested LCT channel.  With ASM,
  the receiver joins an LCT channel by joining a multicast group G, and
  all packets sent to G, regardless of the sender, may be received by
  the receiver.  Thus, SSM has compelling security advantages over ASM
  for prevention of denial of service attacks.  In either case,
  receivers SHOULD use mechanisms to filter out packets from unwanted
  sources.

Spencer (minor): I'm confused by this. I would have thought that ASM 
wasn't so easily filtered in many cases (SSM, sure) - based on the source 
address, which could be coming from anywhere? Is this a membership check?


8.3.  Congestion control issues

  A receiver with an incorrect implementation of a multiple rate
  congestion control building block may affect health of the network in
  the path between the sender and the receiver, and may also affect the
  reception rates of other receivers joined to the session.

  Protocol Instantiations could address this issue by requiring
  receivers to identify themselves as legitimate before they receive
  the Session Description needed to join the session.

Spencer (minor): I'm sorry, but I don't understand what's being suggested 
here. Could you provide any guidance

Re: [Gen-art] Gen-ART Review of draft-ietf-dime-pmip6-02.txt

[Spencer Dawkins]

Hi, Jouni,

Thanks for the quick response. If I wasn't still jet-lagged, I could 
remember what I was thinking when I did the review :-)


Responses inline... and I deleted stuff we already agreed on.

Spencer


1.  Introduction

 This specification defines the Diameter support for PMIPv6.  In the
 context of this specification the location of the subscriber policy
 profile equals to the home Diameter server, which is also referred as

Spencer (clarity): this sentence is difficult to parse - is it  saying 
In this specification, the home Diameter server, which is  also referred 
to as the home AAA server (HAAA), contains the  subscriber policy 
profile? If it doesn't, I'm too confused to make  a suggestion...


How about:

In the context of this specification the home AAA server (HAAA)
functionality is co-located with the subscriber policy profile.



Much clearer - thanks!



 the home AAA server (HAAA).  The NAS functionality of the MAG may be
 co-located or an integral part of the MAG.

4.5.  MIP6-Feature-Vector AVP

 LOCAL_MAG_ROUTING_SUPPORTED (0x0400)

Direct routing of IP packets between MNs anchored to the same MAG
is supported.  When a MAG sets this bit in the MIP6-Feature-
Vector, it indicates that routing IP packets between MNs anchored
to the same MAG is supported, without reverse tunneling packets
via the LMA or requiring any Route Optimization related signaling
(e.g. the Return Routability Procedure in [RFC3775]) prior direct
routing.  If this bit is unset in the returned MIP6-Feature-Vector

Spencer (clarity): I'd say if this bit is cleared.


OK.


AVP, the HAAA does not authorize direct routing of packets between
MNs anchored to the same MAG.  This policy feature SHOULD be
supported per MN and subscription basis.

Spencer (minor): it's not clear who SHOULD be supporting this  feature - 
who does the 2119 SHOULD apply to? I would guess it  applies to the MAG, 
but I'm guessing. Is this supported on a per-MN  and per-subscription 
basis? And I'm not sure why this SHOULD isn't  a MUST.


supported on a per-MN and per-subscription basis is what the text  tries 
to say.


If people think it's clear enough, that's fine. I was just getting lost.

It is SHOULD as the RFC5213 does not mandate whether the local routing  is 
per-MN (uses MAY in RFC5213) or applies to whole MAG. Therefore, we  felt 
SHOULD is enough and final decision is then left for the 
deployment/system.


That's fine.

Sorry for asking three questions back-to-back.

The question that may have gotten lost is who is required to support 
this? - the MAG, or the HAAA, or both? This statement occurs in text that 
describes the message flow. I'm understanding your response as saying that 
the requirement applies to the MAG, but one reasonable interpretation is 
that it applies to both the MAG and HAAA (since they exchange messages with 
this AVP).


Suggest The MAG SHOULD support this policy feature on a per MN and 
subscription basis.




5.1.  MAG-to-HAAA Interface

 Whenever the MAG sends a Diameter request message to the HAAA the
 User-Name AVP SHOULD contain the MN's identity.  The MN identity, if

Spencer (minor): what is this SHOULD conditional on?


In case of identity hiding is applied, the User-Name can be absent.


Ah - if my understanding is correct, the text might be clearer as Whenever 
the MAG sends a Diameter request message to the HAAA and identity hiding is 
not in effect, the User-Name MUST contain the MN's identity.




 available, MUST be in Network Access Identifier (NAI) [RFC4282]
 format.  At minimum the home realm of the MN MUST be available at the
 MAG when the network access authentication takes place.  Otherwise
 the MAG is not able to route the Diameter request messages towards
 the correct HAAA.  The MN identity used on the MAG-to-HAAA interface
 and in the User-Name AVP MAY entirely be related to the network
 access authentication, and therefore not suitable to be used as the
 MN-ID mobility option value in the subsequent PBU/PBA messages.  See
 the related discussion on MN's identities in Section 4.6 and in
 Section 5.2.1


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

[Gen-art] Gen-ART review of draft-seokung-msec-mikey-seed-03

[Spencer Dawkins]

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-seokung-msec-mikey-seed-03
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-08-07
Review Date: 2009-08-03
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as an Informational 
RFC. I have some questions (marked as Spencer (minor):) that would be nits 
if they weren't in the Security Considerations section.


Addition of the new values to use the SEED Cipher Algorithm in the
   Multimedia Internet KEYing (MIKEY)

Spencer (clarity): I would suggest a possible title change to something like 
IANA Registry Update for SEED Cipher Algorithm Support in Multimedia 
Internet KEYing (MIKEY) - it wasn't clear that this was an IANA request 
until I was about halfway through the draft. Please check this with your 
document shepherd, before submitting an update with a new title!


Abstract

  This document proposes the addition of new values to use the SEED
  block cipher algorithm for the Secure Real-time Transport Protocol
  (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in
  Multimedia Internet KEYing (MIKEY).

Spencer (clarity): I would suggest something like s/This document proposes 
the addition of new values to use/This document updates IANA registries to 
support/, both here and in the Introduction (same paragraph, with references 
added, so same comment).


1. Introduction

  This document proposes the addition of new values to use the SEED
  [RFC4269] block cipher algorithm for the Secure Real-time Transport
  Protocol (SRTP) and the Secure Real-time Transport Control Protocol
  (SRTCP) [RFC3711] in Multimedia Internet KEYing (MIKEY) [RFC3830].

1.1. SEED

  SEED is a Korean National Industrial Association standard and is
  widely used in South Korea for electronic commerce and various
  security products such as firewall, VPN, and so on.

Spencer (clarity): I think the following paragraph should be the first 
paragraph in this section (the previous paragraph is fine, but the following 
paragraph is the most helpful to the reader).


  SEED is a 128-bit symmetric key block cipher that has been developed
  by KISA (Korea Information Security Agency) and a group of experts
  since 1998. The input/output block size of SEED is 128-bit and the
  key length is also 128-bit. SEED has a 16-round Feistel structure.


2.1. Modified Table 6.10.1.b from [RFC3830]

  For the Encryption algorithm, a one byte length is enough. The

Spencer (clarity): I'm not sure what you mean by a one byte length is 
enough - is this saying that space is available in the registry table? Or 
something else? I have the same comment about the same text in section 2.2.


  currently defined possible values are:

  SRTP encr alg | Value
  - 
  NULL  | 0

  AES-CM| 1
  AES-F8| 2
  SEED-CTR  | 3 (NEW)
  SEED-CCM  | 4 (NEW)
  SEED-GCM  | 5 (NEW)

  Figure 1: Table 6.10.1.b from [RFC3830] (Revised)


2.2. Modified Table 6.10.1.d from [RFC3830]

  For the SRTP pseudo-random function, a one byte length is also
  enough. The currently defined possible values are:

  SRTP PRF  | Value
  - 
  AES-CM| 0

  SEED-CTR  | 1 (NEW)

  Figure 2: Table 6.10.1.d from [RFC3830] (Revised)

3. Security Considerations

  No security problem has been found on SEED. SEED is secure against
  all known attacks including Differential cryptanalysis, linear

Spencer (minor): I would suggest dropping the first sentence.

  cryptanalysis, and related key attacks. The best known attack is only

Spencer (minor): should this be The only known attack is an exhaustive 
search for the key?


  an exhaustive search for the key. For further security
  considerations, the reader is encouraged to read [SEED-EVAL]. 


___
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-pmip6-02.txt

[Spencer Dawkins]

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-dime-pmip6-02.txt
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-08-05
Review Date: 2009-08-03
IESG Telechat date: (not known)

Summary: This specification is almost ready for publication as a Proposed 
Standard. I have some minor comments, mostly involving 2119 language.


1.  Introduction

  This specification defines the Diameter support for PMIPv6.  In the
  context of this specification the location of the subscriber policy
  profile equals to the home Diameter server, which is also referred as

Spencer (clarity): this sentence is difficult to parse - is it saying In 
this specification, the home Diameter server, which is also referred to as 
the home AAA server (HAAA), contains the subscriber policy profile? If it 
doesn't, I'm too confused to make a suggestion...


  the home AAA server (HAAA).  The NAS functionality of the MAG may be
  co-located or an integral part of the MAG.

4.5.  MIP6-Feature-Vector AVP

  LOCAL_MAG_ROUTING_SUPPORTED (0x0400)

 Direct routing of IP packets between MNs anchored to the same MAG
 is supported.  When a MAG sets this bit in the MIP6-Feature-
 Vector, it indicates that routing IP packets between MNs anchored
 to the same MAG is supported, without reverse tunneling packets
 via the LMA or requiring any Route Optimization related signaling
 (e.g. the Return Routability Procedure in [RFC3775]) prior direct
 routing.  If this bit is unset in the returned MIP6-Feature-Vector

Spencer (clarity): I'd say if this bit is cleared.

 AVP, the HAAA does not authorize direct routing of packets between
 MNs anchored to the same MAG.  This policy feature SHOULD be
 supported per MN and subscription basis.

Spencer (minor): it's not clear who SHOULD be supporting this feature - who 
does the 2119 SHOULD apply to? I would guess it applies to the MAG, but I'm 
guessing. Is this supported on a per-MN and per-subscription basis? And 
I'm not sure why this SHOULD isn't a MUST.


4.8.  Service-Selection AVP

  It is also possible that the MAG receives the service selection
  information from the MN, for example, via some lower layer mechanism.
  In this case the MAG SHOULD include the Service-Selection AVP also in

Spencer (minor): why is this a SHOULD, and not a MUST?

  the MAG-to-HAAA request messages.  In absence of the Service-
  Selection AVP in the MAG-to-HAAA request messages, the HAAA may want
  to inform the MAG of the default service provisioned to the MN and
  include the Service-Selection AVP in the response message.

5.1.  MAG-to-HAAA Interface

  Whenever the MAG sends a Diameter request message to the HAAA the
  User-Name AVP SHOULD contain the MN's identity.  The MN identity, if

Spencer (minor): what is this SHOULD conditional on?

  available, MUST be in Network Access Identifier (NAI) [RFC4282]
  format.  At minimum the home realm of the MN MUST be available at the
  MAG when the network access authentication takes place.  Otherwise
  the MAG is not able to route the Diameter request messages towards
  the correct HAAA.  The MN identity used on the MAG-to-HAAA interface
  and in the User-Name AVP MAY entirely be related to the network
  access authentication, and therefore not suitable to be used as the
  MN-ID mobility option value in the subsequent PBU/PBA messages.  See
  the related discussion on MN's identities in Section 4.6 and in
  Section 5.2.1

Spencer (nit): missing period here.

5.2.1.  Authorization of the Proxy Binding Update

  Whenever the LMA sends a Diameter request message to the HAAA, the
  User-Name AVP SHOULD contain the MN's identity.  The LMA MAY retrieve

Spencer (minor): what is this SHOULD conditional on?

  the MN's identity information from the PBU MN-ID [RFC4283][RFC5213]
  mobility option.  The identity SHOULD be the same as used on the MAG-
  to-HAAA interface, but in the case those identities differ the HAAA
  MUST have a mechanism of mapping the MN identity used on the MAG-to-
  HAAA interface to the identity used on the LMA-to-HAAA interface.

6.1.  Session-Termination-Request

  The LMA or the MAG MAY send the Session-Termination-Request (STR)
  command [RFC3588] to the HAAA and inform the termination of an

Spencer (clarity): I got lost in this sentence. Suggest to inform the HAAA 
that the termination of


  ongoing PMIPv6 session is in progress. 


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

[Gen-art] Gen-ART Review of draft-ietf-speermint-voip-consolidated-usecases-13

[Spencer Dawkins]

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-speermint-voip-consolidated-usecases-13
(Note: The IETF Last Call was issued for version 12 - since version 13 was
available, I reviewed it instead)

Reviewer: Spencer Dawkins
IETF LC End Date: 2009-07-08
Review Date: 2009-07-23 (late!)
IESG Telechat date: (not known)

Summary: This draft is almost ready for publication as an Informational RFC.
I identified some minor questions (listed below). The ones I'd really like
for Russ to think about are in Section 7 (Security Considerations).

I also made suggestions to improve clarity, but these should not slow the
document approval process down, unless Russ thinks some o of them are
important.

1.  Introduction

  Only use cases related to VoIP are considered in this document.
  Other real-time SIP communications use cases, like Instant Messaging
  (IM) and presence are out of scope for this document.  In describing
  use cases, the intent is descriptive, not prescriptive.

Spencer (clarity): I would suggest These use cases are descriptive, not
prescriptive for the last sentence in this paragraph.

  The use cases contained in this document attempts to be as
  comprehensive as possible, but should not be considered the exclusive
  set of use cases.

3.  Reference Architecture

  Originating SSP (O-SSP) is the SSP originating a request.

Spencer (clarity): at this point in the document, it's not clear whether a
request is a SIP request or a request to discover a peer, determine a next
hop, etc. Could you add an adjective (probably either SIP request or
something like peering request)?

  Terminating SSP (T-SSP) is the SSP terminating the request
  originating from O-SSP.  Assisting LUF and LRF Provider offers LUF
  and LRF services to O-SSP.  Indirect SSP (I-SSP) is the SSP providing
  indirect peering service(s) to O-SSP to connect to T-SSP.

  Note that in Figure 1 - some elements defined are optional in many
  use cases.

Spencer (clarity): I would suggest some elements included in Figure 1 are
optional.

4.  Contexts of Use Cases

  o  Next Hop Routing Determination - Resolving the SED information is
 necessary to route the request to the T-SSP.  The LRF is used for
 this determination.  The O-SSP may also use the standard procedure

Spencer (minor): is this The O-SSP may also use or Alternatively, the
O-SSP may use? The text says in addition to, but I'm thinking you mean
instead of.

 defined in [RFC3263] to discover the next hop address.

  o  Call setup - SSPs that are interconnecting to one another may also
 define specifics on what SIP features need to be used when

Spencer (minor): are these SIP features? I'm thinking something more like
what unique interconnection parameters of this SIP peering arrangement must
to be used, but you guys would be better at rephrasing, if you agree with
the comment. For example, I'm not thinking port numbers are SIP
features...

 contacting the next hop in order to a) reach the next hop at all
 and b) to prove that the sender is a legitimate peering partner.

 Examples: hard-code transport (TCP/UDP/TLS), non-standard port
 number, specific source IP address (e.g. in a private Layer-3
 network), which TLS client certificate [RFC4366] to use, and other
 authentication schemes.

  o  Call reception - This step serves to ensure that the type of
 relationship (static or on-demand, indirect or direct) is
 understood and acceptable.  For example, the receiving SBE needs
 to determine whether the INVITE it received really came from a
 trusted member possibly via an access control list entry.

Spencer (clarity): I think the sentence would be clearer if it ended came
from a trusted member.

5.  Use Cases

  Please note there are intra-domain message flows within the use cases
  to serve as supporting background information.  Only inter-domain
  communications are germane to Speermint.

Spencer (minor): I understand what you're saying, but as an RFC, this
document will outlive the SPEERMINT working group. Perhaps germane to this
document?

5.2.  Static Direct Peering Use Case

  This is the simplest form of a peering use case.  Two SSPs negotiate
  and agree to establish a SIP peering relationship.  The peer
  connection is statically configured and is direct between the
  connected SSPs.  The peers may exchange interconnection parameters

Spencer (clarity): I would suggest and the peer SSPs are directly
connected.

  such as DSCP [RFC2474] policies, the maximum number of requests per
  second and proxy location prior to establishing the interconnection.
  Typically, the T-SSP only accepts traffic originating directly from
  the trusted peer.

   Note that UAC inserted

Re: [Gen-art] Gen-ART Review of draft-hollenbeck-rfc4930bis-02

[Spencer Dawkins]

This revision of the draft is even more ready for publication as a Full 
Standard ;-)


Spencer


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 resolve these comments along with any other Last Call comments you 
may receive.

Document: draft-hollenbeck-rfc4930bis-01
Reviewer: Spencer Dawkins
Review Date: 2009-05-18
IETF LC End Date: 2009-06-11
IESG Telechat date: 2009-07-16
Summary: This document is ready for publication as a Full Standard 



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

[Gen-art] Gen-ART review of draft-ietf-nea-pb-tnc-04.txt

[Spencer Dawkins]

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-nea-pb-tnc-04.txt
Reviewer: Spencer Dawkins
Review Date: 10 July 2009
IESG Telechat date: 16 July 2009

Summary: This document is almost ready for publication as a Proposed 
Standard. I have three minor issues that I wanted to put forward before next 
week's telechat. All are about 2119-language in the document.


And I apologize profusely for not sending my review before the end of IETF 
Last Call for this document.


4.1. PB-TNC Header

Spencer (minor): the style of error handling in this section bothers me - 
there are several occurances where one party MUST NOT send a batch type, but 
if it DOES send that batch type, the other party SHOULD ignore it and send 
an error message if received. Is there a reason why this is not also a MUST? 
(sample follows, but there are multiple occurances in this section). If it's 
really a SHOULD, what do you expect the second party to do instead? And is 
there any guidance you can give about why the handling described might not 
be appropriate?


  B-Type (Batch Type) (4 bits)

 This field is used to drive the state machine described in section
 3.2. This field MUST have one of the values from the following
 table.  If any other value is received, the recipient MUST send a
 Malformed Message error code in response.  In addition, if the
 value received is not permitted for the current state, according
 to the state machine in section 3.2. , the recipient MUST send an
 Unexpected Batch Type error code in response.

 Number   Name Definition
 --    --

 1CDATAThe Posture Broker Client may send a batch with
   this Batch Type to convey messages to the
   Posture Broker Server.  A Posture Broker Server
   MUST NOT send this Batch Type.  If a Posture
   Broker Client receives a batch with this Batch
   Type, it SHOULD ignore the batch and send a
   fatal Unexpected Batch Type error code in
   response.  A CDATA batch may be empty (contain
   no messages) if the Posture Broker Client has
   nothing to send.
...

  Batch Length (32 bits)

 This length field contains the size of the full PB-TNC batch in
 octets.  This length includes the PB-TNC header and all the PB-TNC
 messages in the batch.  In other words, it includes the entire
 contents of the batch. This field MUST contain at least the value
 8 for the fixed-length fields in this header. Any Posture Broker
 Client or Posture Broker Server that receives a PB-TNC message
 with a PB-TNC Message Length field whose value is less than 8
 SHOULD send an Invalid Parameter error code in response.

Spencer (minor): is there any guidance you can give about why this reaction 
might not be appropriate? I note that similar phrasing for PB-TNC Message 
Length (32 bits) is MUST send an error in response... and I'm seeing 
similar SHOULDs in for other invalid length fields, so I'm actually asking a 
question about a number of SHOULDs in this specification.


...

 When a Posture Broker Client sets the EXCL flag for a PA message,
 the Posture Broker Client MUST set the Posture Validator
 Identifier field to the identifier of the Posture Validator that
 should receive the PA message.  If the EXCL flag is not set, a
 Posture Broker Client MAY still set the Posture Validator
 Identifier value for PA messages that it sends to indicate that
 the PA message is intended as a response to a message sent by the
 Posture Validator associated with the specified Posture Validator
 Identifier.  If the Posture Broker Server does not wish to
 indicate any Posture Validator in this manner, it SHOULD set this
 field to the reserved value 0x.

Spencer (minor): I don't think this is a 2119 SHOULD (about 
interoperability) - if you don't set the field to the reserved value, you've 
indicated a Posture Validator, which is what you didn't want to do, or am I 
confused? I'm thinking should be lowercased (the text is just saying how you 
do what you are trying to do).















Sahita et al.  Expires October 17, 2009   [Page 78]


___
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-dynamic-hostname-04

[Spencer Dawkins]

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-ospf-dynamic-hostname-04
Reviewer: Spencer Dawkins
Review Date: 30 June 2009
IESG Telechat date: 02 July 2009

Summary: This version of the draft addresses all of the issues I identified 
with version 03. This document is ready for publication as a Proposed 
Standard.


There is some new text in Section 3.1 that I wanted to ask about:

  The value field identifies the symbolic hostname of the router
  originating the LSA.  This symbolic name can be the FQDN for the
  router, it can be a subset of the FQDN, or it can be any string
  operators want to use for the router.  The use of FQDN or a subset of
  it is strongly recommended.

This being a Proposed Standard (when approved) that uses 2119 language... 
did you mean strongly RECOMMENDED, or just a really good idea?


But you guys can do the right thing without telling me what that is ...

Thanks,

Spencer



Hi, Carlos,

Both of your proposed issue resolutions work for me (and I agree about 
putting the duplicated hostname note in the Security Considerations 
section, and not in Section 3).


Thanks,

Spencer

- Original Message - 
From: Carlos Pignataro cpign...@cisco.com

To: Spencer Dawkins spen...@wonderhamster.org
Cc: Sanjay Harwani (sharwani) sharw...@cisco.com; Subbaiah Venkata 
svenk...@google.com; Danny McPherson da...@tcb.net; i...@ietf.org; 
General Area Review Team gen-art@ietf.org; Ross Callon 
rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) 
a...@cisco.com

Sent: Friday, June 12, 2009 10:29 AM
Subject: Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03



Hi Spencer,

Thank you for your review, please see inline.

On 6/12/2009 6:24 AM, Spencer Dawkins wrote:

Hi, Sanjay,

please see inline starting with SD:

And thanks for a quick response (before I leave for vacation today).

Spencer

- Original Message - 
From: Sanjay Harwani (sharwani) sharw...@cisco.com

To: Spencer Dawkins spen...@wonderhamster.org; Subbaiah Venkata
svenk...@google.com; Danny McPherson da...@tcb.net; Carlos 
Pignataro

(cpignata) cpign...@cisco.com
Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; 
Ross
Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay 
Roy

(akr) a...@cisco.com
Sent: Thursday, June 11, 2009 11:38 PM
Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03


Adding in Carlos who holds the pen for us, Please see inline starting
with SH:

-Original Message-
From: Spencer Dawkins [mailto:spen...@wonderhamster.org]
Sent: Friday, June 12, 2009 3:55 AM
To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
Cc: i...@ietf.org; General Area Review Team; Ross Callon; Acee Lindem;
Abhay Roy (akr)
Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ospf-dynamic-hostname-03
Reviewer: Spencer Dawkins
Review Date: 2009-06-11
IETF LC End Date: 2009-06-16
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed
Standard. I identified two minor issues listed below.

2.  Possible solutions

   Another approach is having a centralized location where the name-to-
   Router ID mapping can be kept.  DNS can be used for the same.  A
   disadvantage with this centralized solution is that its a single

Spencer (nit): s/its/it's/


Ack -- fixed in the working copy.



   point of failure; and although enhanced availability of the central
   mapping service can be designed, it may not be able to resolve the
   hostname in the event of reachability or network problems.  Also, the
   response time can be an issue with the centralized solution, which
   can be particularly problematic in times of problem resolution.  If

Spencer (minor): good point on response times, but I'd also think you'd
point out that looking up attributes on a centralized mapping table is
exactly the wrong thing to do when you're resolving problems with
routing - the centralized resource may not even be reachable.

SH: I think we already have it covered just above in the same paragraph.
(single point of failure)
snip
 A disadvantage with this centralized solution is that its a
single
   point of failure; and although enhanced availability of the central
   mapping service can be designed, it may not be able to resolve the
   hostname in the event of reachability or network problems.
/snip

SD: I'll call for my eye exam appointment when they open

[Gen-art] Gen-ART review of draft-livingood-woundy-p4p-experiences-10

[Spencer Dawkins]

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-livingood-woundy-p4p-experiences-10
Reviewer: Spencer Dawkins
Review Date: 30 June 2009
IESG Telechat date: 02 July 2009

Summary: This draft addresses all issues that I identified in my review of 
version 07. Ready for publication as Informational (and we need more 
Informational drafts like this one).


There is one problem that I inadvertently contributed to in my review:

I mentioned that we usually put a please delete this section note to the 
RFC Editor for null IANA considerations, and that's present in v10, but 
there's also a please delete this section note for the SECURITY 
Considerations section (which is also null, but for the right reasons). 
Since the Security Considerations section is required for all RFCs, Lisa 
should probably add a note asking the RFC Editor to ignore the note in the 
draft ;-)


Thanks (and sorry!),

Spencer

7.  Security Considerations

  There are no security considerations in this document.

  NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO
  PUBLICATION.


8.  IANA Considerations

  There are no IANA considerations in this document.

  NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO
  PUBLICATION.


___
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-ospf-dynamic-hostname-03

[Spencer Dawkins]

Hi, Sanjay,

please see inline starting with SD:

And thanks for a quick response (before I leave for vacation today).

Spencer

- Original Message - 
From: Sanjay Harwani (sharwani) sharw...@cisco.com
To: Spencer Dawkins spen...@wonderhamster.org; Subbaiah Venkata 
svenk...@google.com; Danny McPherson da...@tcb.net; Carlos Pignataro 
(cpignata) cpign...@cisco.com
Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross 
Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy 
(akr) a...@cisco.com

Sent: Thursday, June 11, 2009 11:38 PM
Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03


Adding in Carlos who holds the pen for us, Please see inline starting
with SH:

-Original Message-
From: Spencer Dawkins [mailto:spen...@wonderhamster.org]
Sent: Friday, June 12, 2009 3:55 AM
To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
Cc: i...@ietf.org; General Area Review Team; Ross Callon; Acee Lindem;
Abhay Roy (akr)
Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ospf-dynamic-hostname-03
Reviewer: Spencer Dawkins
Review Date: 2009-06-11
IETF LC End Date: 2009-06-16
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed
Standard. I identified two minor issues listed below.

2.  Possible solutions

  Another approach is having a centralized location where the name-to-
  Router ID mapping can be kept.  DNS can be used for the same.  A
  disadvantage with this centralized solution is that its a single

Spencer (nit): s/its/it's/

  point of failure; and although enhanced availability of the central
  mapping service can be designed, it may not be able to resolve the
  hostname in the event of reachability or network problems.  Also, the
  response time can be an issue with the centralized solution, which
  can be particularly problematic in times of problem resolution.  If

Spencer (minor): good point on response times, but I'd also think you'd
point out that looking up attributes on a centralized mapping table is
exactly the wrong thing to do when you're resolving problems with
routing - the centralized resource may not even be reachable.

SH: I think we already have it covered just above in the same paragraph.
(single point of failure)
   snip
A disadvantage with this centralized solution is that its a
single
  point of failure; and although enhanced availability of the central
  mapping service can be designed, it may not be able to resolve the
  hostname in the event of reachability or network problems.
   /snip

SD: I'll call for my eye exam appointment when they open :-). What I liked 
about the response time text was that it clearly called out the impact on 
problem resolution - if it was possible for this to be clearly stated for 
reachability, that seems helpful to me. If I was suggesting text, it might 
be something like:


SD: A disadvantage with this centralized solution is that it's a single 
point of failure; and although enhanced availability of the central mapping 
service can be designed, it may not be able to resolve the hostname in the 
event of reachability or network problems, which can be particularly 
problematic in times of problem resolution. Also, the response time can be 
an issue with the centralized solution, which can be equally problematic.


3.  Implementation

  The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL.  Upon receipt
  of the TLV a router may decide to ignore this TLV, or to install the
  symbolic name and Router ID in its hostname mapping table.

Spencer (minor): I'm suspecting that if this attribute becomes widely
deployed, network operators would train themselves to read the hostname
and pay very little attention to the numeric router ID, so I'm wondering
if it's worth saying anything (either here or in an Operations and
Management Considerations section ducks :-) about the possibility that
two different routers may both insist they are routerXYZ.

That would be a misconfiguration, and the text as written allows the
router to ignore the second attempt to claim the name routerXYZ, but
it would be irritating to troubleshoot a problem looking at logs that
conflate two disjoint routerXYZ routers. I'm not a router guy, so I
don't know what other responses might be appropriate - I don't think
you'd declare an error for a perfectly good next-hop who's confused
about its hostname, and I don't know if suggesting that this be SNMP
TRAPped would make sense - but you guys would be the right ones to
suggest an appropriate response.

SH: This is a mis-configuration issue. Network Administrators need to be
careful while configuring hostnames

Re: [Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

[Spencer Dawkins]

Hi, Carlos,

Both of your proposed issue resolutions work for me (and I agree about 
putting the duplicated hostname note in the Security Considerations section, 
and not in Section 3).


Thanks,

Spencer

- Original Message - 
From: Carlos Pignataro cpign...@cisco.com

To: Spencer Dawkins spen...@wonderhamster.org
Cc: Sanjay Harwani (sharwani) sharw...@cisco.com; Subbaiah Venkata 
svenk...@google.com; Danny McPherson da...@tcb.net; i...@ietf.org; 
General Area Review Team gen-art@ietf.org; Ross Callon 
rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay Roy (akr) 
a...@cisco.com

Sent: Friday, June 12, 2009 10:29 AM
Subject: Re: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03



Hi Spencer,

Thank you for your review, please see inline.

On 6/12/2009 6:24 AM, Spencer Dawkins wrote:

Hi, Sanjay,

please see inline starting with SD:

And thanks for a quick response (before I leave for vacation today).

Spencer

- Original Message - 
From: Sanjay Harwani (sharwani) sharw...@cisco.com

To: Spencer Dawkins spen...@wonderhamster.org; Subbaiah Venkata
svenk...@google.com; Danny McPherson da...@tcb.net; Carlos 
Pignataro

(cpignata) cpign...@cisco.com
Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; Ross
Callon rcal...@juniper.net; Acee Lindem a...@redback.com; Abhay 
Roy

(akr) a...@cisco.com
Sent: Thursday, June 11, 2009 11:38 PM
Subject: RE: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03


Adding in Carlos who holds the pen for us, Please see inline starting
with SH:

-Original Message-
From: Spencer Dawkins [mailto:spen...@wonderhamster.org]
Sent: Friday, June 12, 2009 3:55 AM
To: Subbaiah Venkata; Sanjay Harwani (sharwani); Danny McPherson
Cc: i...@ietf.org; General Area Review Team; Ross Callon; Acee Lindem;
Abhay Roy (akr)
Subject: Gen-ART review of draft-ietf-ospf-dynamic-hostname-03

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ospf-dynamic-hostname-03
Reviewer: Spencer Dawkins
Review Date: 2009-06-11
IETF LC End Date: 2009-06-16
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed
Standard. I identified two minor issues listed below.

2.  Possible solutions

   Another approach is having a centralized location where the name-to-
   Router ID mapping can be kept.  DNS can be used for the same.  A
   disadvantage with this centralized solution is that its a single

Spencer (nit): s/its/it's/


Ack -- fixed in the working copy.



   point of failure; and although enhanced availability of the central
   mapping service can be designed, it may not be able to resolve the
   hostname in the event of reachability or network problems.  Also, the
   response time can be an issue with the centralized solution, which
   can be particularly problematic in times of problem resolution.  If

Spencer (minor): good point on response times, but I'd also think you'd
point out that looking up attributes on a centralized mapping table is
exactly the wrong thing to do when you're resolving problems with
routing - the centralized resource may not even be reachable.

SH: I think we already have it covered just above in the same paragraph.
(single point of failure)
snip
 A disadvantage with this centralized solution is that its a
single
   point of failure; and although enhanced availability of the central
   mapping service can be designed, it may not be able to resolve the
   hostname in the event of reachability or network problems.
/snip

SD: I'll call for my eye exam appointment when they open :-). What I 
liked

about the response time text was that it clearly called out the impact on
problem resolution - if it was possible for this to be clearly stated for
reachability, that seems helpful to me. If I was suggesting text, it 
might

be something like:

SD: A disadvantage with this centralized solution is that it's a single
point of failure; and although enhanced availability of the central 
mapping
service can be designed, it may not be able to resolve the hostname in 
the

event of reachability or network problems, which can be particularly
problematic in times of problem resolution. Also, the response time can 
be

an issue with the centralized solution, which can be equally problematic.



I think this text improves the paragraph. It is a very subtle (surgical)
change, but it highlights and emphasizes the impact on problem
resolution for both reachability and response time. Thanks for the
suggestion.
[Authors: change made in the working copy, let me know if other 
suggestions]




3.  Implementation

   The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL.  Upon receipt
   of the TLV a router may decide to ignore this TLV, or to install the
   symbolic

[Gen-art] Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-geopriv-lbyr-requirements-07
Reviewer: Spencer Dawkins
Review Date: 2009-06-03
IETF LC End Date: 2009-06-09
IESG Telechat date: (not known)

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


Comments: Most of my notes below involve text clarity. I did question one 
2119 keyword use in Section 4.1, as well.



1.  Introduction

  Location determination, different than location configuration or

Spencer (clarity): Is this s/different than/as distinct from/ ? but this 
sentence didn't parse for me.


  dereferencing, often includes topics related to manual provisioning
  processes, automated location calculations based on a variety of
  measurement techniques, and/or location transformations, (e.g., geo-
  coding), and is beyond the scope of this document.

  The issues around location configuration protocols have been
  documented in a location configuration protocol problem statement and
  requirements document [I-D.ietf-geopriv-l7-lcp-ps].  There are
  currently several examples of a location configuration protocols
  currently proposed, including, DHCP
  [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD

Spencer (clarity): got a reference for LLDP-MED here?

  [I-D.ietf-geopriv-http-location-delivery] protocols.


2.  Terminology

  Location Configuration Protocol:  A protocol which is used by a
 client to acquire either location or a location URI from a

Spencer (clarity): I'm guessing here that you mean s/either location/either 
a location object/


 location configuration server, based on information unique to the
 client.

3.3.  Location URI Authorization

  Location URIs manifest themselves in a few different forms.  The
  different ways that a location URI can be represented is based on
  local policy, and are depicted in the following four scenarios.

  1. No specific information at all:  As is typical, a location URI is

Spencer (clarity): could this be something more like No location 
information included in the URI:?


 used to get location information.  However, in this case, the URI
 representation itself does not need to reveal any specific
 information at all.  Location information is acquired by the
 dereferencing operation a location URI.

  2. No user specific information:  By default, a location URI MUST NOT

Spencer (clarity): could this be URI does not identify a user:?

 reveal any information about the Target other than location
 information.  This is true for the URI itself, (or in the document
 acquired by dereferencing), unless policy explicitly permits
 otherwise.

3.4.  Location URI Construction

  Depending on local policy, a location URI may be constructed in such
  a way as to make it difficult to guess.  Accordingly, the form of the
  URI is then constrained by the degree of randomness and uniqueness
  applied to it.  In this case, it may be important to protect the
  actual location information from inspection by an intermediate node.

Spencer (clarity): is this section applicable to all of the scenarios in the 
previous section, or just to possession authorization model? If not 
applicable to all, you might point that out here.


  Construction of a location URI in such a way as to not reveal any
  domain, user, or device specific information, with the goal of making
  the location URI appear bland, uninteresting, and generic, may be
  helpful to some degree in order to keep location information more
  difficult to detect.  Thus, obfuscating the location URI in this way
  may provide some level of safeguard against the undetected stripping
  off of what would otherwise be evident location information, since it
  forces a dereference operation at the location dereference server, an
  important step for the purpose of providing statistics, audit trails,
  and general logging for many different kinds of location based
  services.

4.1.  Requirements for a Location Configuration Protocol

  C3. Location URI cancellation:  The location configuration protocol
 MUST support the ability to request a cancellation of a specific
 location URI.

 Motivation: If the client determines that in its best interest to
 destroy the ability for a location URI to effectively be used to
 dereference a location, then there should be a way to nullify the
 location URI.

Spencer (clarity): sorry, but can't parse this sentence. Something like If 
the client determines that a location URI should no longer provide a 
location, then there should be a way to nullify the location URI?


  C5. User Identity Protection:  The location URI MUST NOT contain
 information that identifies the user or device

[Gen-art] Gen-ART review of draft-livingood-woundy-p4p-experiences-07

[Spencer Dawkins]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-livingood-woundy-p4p-experiences-07
Reviewer: Spencer Dawkins
Review Date: 2009-05-27
IETF LC End Date: 2009-06-16
IESG Telechat date: (not known)

Summary: This document is nearly ready for publication as an Informational 
RFC. I did identify some minor issues (listed below) that should be 
considered as this document moves forward in the approval process.


I also identified some nits, which aren't actually part of the Gen-ART 
review but are included for the convenience of the editor.


Thanks,

Spencer

1.  Requirements Language

  The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
  SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
  document are to be interpreted as described in RFC 2119 [RFC2119].

Spencer (nit): idnits says no 2119 keywords in the document, so this section 
can be deleted (along with the [rfc2119] reference.


2.  Introduction

  Comcast is a large broadband ISP, based in the U.S., serving the

Spencer (nit): 
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt doesn't list 
ISP as an abbreviation that isn't expanded (please expand on first use).


  majority of its customers via cable modem technology.  A trial was
  conducted in July 2008 with Pando Networks, Yale, and several ISP
  members of the P4P Working Group, which is part of the Distributed
  Computing Industry Association (DCIA).  Comcast is a member of the
  DCIA's P4P Working Group, whose mission is to work with Internet
  service providers (ISPs), peer-to-peer (P2P) companies, and
  technology researchers to develop P4P mechanisms, such as so-called
  iTrackers (hereafter P4P iTrackers), that accelerate distribution
  of content and optimize utilization of ISP network resources.  P4P
  iTrackers theoretically allow P2P networks to optimize traffic within
  each ISP, reducing the volume of data traversing the ISP's
  infrastructure and creating a more manageable flow of data.  P4P
  iTrackers can also accelerate P2P downloads for end users.

  The P4P iTracker trial was conducted, in cooperation with Pando,
  Yale, and three other P4P member ISPs, from July 2 to July 17, 2008.
  This was the first P4P iTracker trial over a cable broadband network.
  The trial used a Pando P2P client, and Pando distributed a special 21
  MB licensed video file in order to measure the effectiveness of P4P

Spencer (nit): suggest s/21 MB/21-MB/ for clarity

  iTrackers.  A primary objective of the trial was to measure the
  effects that increasing the localization of P2P swarms would have on

Spencer (minor): it would be helpful to add a definition for swarm - 
everyone kind of knows what you're talking about, but it's not even defined 
in Wikipedia :-) (per 
http://en.wikipedia.org/wiki/Swarm_(disambiguation))...


  P2P uploads, P2P downloads, and ISP networks, in comparison to normal
  P2P activity.


3.  High-Level Details

  There were five different swarms for the content used in the trial.
  The first was a random P2P swarm, as a control group.  The second,
  third, and fourth used different P4P iTrackers: Generic, Coarse
  Grained, and Fine Grained, all of which are described in Section 4.
  The fifth was a proprietary Pando mechanism.  (The results of the
  fifth swarm, while very good, are not included here since our focus

Spencer (minor): while very good is slightly more marketing-speak than I 
was comfortable with... the ADs can ignore this comment, of course.


  is on open standards and a mechanism which may be leveraged for the
  benefit of the entire community of P2P clients.)  Comcast deployed a
  P4P iTracker server in its production network to support this trial,
  and configured multiple iTracker files to provide varying levels of
  localization to clients.

4.1.  P4P Fine Grain

  The Fine Grain topology was the first and most complex P4P iTracker
  that we built for this trial.  It was a detailed mapping of Comcast
  backbone-connected network Autonomous System Numbers (ASN) to IP
  Aggregates which were weighted based on priority and distance from
  each other.  Included in this design was a prioritization of all Peer
  and Internet transit connected ASNs to the Comcast backbone to ensure
  that P4P traffic would prefer settlement free and lower cost networks
  first, and then more expensive transit links.  This attempted to
  optimize and lower transit costs associated with this traffic.  We
  then took the additional step of detailing each ASN and IP aggregate
  into IP subnets down to Optical Transport Nodes (OTN) where all Cable
  Modem Termination Systems (CMTS) reside.  This design gave a highly

Spencer (minor): you're referring to components of cable networking that 
probably aren't familiar

[Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netlmm-pmip6-ipv4-support-12
Reviewer: Spencer Dawkins
Review Date: 2009-05-18
IETF LC End Date: 2009-05-18
IESG Telechat date: 2009-05-21

Summary: This draft is almost ready for publication as a Proposed Standard. 
There are a small number of minor comments listed below, most of which are 
either about text clarity or 2119 language.


I have also included a small number of nits, for the convenience of the 
editor. These nits are not part of the Gen-ART review.


1.1.  Stated Assumptions

  The following are the configuration requirements from the mobility
  entities in the Proxy Mobile IPv6 domain for supporting the
  extensions defined in this document.

  o  The local mobility anchor and the mobile access gateway are both
 IPv4 and IPv6 enabled.  Irrespective of the type of transport

Spencer (nit): is this saying BOTH the local mobility and the mobile
access gateway are enabled for BOTH IPv4 and IPv6? If so, this might be
said more clearly...

 network (IPv4 or IPv6) separating these two entities, the mobility
 signaling is always based on Proxy Mobile IPv6 [RFC-5213].


2.2.  Terminology

  Selective De-registration

 It is a procedure for partial de-registration of all the addresses

Spencer (nit): s/It is a/A/ (just reads oddly to me in a technical
specification)

 that belong to one address family, i.e., de-registration of either
 IPv4 home address, or all of the IPv6 home network prefixes.

3.1.2.1.  Processing Proxy Binding Updates

  The processing rules specified in Section 5.3 of [RFC-5213] are
  applied for processing the received Proxy Binding Update message.
  However, if the received Proxy Binding Update message has an IPv4
  Home Address option [ID-DSMIP6], the following considerations MUST be
  applied additionally.

  o  If there is an IPv4 Home Address option [ID-DSMIP6] present in the
 received Proxy Binding Update message, but if there is no Home
 Network Prefix option [RFC-5213] present in the request, the local
 mobility anchor MUST NOT reject the request as specified in
 Section 5.3.1 of [RFC-5213].  At least one instance of any of
 these two options MUST be present.  If there is not a single

Spencer (minor): I'm confused by these two options - this MUST (and the
next MUST) are already in text that's conditional on an IPv4 Home Address
option being present, and the only other option that's named is Home Network
Prefix option. I'm not sure which two options are being discussed.
Should this text appear somewhere else (like, outside the If there is an
IPv4 Home Address option present)? If it's in the right place, s/any of
these two options/either the IPv4 Home Address option or the Home Network
Prefix option/ would be clearer - but I'm not sure if I'm understanding the
intent here.

 instance of any of these two options present in the request, the
 local mobility anchor MUST reject the request and send a Proxy
 Binding Acknowledgement message with Status field set to
 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
 network prefix option) [RFC-5213].

  o  If the prefix request(P) flag in the IPv4 Home Address option is
 set to a value of 1, then the local mobility anchor MUST reject

Spencer (nit): it would help readers if you also included an expansion of
value of 1 in parentheses, as you do for other magic numbers elsewhere
in this draft. I don't see prefix request flag elsewhere in this
document - if that's true, it would also be lovely if you provided a
reference to the document where it is defined, but that's less important if
you provide the expansion.

 the request and send a Proxy Binding Acknowledgement message with
 the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4
 prefix assignment not supported).

  o  If there exists a Binding Cache entry that can be associated with
 the request, the local mobility anchor MUST apply considerations
 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the
 request is re-registration or a de-registration request and the
 respective considerations from the below sections MUST be applied.

Spencer (nit): it would help readers if you could point to specific sections
below (because there are a lot to choose from!), as you do in similar text 
elsewhere in the document.


  o  If there exists a Binding Cache entry that can be associated with
 the request and if it is determined that the request is a re-
 registration request and with the request to extend IPv4 home
 address mobility support to the existing IPv6-only mobility
 session, considerations from Section 3.1.2.2 MUST be applied

[Gen-art] Gen-ART Review of draft-hollenbeck-rfc4930bis-01

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments 
you may receive. 


Document: draft-hollenbeck-rfc4930bis-01
Reviewer: Spencer Dawkins
Review Date: 2009-05-18
IETF LC End Date: 2009-06-11
IESG Telechat date: (not known) 


Summary: This document is ready for publication as a Full Standard


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

Re: [Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12

[Spencer Dawkins]

(dropping IETF discussion list)

Hi, Jari,

My apologies for not finishing the thought - when I tagged


3.2.3.2.  Receiving Proxy Binding Acknowledgement

  All the considerations from section 6.9.1.2 of [RFC-5213] MUST be
  applied with the following exceptions.

Spencer (minor): not sure why the next two bullets are SHOULD NOTs - we
usually provide at least one example of why an implementation would 
choose

not to perform SHOULD NOTs, for background.

  o  If the received Proxy Binding Acknowledgement message has the
 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
 mobile node is not authorized for IPv4 home address), the mobile
 access gateway SHOULD NOT send a Proxy Binding Update message
 including the IPv4 Home Address option [ID-DSMIP6] till an
 administrative action is taken.

  o  If the received Proxy Binding Acknowledgement message has the
 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
 mobile node is not authorized for the requesting IPv4 home
 address), the mobile access gateway SHOULD NOT request for the
 same address again, but MAY request the local mobility anchor to
 do the assignment of address by including exactly one instance of
 IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address
 and the prefix length fields in the option set to ALL_ZERO value.


While adding rules about when taking a SHOULD is useful, I do not think it 
is an absolute rule. Generally speaking, SHOULD says that you can disobey 
it but only if you fully understand the implications.


I should have also asked if it's clear what the other party does when the 
SHOULD NOT is violated. A MUST NOT is a clear protocol violation, so the 
choices are usually something like (1) send appropriate error response, or 
(2) drop silently. An implmentation that violates a SHOULD NOT is still 
conforming to the specification, so these choices aren't the right answers - 
is the appropriate reaction obvious?


I'm not smart enough about PMIP6 to know whether it's clear or not - but I 
should have asked the question. If you guys tell me no problem, no 
problem.


Thanks,

Spencer 



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

Re: [Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12

[Spencer Dawkins]

Hi, Sri,

(Thanks to everyone for the quick responses - I can still remember the 
review without having to re-read it ;-)



If the request is rejected with a specific reason, there is not point
for the requester to continue to send the messages for the exact same
service. Its ok to resend the message when some thing changes. Ex: An
administrative action allowing the user for that service.
So, the SHOULD NOT is with the goal to avoid unnecessary messaging.
Otherwise, the requester will recv the same error code.


I'm sorry, I'm not asking the question clearly - I'm asking why these SHOULD 
NOTs aren't MUST NOTs. Is there a reason why the requestor would resend the 
messages for the same service, without changing anything?


If there's a reason, SHOULD NOT would be appropriate. If there's not a 
reason, perhaps MUST NOTs would be more appropriate.


Thanks,

Spencer 



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

Re: [Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12

[Spencer Dawkins]

Hi, Ryuji,

Thanks for explaining - SHOULD NOTs will be fine (with me).

Spencer



Hi Spencer,

Thanks for the detailed comment.

On 2009/05/18, at 12:02, Spencer Dawkins wrote:


Hi, Sri,

(Thanks to everyone for the quick responses - I can still remember  
the review without having to re-read it ;-)



If the request is rejected with a specific reason, there is not point
for the requester to continue to send the messages for the exact same
service. Its ok to resend the message when some thing changes. Ex: An
administrative action allowing the user for that service.
So, the SHOULD NOT is with the goal to avoid unnecessary messaging.
Otherwise, the requester will recv the same error code.


I'm sorry, I'm not asking the question clearly - I'm asking why  
these SHOULD NOTs aren't MUST NOTs. Is there a reason why the  
requestor would resend the messages for the same service, without  
changing anything?


If there's a reason, SHOULD NOT would be appropriate. If there's not  
a reason, perhaps MUST NOTs would be more appropriate.


The MUST NOT is too strict in this case.
As Sri mentioned, it is just for optimization by skipping unnecessary  
messaging.


After operational action is taken by LMA and error is fixed, MAG  
should be able to retry the registration of the home address which

was previously rejected with  NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS.
The retry timing depends on operation and administrative matter. It  
might be the next registration or 1 hour later..

That's why we just put SHOULD NOT here.

We will work on the other comments.

regards,
ryuji











Thanks,

Spencer






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

[Gen-art] Gen-ART review of draft-ietf-dkim-overview-11

[Spencer Dawkins]

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 resolve 
these comments along with any other Last Call comments you may receive. 


Document: draft-ietf-dkim-overview-11
Reviewer: Spencer Dawkins
Review Date: 2009-05-15
IETF LC End Date: 2009-05-08 (oops!)
IESG Telechat date: 2009-05-21 


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

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

[Gen-art] Gen-ART review of draft-ietf-netlmm-grekey-option-06.txt

[Spencer Dawkins]

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-netlmm-grekey-option-06.txt
Reviewer: Spencer Dawkins
Review Date: 21 April 2009
IESG Telechat date: 23 April 2009
Summary: This draft is almost ready for publication as a Proposed Standard.
I did have some questions about 2119 SHOULD/SHOULD NOT usage in the
document.

Major issues: None.

Minor issues: See below.

Nits/editorial comments:

I agree with Ralph's note about using acronyms consistently (MAG being the
example I noticed first).

Is vanilla a clearly-understood term of art? :-)

-

4.2.  Operational Summary

  o  If the mobile access gateway includes the GRE Key option in the
 Proxy Binding Update for a specific mobile node and the local
 mobility anchor accepts the Proxy Binding Update by sending a
 Proxy Binding Acknowledgement with a success status code (less
 than 128) other than GRE KEY OPTION NOT REQUIRED, but without
 the GRE Key option, then the mobile access gateway MUST consider
 that the local mobility anchor does not support GRE Key option as
 per this specification.  The mobile access gateway SHOULD NOT
 include the GRE Key option in any subsequent Proxy Binding Update
 message that is sent to that LMA.

Spencer (minor): Why is this a SHOULD NOT (and not a MUST NOT)?

o  If the mobile access gateway sent a Proxy Binding Update message
 without the GRE Key option, but the received Proxy Binding
 Acknowledgement has the Status Code GRE KEY OPTION REQUIRED,
 indicating that the GRE encapsulation and GRE key is required, the
 mobile access gateway SHOULD resend the Proxy Binding Update
 message with the GRE Key option.  If the MAG does not support the

Spencer (minor): Why is this a SHOULD (and not a MUST)?

 GRE Key option, the MAG MAY log the event and possibly raise an
 alarm to indicate a possible misconfiguration.

  o  If the MAG has successfully negotiated GRE encapsulation and
 exchanged the GRE keys with the LMA for a specific mobility
 session, the MAG SHOULD NOT include the GRE Key option in the de-
 registration Proxy Binding Update.

Spencer (minor): Why is this a SHOULD NOT (and not a MUST NOT)?

7.2.  TLV-header Tunneling Negotiation

  The mobile access gateway negotiates the format for tunneling payload
  traffic during Proxy Mobile IPv6 registration procedure.  If the
  mobile access gateway is required to use the TLV-header UDP
  encapsulation format, the mobile access gateway MUST set the TLV-
  header Format (T) flag in the Proxy Binding Update message sent to
  the local mobility anchor.  If the local mobility anchor supports the
  TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header
  Format (T) flag in the Proxy Binding Acknowledgement.  Otherwise, the
  TLV-header Format (T) flag is cleared.  The setting of the TLV-header
  Format (T) flag in the Proxy Binding Acknowledgement indicates to the
  mobile access gateway that it MUST use the TLV-header UDP
  encapsulation format for all packets tunneled to the LMA for the
  entire duration the mobile node is attached to the mobile access
  gateway.  The TLV-header UDP tunneling format SHOULD NOT change
  during a Binding Lifetime Extension Proxy Binding Update (re-
  registration) from the same mobile access gateway.

Spencer (minor): Why is this a SHOULD NOT (and not a MUST NOT)?

7.4.  Local Mobility Anchor Operation

  When the local mobility anchor receives a Proxy Binding Update
  encapsulated in UDP and containing the IPv4 home address option, it
  needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4].  In
  addition, if the TLV-header Format (T) flag is set in the Proxy
  Binding Update, the local mobility anchor needs to determine whether
  it can accept the TLV-header UDP based encapsulation format.  If it
  does, it SHOULD set the TLV-header Format (T) flag in the Proxy
  Binding Acknowledgement.  Otherwise, the LMA MUST NOT set the TLV-

Spencer (minor): Why is this a SHOULD (and not a MUST)?

  header Format (T) flag in the Proxy Binding Acknowledgement.



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

[Gen-art] Gen-ART review of draft-ietf-rmt-pi-norm-revised-10

[Spencer Dawkins]

Just to let people know, version 10 of this specification addressed my 
questions from version 09, and I didn't see any new issues in text that was 
added in this version.


Thanks,

Spencer



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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-rmt-pi-norm-revised-09
Reviewer: Spencer Dawkins
Review Date: 2009-04-08
IETF LC End Date: 2009-04-15
IESG Telechat date: (not known)

Summary: This specification is almost ready for publication as a Proposed 
Standard. I have one minor issue that I'm pretty sure is just a missing 
word, but it's in a normative sentence, so clearly should be fixed before 
publication.


(Please note - this is a previously-published Experimental specification 
going to Proposed Standard, so I spent most of my review cycle looking at 
NEW text)


Major issues: None noted.

Minor issues:

4.2.3.1.  NORM_CMD(FLUSH) Message

  Note that receivers also employ a timeout mechanism to self-initiate
  NACKing (if there are outstanding repair needs) when no messages of
  any type are received from a sender.  This inactivity timeout is
  related to the NORM_CMD(FLUSH) and NORM_ROBUST_FACTOR and is
  specified in Section 5.3.  Receivers SHALL self-initiate the NACK
  repair process when the inactivity has expired for a specific sender

Spencer (minor): I'm guessing s/inactivity has/inactivity timeout has/, 
but something needs help here...


  and the receiver has pending repairs needed from that sender.  With a
  sufficiently large NORM_ROBUST_FACTOR value, data content is
  delivered with a high assurance of reliability.  The penalty of a
  large NORM_ROBUST_FACTOR value is the potential transmission of
  excess NORM_CMD(FLUSH) messages and a longer inactivity timeout for
  receivers to self-initiate a terminal NACK process.


Nits/editorial comments:

Abstract

  This document describes the messages and procedures of the Negative-
  ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol.
  This protocol is designed to provide end-to-end reliable transport of
  bulk data objects or streams over generic IP multicast routing and
  forwarding services.  NORM uses a selective, negative acknowledgment
  mechanism for transport reliability and offers additional protocol
  mechanisms to allow for operation with minimal a priori coordination
  among senders and receivers.  A congestion control scheme is
  specified to allow the NORM protocol to fairly share available
  network bandwidth with other transport protocols such as Transmission
  Control Protocol (TCP).  It is capable of operating with both
  reciprocal multicast routing among senders and receivers and with
  asymmetric connectivity (possibly a unicast return path) between the
  senders and receivers.  The protocol offers a number of features to
  allow different types of applications or possibly other higher level
  transport protocols to utilize its service in different ways.  The
  protocol leverages the use of FEC-based repair and other IETF
  reliable multicast transport (RMT) building blocks in its design.
  This document obsoletes RFC 3940.

Spencer (nit) - Requirements language is described before the table of 
contents - the RFC has it after the table of contents, which is where I 
would have expected it.


Requirements Language

  The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL
  NOT,SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in
  this document are to be interpreted as described in [RFC2119].

This also isn't quite the suggested boilerplate for 2119, according to 
idnits 2.11.08, but the difference is that the draft text specifies 
[RFC2119], not RFC 2119 - that should be fine.


___
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

Re: [Gen-art] Gen-ART LC review of draft-ietf-lemonade-streaming-10

[Spencer Dawkins]

Just to let people know, version 10 of this draft addresses all my questions 
from my -09 review.


Ready to publish as Informational.

Thanks,

Spencer



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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lemonade-streaming-09
Reviewer: Spencer Dawkins
Review Date: 2009-03-06
IETF LC End Date: 2009-03-12
IESG Telechat date: (not known)

Summary: Almost ready for publication as Informational. A couple of nits 
(forwarded for the editor, not part of Gen-ART reviews), and a couple of 
minor questions.


Comments:

1.  Introduction

  Email clients on resource and/or network constrained devices, such as
  mobile phones, may have difficulties in retrieving and/or storing
  large attachments received in a message.  For example, on a poor
  network link, the latency required to download the entire attachment

Spencer (nit): s/attachment/attachment before displaying any of it/, 
perhaps? The sentence seems to say the user won't download the entire 
attachment under any conditions, but that's probably not what it should 
say...


  may not be acceptable to the user.  Conversely, even on a high-speed
  network, the device may not have enough storage space to secure the
  attachment once retrieved.

3.1.  Overview of Mechanism

  The proposed mechanism has the following steps:

  1.  Client determines from MIME headers of a particular message that
  a particular message part (attachment) should be streamed to the
  user.  Note that no assumptions are made about how/when/if the
  client contacts the user of the client about this decision.  User
  input MAY be required in order to initiate the proposed
  mechanism.

Spencer (minor): this MAY doesn't smell 2119 to me...

3.2.  Media Server Discovery

  There is also a scenario where media server discovery would improve
  the security of the streaming mechanism, by avoiding the use of
  completely anonymous URLs.  For example, the client could discover a
  media server address that was an authorised user of the IMAP server
  for streaming purposes, which would allow the client to generate a
  URL, which was secure in that it could *only* be accessed by an
  entity that is trusted by the IMAP Server to retrieve content.  The
  issue of trust in media servers is discussed more fully in Section 4

Spencer (nit): missing period after 4.

  Example values of the /shared/mediaServers METADATA entry:

  sip:i...@ms.example.net:5060:stream;sip:annc@
  ms1.example.net:5060;sips:i...@ms2.example.net:5061

  sip:i...@192.0.2.40:5060;sip:192.0.2.41:5060;sips:annc@
  192.0.2.42:5060:stream

Spencer (minor): Hmm. The paragraph that talked about line wrapping in 
section 2 was specifically about S: and C:, and that doesn't apply here. 
Is this clear enough for the target reader? At a minimum, I see people 
indenting continuation lines in other specs...


3.7.  Client Use of the Media Server MSCML IVR Service

  Since the playcollect request is used purely for its VCR
  capabilities, there is no need for the media server to perform DTMF
  collection, therefore the playcollect attributes firstdigittimer,
  interdigittimer and extradigittimer SHOULD all be set to 0ms,
  which will have the effect of causing digit collection to cease
  immediately the media has finished playing.

Spencer (minor): immediately the is missing a word... if I could guess 
which word, this would be a nit.


3.8.  Media Server Use of IMAP Server

  If the media server is configured as an authorized user of the IMAP
  server, it SHOULD authenticate to the IMAP server using the
  credentials for that user.  This document does not go into the
  details of IMAP authentication, but the authentication SHOULD NOT use
  the LOGIN command over a non-encrypted communication path.

Spencer (minor, because I'm not your security reviewer): I'm struggling 
why this last statement is SHOULD NOT with no qualifications... if you 
tell me that this is normal practice in the e-mail community, I'll be 
quiet, but this would worry me if I saw it happening.


4.  Security Considerations

  o  However, since the media server will retrieve content from an IMAP
 server on the users behalf, the issue of security between the IMAP

Spencer (nit): s/users/user's/

 server and the media server also needs to be considered.  A client
 has no way of determining (programatically at least) the security
 of the exchanges between the media server and the IMAP server.
 However, it can determine, using the stream token that is part
 of the media server discovery mechanism described in Section 3.2,
 that the media server has a pre-existing authentication
 relationship with the IMAP server for the purposes of retrieving
 content using IMAP URLs.  The IMAP

[Gen-art] Gen-ART LC review of draft-ietf-avt-rtcp-non-compound-08

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-avt-rtcp-non-compound-08
Reviewer: Spencer Dawkins
Review Date: 2009-02-09
IETF LC End Date: 2009-02-09
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as a Proposed 
Standard. I have one minor comment and a few nits, reported below.


Major issues: None noted.

Minor issues:

4.2.1.  Verification of Delivery

  o  An algorithm to detect consistent failure of delivery of reduced-
 size RTCP MUST be used by any application using it.  The details
 of this algorithm are application dependent and therefore outside
 the scope of this document.

Spencer (minor): does it make sense to have a MUST for something that's out
of scope for this document, with no reference to any other document?

Nits/editorial comments:


1.  Introduction

  There are a number of benefits with reduced-size RTCP, these are
  discussed in Section 3.3.

Spencer (nit): s/RTCP,/RTCP;/

3.4.5.  Header Compression

  Two issues are related to header compression, possible changes are
  left for future work:

Spencer (nit): s/, possible/. Possible/

4.2.1.  Verification of Delivery

  o  The middle box issue is more difficult and here one will be
 required to use heuristics to determine if the reduced-size RTCP
 are delivered or not.  The methods detect successful delivery of
 reduced-size RTCP packets depends on the packet type.  The RTCP

Spencer (nit):s/methods detect/method used to detect/ (note that there are
missing words AND a numbering mismatch in this sentence).

 packet types for which successful delivery can be detected are:

6.  Security Considerations

  The security considerations of RTP [RFC3550] and AVPF [RFC4585] will
  apply also to reduced-size RTCP.  The reduction in validation
  strength for received packets on the RTCP port may result in a higher
  degree of acceptance of spurious data as real RTCP.  This
  vulnerability can mostly be addressed by usage of any security
  mechanism that provide authentication, one example such mechanism is
  SRTP [RFC3711].

Spencer (nit): s/authentication, one example such/authentication; one such/ 



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

[Gen-art] Gen-ART LC review of draft-ietf-netconf-tls-06.txt

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments you 
may receive.


Document: draft-ietf-netconf-tls-06.txt
Reviewer: Spencer Dawkins
Review Date: 2009-02-09
IETF LC End Date: 2009-02-19
IESG Telechat date: (not known)

Summary: This document is ready for publication as a Proposed Standard.

Major issues: none noted

Minor issues: none noted

Nits/editorial comments: one noted (as follows)

2.2. Connection Closure

  A TLS client (NETCONF manager) MUST close the associated TLS
  connection if the connection is not expected to issues any NETCONF

Spencer (nit): s/issues/issue/

  RPC commands later.  It MUST send a TLS close_notify alert before
  closing the connection.  The TLS client MAY choose to not wait for
  the TLS server (NETCONF agent) close_notify alert and simply close
  the connection, thus generating an incomplete close on the TLS server
  side.  Once the TLS server gets a close_notify from the TLS client,
  it MUST reply with a close_notify unless it becomes aware that the
  connection has already been closed by the TLS client (e.g., the
  closure was indicated by TCP).



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

Re: [Gen-art] Gen-ART review of draft-melnikov-sieve-imapext-metadata-08

[Spencer Dawkins]

Hi, Alexey,

That would be great - and thanks for continuing to think about my comments.

Spencer

- Original Message - 
From: Alexey Melnikov alexey.melni...@isode.com

To: Spencer Dawkins spen...@wonderhamster.org
Cc: i...@ietf.org; General Area Review Team gen-art@ietf.org; Lisa 
Dusseault l...@osafoundation.org

Sent: Tuesday, January 20, 2009 6:17 AM
Subject: Re: Gen-ART review of draft-melnikov-sieve-imapext-metadata-08



Spencer Dawkins wrote:


Hi, Alexey,


Hi Spencer,

Thanks for the quick response back... now I can remember what I said in 
the review ;-)


Spencer


Spencer Dawkins wrote:



[...]


5.  Security Considerations

  Extensions defined in this document deliberately don't provide a way
  to modify annotations.

Spencer: The next two paragraphs punt to same as sieve script - could 
you

provide a specific reference for the reader here?


Reference to the Sieve document?


If that's where the security considerations for sieve scripts are 
located - that would be fine.


After thinking more about this: RFC 5228 (Sieve base) doesn't describe how 
Sieve scripts are stored and how to handle failure to retrieve them - this 
is out of scope for both documents. However I can add an example of what I 
meant here - if a Sieve script is stored in LDAP and the script can't be 
retrieved when a message is processed, then the agent performing Sieve 
processing can, for example, assume that the script doesn't exist, or 
delay message delivery until the script can be retrieved successfully. 
Annotations should be treated as if they are a part of the script itself, 
so a temporary failure to retrieve them should be handled in the same way 
as a temporary failure to retrieve the Sieve script itself.






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

[Gen-art] Gen-ART Last Call review of draft-ietf-tls-ecdhe-psk-05.txt

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-tls-ecdhe-psk-05.txt
Reviewer: Spencer Dawkins
Review Date: 2009-01-19
IETF LC End Date: 2009-01-26
IESG Telechat date: (not known)

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


Minor issues:

In this document, all of the ciphersuite numbers are given as 0xXX,0xXX. If 
I understand the document, IANA should be assigning these values, but I 
didn't see guidance to IANA about whether the ciphersuite values should be 
chosen from the Standards Action or Specification Required ranges. Is it 
implicit that the values would be from Specification Required, because this 
is an Informational RFC?


I'm not a security type, but if the document is revised, it might be good to 
provide that guidance. 



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

Re: [Gen-art] Gen-ART review ofdraft-ietf-ospf-manet-mdr-04.txt

[Spencer Dawkins]

Just for completeness, version 04 addresses all of my comments from 03. 
Ready for publication as Experimental.


Thanks,

Spencer



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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-ospf-manet-mdr-03.txt
Reviewer: Spencer Dawkins
Review Date: 2008-12-12
IETF LC End Date: 2008-12-24
IESG Telechat date: (not known)
Summary: This draft is on the right track for publication as Experimental. 
I have a small number of questions, listed below.


Comments:

2.6.  Hello Protocol

  Differential Hellos are sent every HelloInterval seconds, except when
  full Hellos are sent, which happens once every 2HopRefresh Hellos.

Spencer (clarity): Is 2HopRefresh a counter? As I continue reading, it 
seems
to be treated as a counter, but that wasn't clear to me at this point in 
the

document (I think I caught up in Section 4.1, but that's later than I'd
hoped)

  The default value of 2HopRefresh is 1, i.e., the default is to send
  only full Hellos.  The default value for HelloInterval is 2 seconds.
  Differential Hellos are used to reduce overhead and to allow Hellos
  to be sent more frequently, for faster reaction to topology changes.

3.2.  New Configurable Interface Parameters

  All possible configurations of the new interface parameters are
  functional, except that if AdjConnectivity is 0 (full-topology
  adjacencies), then LSAFullness must be 1, 2, or 4 (see Section 9.3).
  Differential Hellos should be used to reduce the size of Hello
  packets when the average number of neighbors is large.  Differential

Spencer (clarity): does large have any relationship with 160 or 200
nodes mentioned in the next paragraph?

  Hellos are obtained by setting the parameter 2HopRefresh to an
  integer greater than 1, with the recommended value being 3.  Good
  performance in simulated mobile networks with up to 160 nodes has
  been obtained using the default configuration with differential
  Hellos.  Good performance in simulated mobile networks with up to 200
  nodes has been obtained using the same configuration except with
  minimal LSAs (LSAFullness = 0).  Simulation results are presented in
  Appendix E.

  MDRConstraint
 A parameter of the MDR selection algorithm, which affects the
 number of MDRs selected.  The default value of 3 results in nearly
 the minimum number of MDRs.  The optional value 2 results in a
 larger number of MDRs.

Spencer(clarity): are 3 and 2 the only possible values for this
parameter? If so, that's fine, but the chosen values made me wonder about
other possible values...

12.  IANA Considerations

  This document defines three new LLS TLV types to be allocated by
  IANA: MDR-Hello TLV, MDR-Metric TLV, and MDR-DD TLV.

Spencer (clarity): it would be good to point to the definitions in this 
section.


D.  Non-Ackable LSAs for Periodic Flooding

  In a highly mobile network, it is possible that a router almost
  always originates a new router-LSA every MinLSInterval seconds.  In
  this case, it should not be necessary to send Acks for such an LSA,
  or to retransmit such an LSA as a unicast, or to describe such an LSA
  in a DD packet.  In this case, the originator of an LSA MAY indicate
  that the router-LSA is non-ackable by setting a bit (to be
  specified) in the options field of the LSA.  For example, a router

Spencer: to be specified? Is this the L bit described in A.1?

  can originate non-ackable LSAs if it determines (e.g., based on an
  exponential moving average) that a new LSA is originated every
  MinLSInterval seconds at least 90 percent of the time. (Simulations
  can be used to determine the best threshold.)

___
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

Re: [Gen-art] Gen-ART review of draft-ietf-ospf-lls-06.txt

[Spencer Dawkins]

Just to let people know, version 06 addresses all of my comments on -05...

Thanks!

Spencer



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 resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-ospf-lls-05.txt
Reviewer: Spencer Dawkins
Review Date: 2008-11-05
IETF LC End Date: 2008-11-10

Summary: This document is on the right track for publication as Proposed 
Standard. I have a couple of 2119 questions.


Comments:

  The 16-bit LLS Data Length field contains the length (in 32-bit
  words) of the LLS block including the header and payload.
  Implementations MUST NOT use the Length field in the IP packet header
  to determine the length of the LLS data block.

Spencer: I'm not sure this is a 2119 MUST NOT - aren't you just saying 
that if you try it, you'll fail?


  The CA-TLV MUST only appear once in the the LLS block.  Also, when
  present, this TLV SHOULD be the last TLV in the LLS block.

Spencer: Why SHOULD and not MUST? At a minimum, I would expect to see some 
description of what should happen if CA-TLV is NOT the last TLV in the LLS 
block - and if the expectation is that processing continues, I'm not sure 
what this sentence means...


___
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

Re: [Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06

[Spencer Dawkins]

Hi, Jouni,

Both of these are clearer - thanks for your patience.

Spencer



Hi Spencer,


On Dec 29, 2008, at 6:13 PM, Spencer Dawkins wrote:


Hi, Jouni,

Thanks for your quick response - I'm OK with most of your proposed  
changes.


I should emphasize that my comments here are Last Call comments that  
you (and the document shepherd, and the AD) can decide to ignore -  
I'm just telling you what I'm seeing when I read the text.


Just to finish up:


Some of the potential use-cases were listed earlier in this section.
The general aim is better manageability of services and service
provisioning from both operators and service providers point of  
view.

However, it should be understood that there are potential deployment
possibilities where selecting a certain service may restrict
simultaneous access to other services from an user point of view.
For example, services may be located in different administrative
domains or external customer networks that practice excessive
filtering of inbound and outbound traffic.

Spencer: I wasn't clear on who this understanding is directed to -  
it almost reads like you're warning users that bad things might  
happen if you use a specific service, but surely the user  
specifies the service because an operator requires this?


We had this discussion earlier on RFC5149.. and concerns were raised
whether the Service Selection is a potential tool for enabling walled
gardens etc. Thus this note here was added to emphasize that point.


I understand your point from your explanation, but can't get that  
understanding from the draft text. If you said


s/from a user point of view/from a user point of view (for example,  
a walled garden)/


that would be as clear as your explanation.


Ok. Thanks. Will add this.






3.  Service Selection Extension

At most one Service Selection extension MAY be included in any  
Mobile
IPv4 Registration Request message.  It SHOULD be included at least  
in


Spencer: seems to be missing a qualifier: When a non-default  
service is selected, the Service Selection extension SHOULD be  
included ...?


Spencer: If this is qualified, could the SHOULD be a MUST?


Hmm.. right. New text would be:

 At most one Service Selection extension MAY be included in any  
Mobile
 IPv4 Registration Request message.  When a non-default service is  
selected,

 the Service Selection extension SHOULD be included at least in
 the Registration Request message that is sent for the initial  
binding

 registration when the mobile node and the home agent do not have an
 existing binding.  The Service Selection extension MUST be placed in
 the Registration Request message as follows:



Spencer: If it remains as SHOULD, what happens if the Service  
Selection extension is not included in the initial binding  
registration, but is included in subsequent binding registrations?


The first RRQ would be treated as the selection of the default
service. The subsequent RRQs with the service selection would cause
reauthorization  evaluation of the requested service. If the newly
requested service conflicts with the default service from the HA
point of view, then an appropriate error is returned and the binding
is dropped.


I'm still confused by


When a non-default service is selected,
 the Service Selection extension SHOULD be included at least in
 the Registration Request message that is sent for the initial  
binding

 registration when the mobile node and the home agent do not have an
 existing binding.


My understanding from your explanation is that, by definition, if  
you don't include the Service Selection extension, you aren't  
selecting a non-default service until you DO send an RRQ that  
includes the Service Selection extension - right? If I'm tracking  
you, you're talking about two cases at the same time - what happens  
if you DO include the extension in the first RRQ, and what happens  
if you DON'T include the extension in the first RRQ, then switch to  
a non-default service by including the Service Selection extension  
in a subsequent RRQ - that would be why I was confused.


I think your explanation is way clearer than the draft text -  
perhaps you could insert it into the draft text?


A new try:

   At most one Service Selection extension MAY be included in any  
Mobile

   IPv4 Registration Request message.  The Service Selection extension
   SHOULD be included at least in the Registration Request message that
   is sent for the initial binding registration when the mobile node  
and

   the home agent do not have an existing binding. In absence of a
   specifically indicated service in the Registration Request for the
   initial binding registration, the home agent MUST act as if the  
default
   service, such as plain Internet access had been requested. The  
absence

   of the Service Selection extension in a Registration Request that
   refreshes an existing binding MUST be treated as if the existing  
service
   selection is maintained

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt

[Spencer Dawkins]

Hi, Richard,

These changes address all my comments - best wishes with your draft.

Happy New Year,

Spencer

- Original Message - 
From: Richard Ogier rich.og...@earthlink.net

To: Spencer Dawkins spen...@wonderhamster.org
Cc: phillipspagn...@gmail.com; General Area Review Team 
gen-art@ietf.org; Acee Lindem a...@redback.com; Abhay Roy 
a...@cisco.com

Sent: Sunday, December 28, 2008 4:59 PM
Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt



Hi Spencer,

I have updated the draft to address all of your comments.
http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-04.txt

Answers to your questions are given below.

Thanks,
Richard

Spencer Dawkins 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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-ospf-manet-mdr-03.txt
Reviewer: Spencer Dawkins
Review Date: 2008-12-12
IETF LC End Date: 2008-12-24
IESG Telechat date: (not known)
Summary: This draft is on the right track for publication as 
Experimental. I have a small number of questions, listed below.


Comments:

2.6.  Hello Protocol

  Differential Hellos are sent every HelloInterval seconds, except when
  full Hellos are sent, which happens once every 2HopRefresh Hellos.

Spencer (clarity): Is 2HopRefresh a counter? As I continue reading, it 
seems
to be treated as a counter, but that wasn't clear to me at this point in 
the

document (I think I caught up in Section 4.1, but that's later than I'd
hoped) .



Richard:  To clarify the meaning of the parameter 2HopRefresh, I modified 
the text
in Section 2.6 (overview) to be similar to the corresponding text in 
Section 4.1.




  The default value of 2HopRefresh is 1, i.e., the default is to send
  only full Hellos.  The default value for HelloInterval is 2 seconds.
  Differential Hellos are used to reduce overhead and to allow Hellos
  to be sent more frequently, for faster reaction to topology changes.

3.2.  New Configurable Interface Parameters

  All possible configurations of the new interface parameters are
  functional, except that if AdjConnectivity is 0 (full-topology
  adjacencies), then LSAFullness must be 1, 2, or 4 (see Section 9.3).
  Differential Hellos should be used to reduce the size of Hello
  packets when the average number of neighbors is large.  Differential

Spencer (clarity): does large have any relationship with 160 or 200
nodes mentioned in the next paragraph?



Richard:  No.  To give an idea of what large means here, I added
(e.g., greater than 50) after the word large.



  Hellos are obtained by setting the parameter 2HopRefresh to an
  integer greater than 1, with the recommended value being 3.  Good
  performance in simulated mobile networks with up to 160 nodes has
  been obtained using the default configuration with differential
  Hellos.  Good performance in simulated mobile networks with up to 200
  nodes has been obtained using the same configuration except with
  minimal LSAs (LSAFullness = 0).  Simulation results are presented in
  Appendix E.

  MDRConstraint
 A parameter of the MDR selection algorithm, which affects the
 number of MDRs selected.  The default value of 3 results in nearly
 the minimum number of MDRs.  The optional value 2 results in a
 larger number of MDRs.

Spencer(clarity): are 3 and 2 the only possible values for this
parameter? If so, that's fine, but the chosen values made me wonder about
other possible values...



Richard:  I added text specifying that MDRConstraint can be any integer
greater than or equal to 2.



12.  IANA Considerations

  This document defines three new LLS TLV types to be allocated by
  IANA: MDR-Hello TLV, MDR-Metric TLV, and MDR-DD TLV.

Spencer (clarity): it would be good to point to the definitions in this 
section.



Richard:  Done.



D.  Non-Ackable LSAs for Periodic Flooding

  In a highly mobile network, it is possible that a router almost
  always originates a new router-LSA every MinLSInterval seconds.  In
  this case, it should not be necessary to send Acks for such an LSA,
  or to retransmit such an LSA as a unicast, or to describe such an LSA
  in a DD packet.  In this case, the originator of an LSA MAY indicate
  that the router-LSA is non-ackable by setting a bit (to be
  specified) in the options field of the LSA.  For example, a router

Spencer: to be specified? Is this the L bit described in A.1?



Richard:  Yes.  I modified the text to indicate this.



  can originate non-ackable LSAs if it determines (e.g., based on an
  exponential moving average) that a new LSA is originated every
  MinLSInterval seconds at least 90 percent of the time. (Simulations
  can be used to determine the best threshold.)








___
Gen-art mailing list
Gen-art@ietf.org

Re: [Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06

[Spencer Dawkins]

Hi, Jouni,

Thanks for your quick response - I'm OK with most of your proposed changes.

I should emphasize that my comments here are Last Call comments that you 
(and the document shepherd, and the AD) can decide to ignore - I'm just 
telling you what I'm seeing when I read the text.


Just to finish up:


 Some of the potential use-cases were listed earlier in this section.
 The general aim is better manageability of services and service
 provisioning from both operators and service providers point of view.
 However, it should be understood that there are potential deployment
 possibilities where selecting a certain service may restrict
 simultaneous access to other services from an user point of view.
 For example, services may be located in different administrative
 domains or external customer networks that practice excessive
 filtering of inbound and outbound traffic.

Spencer: I wasn't clear on who this understanding is directed to - it 
almost reads like you're warning users that bad things might happen if 
you use a specific service, but surely the user specifies the service 
because an operator requires this?


We had this discussion earlier on RFC5149.. and concerns were raised
whether the Service Selection is a potential tool for enabling walled
gardens etc. Thus this note here was added to emphasize that point.


I understand your point from your explanation, but can't get that 
understanding from the draft text. If you said


s/from a user point of view/from a user point of view (for example, a 
walled garden)/


that would be as clear as your explanation.


3.  Service Selection Extension

 At most one Service Selection extension MAY be included in any Mobile
 IPv4 Registration Request message.  It SHOULD be included at least in

Spencer: seems to be missing a qualifier: When a non-default service is 
selected, the Service Selection extension SHOULD be included ...?


Spencer: If this is qualified, could the SHOULD be a MUST?


Hmm.. right. New text would be:

  At most one Service Selection extension MAY be included in any Mobile
  IPv4 Registration Request message.  When a non-default service is 
selected,

  the Service Selection extension SHOULD be included at least in
  the Registration Request message that is sent for the initial binding
  registration when the mobile node and the home agent do not have an
  existing binding.  The Service Selection extension MUST be placed in
  the Registration Request message as follows:



Spencer: If it remains as SHOULD, what happens if the Service Selection 
extension is not included in the initial binding registration, but is 
included in subsequent binding registrations?


The first RRQ would be treated as the selection of the default
service. The subsequent RRQs with the service selection would cause
reauthorization  evaluation of the requested service. If the newly
requested service conflicts with the default service from the HA
point of view, then an appropriate error is returned and the binding
is dropped.


I'm still confused by


When a non-default service is selected,
  the Service Selection extension SHOULD be included at least in
  the Registration Request message that is sent for the initial binding
  registration when the mobile node and the home agent do not have an
  existing binding.


My understanding from your explanation is that, by definition, if you don't 
include the Service Selection extension, you aren't selecting a non-default 
service until you DO send an RRQ that includes the Service Selection 
extension - right? If I'm tracking you, you're talking about two cases at 
the same time - what happens if you DO include the extension in the first 
RRQ, and what happens if you DON'T include the extension in the first RRQ, 
then switch to a non-default service by including the Service Selection 
extension in a subsequent RRQ - that would be why I was confused.


I think your explanation is way clearer than the draft text - perhaps you 
could insert it into the draft text?


Thanks, and Happy New Year,

Spencer 



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

[Gen-art] Gen-ART review of draft-melnikov-sieve-imapext-metadata-08

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-melnikov-sieve-imapext-metadata-08
Reviewer: Spencer Dawkins
Review Date: 2008-12-23
IETF LC End Date: 2009-01-14
IESG Telechat date: (not known)

Summary: Almost ready for publication as a Proposed Standard. Please see
notes below.

Comments:


3.  mailbox and mboxmetadata extensions


3.1.  Test mailboxexists

  Note that a successful mailboxexists test for a mailbox doesn't
  necessarily mean that a fileinto action on this mailbox would
  succeed.  For example the fileinto action might put user over
  quota.  The mailboxexists only verifies existence of the mailbox
  and whether the user in whose context the Sieve script runs has
  permissions to execute fileinto on it.

Spencer (nit): you've been putting fileinto in quotes, up to this point -
suggest that this be consistent.

  The capability string for use with the require command is mailbox.

  Example: The following example assumes that the Sieve engine also
  supports reject [REJECT] and fileinto [SIEVE].  However these
  extensions are not required in order to implement the mailbox
  extension.

   require [fileinto, reject, mailbox];
   if mailboxexists Partners {
  fileinto Partners;
   } else {
  reject This message was not accepted by the Mailstore;
   }

5.  Security Considerations

  Extensions defined in this document deliberately don't provide a way
  to modify annotations.

Spencer: The next two paragraphs punt to same as sieve script - could you
provide a specific reference for the reader here? Just the reference would
be fine, nothing else needed.

  A failure to retrieve data due to the server storing the annotations
  being down or otherwise inaccessible may alter the result of Sieve
  processing.  So implementations SHOULD treat a temporary failure to
  retrieve annotations in the same manner as a temporary failure to
  retrieve a Sieve script.

  Protocols/APIs used to retrieve annotations MUST provide the same
  level of confidentiality as protocols/APIs used to retrieve Sieve
  scripts.


6.  IANA Considerations

  IANA is requested to add the following registrations to the list of
  Sieve extensions:

  To: i...@iana.org
  Subject: Registration of new Sieve extension
  Capability name: mailbox
  Description: adds test for checking for mailbox existence and a new
  optional argument to fileinto for creating a mailbox before
  attempting mail delivery.
  RFC number: this RFC

Spencer: you probably want to add notes to IANA and the RFC Editor to
replace this RFC with the RFC number when it is assigned (just make it
easier for them).

  Contact address:
  The Sieve discussion list ietf-mta-filt...@imc.org

  Capability name: mboxmetadata
  Description: adds tests for checking for mailbox metadata item
  existence and for retrieving of a mailbox metadata value.
  RFC number: this RFC
  Contact address:
  The Sieve discussion list ietf-mta-filt...@imc.org

  Capability name: servermetadata
  Description: adds tests for checking for server metadata item
  existence and for retrieving of a server metadata value.
  RFC number: this RFC
  Contact address:
  The Sieve discussion list ietf-mta-filt...@imc.org


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

Re: [Gen-art] Gen-ART review of draft-melnikov-sieve-imapext-metadata-08

[Spencer Dawkins]

Hi, Alexey,

Thanks for the quick response back... now I can remember what I said in the 
review ;-)


Spencer



Spencer Dawkins 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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-melnikov-sieve-imapext-metadata-08
Reviewer: Spencer Dawkins
Review Date: 2008-12-23
IETF LC End Date: 2009-01-14
IESG Telechat date: (not known)

Summary: Almost ready for publication as a Proposed Standard. Please see
notes below.

Hi Spencer,
Thank you for your review.

Comments:


3.  mailbox and mboxmetadata extensions


3.1.  Test mailboxexists

  Note that a successful mailboxexists test for a mailbox doesn't
  necessarily mean that a fileinto action on this mailbox would
  succeed.  For example the fileinto action might put user over
  quota.  The mailboxexists only verifies existence of the mailbox
  and whether the user in whose context the Sieve script runs has
  permissions to execute fileinto on it.

Spencer (nit): you've been putting fileinto in quotes, up to this 
point -

suggest that this be consistent.

Ok.
In my experience RFC editors are quite good in catching this type of 
thing. But I will fix that if I need to publish another revision before 
publication.


I think all of my comments could be handled as RFC editor notes, if Lisa 
prefers that - I'm good either way.




  The capability string for use with the require command is mailbox.

  Example: The following example assumes that the Sieve engine also
  supports reject [REJECT] and fileinto [SIEVE].  However these
  extensions are not required in order to implement the mailbox
  extension.

   require [fileinto, reject, mailbox];
   if mailboxexists Partners {
  fileinto Partners;
   } else {
  reject This message was not accepted by the Mailstore;
   }

5.  Security Considerations

  Extensions defined in this document deliberately don't provide a way
  to modify annotations.

Spencer: The next two paragraphs punt to same as sieve script - could 
you

provide a specific reference for the reader here?

Reference to the Sieve document?


If that's where the security considerations for sieve scripts are located - 
that would be fine.



Just the reference would
be fine, nothing else needed.

  A failure to retrieve data due to the server storing the annotations
  being down or otherwise inaccessible may alter the result of Sieve
  processing.  So implementations SHOULD treat a temporary failure to
  retrieve annotations in the same manner as a temporary failure to
  retrieve a Sieve script.

  Protocols/APIs used to retrieve annotations MUST provide the same
  level of confidentiality as protocols/APIs used to retrieve Sieve
  scripts.


6.  IANA Considerations

  IANA is requested to add the following registrations to the list of
  Sieve extensions:

  To: i...@iana.org
  Subject: Registration of new Sieve extension
  Capability name: mailbox
  Description: adds test for checking for mailbox existence and a new
  optional argument to fileinto for creating a mailbox before
  attempting mail delivery.
  RFC number: this RFC

Spencer: you probably want to add notes to IANA and the RFC Editor to
replace this RFC with the RFC number when it is assigned (just make it
easier for them).

Ok.


Thanks again, and have a great week.

Spencer


  Contact address:
  The Sieve discussion list ietf-mta-filt...@imc.org

  Capability name: mboxmetadata
  Description: adds tests for checking for mailbox metadata item
  existence and for retrieving of a mailbox metadata value.
  RFC number: this RFC
  Contact address:
  The Sieve discussion list ietf-mta-filt...@imc.org

  Capability name: servermetadata
  Description: adds tests for checking for server metadata item
  existence and for retrieving of a server metadata value.
  RFC number: this RFC
  Contact address:
  The Sieve discussion list ietf-mta-filt...@imc.org






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

[Gen-art] Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt

[Spencer Dawkins]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-ospf-manet-mdr-03.txt
Reviewer: Spencer Dawkins
Review Date: 2008-12-12
IETF LC End Date: 2008-12-24
IESG Telechat date: (not known)
Summary: This draft is on the right track for publication as Experimental. I 
have a small number of questions, listed below.


Comments:

2.6.  Hello Protocol

  Differential Hellos are sent every HelloInterval seconds, except when
  full Hellos are sent, which happens once every 2HopRefresh Hellos.

Spencer (clarity): Is 2HopRefresh a counter? As I continue reading, it seems
to be treated as a counter, but that wasn't clear to me at this point in the
document (I think I caught up in Section 4.1, but that's later than I'd
hoped)

  The default value of 2HopRefresh is 1, i.e., the default is to send
  only full Hellos.  The default value for HelloInterval is 2 seconds.
  Differential Hellos are used to reduce overhead and to allow Hellos
  to be sent more frequently, for faster reaction to topology changes.

3.2.  New Configurable Interface Parameters

  All possible configurations of the new interface parameters are
  functional, except that if AdjConnectivity is 0 (full-topology
  adjacencies), then LSAFullness must be 1, 2, or 4 (see Section 9.3).
  Differential Hellos should be used to reduce the size of Hello
  packets when the average number of neighbors is large.  Differential

Spencer (clarity): does large have any relationship with 160 or 200
nodes mentioned in the next paragraph?

  Hellos are obtained by setting the parameter 2HopRefresh to an
  integer greater than 1, with the recommended value being 3.  Good
  performance in simulated mobile networks with up to 160 nodes has
  been obtained using the default configuration with differential
  Hellos.  Good performance in simulated mobile networks with up to 200
  nodes has been obtained using the same configuration except with
  minimal LSAs (LSAFullness = 0).  Simulation results are presented in
  Appendix E.

  MDRConstraint
 A parameter of the MDR selection algorithm, which affects the
 number of MDRs selected.  The default value of 3 results in nearly
 the minimum number of MDRs.  The optional value 2 results in a
 larger number of MDRs.

Spencer(clarity): are 3 and 2 the only possible values for this
parameter? If so, that's fine, but the chosen values made me wonder about
other possible values...

12.  IANA Considerations

  This document defines three new LLS TLV types to be allocated by
  IANA: MDR-Hello TLV, MDR-Metric TLV, and MDR-DD TLV.

Spencer (clarity): it would be good to point to the definitions in this 
section.


D.  Non-Ackable LSAs for Periodic Flooding

  In a highly mobile network, it is possible that a router almost
  always originates a new router-LSA every MinLSInterval seconds.  In
  this case, it should not be necessary to send Acks for such an LSA,
  or to retransmit such an LSA as a unicast, or to describe such an LSA
  in a DD packet.  In this case, the originator of an LSA MAY indicate
  that the router-LSA is non-ackable by setting a bit (to be
  specified) in the options field of the LSA.  For example, a router

Spencer: to be specified? Is this the L bit described in A.1?

  can originate non-ackable LSAs if it determines (e.g., based on an
  exponential moving average) that a new LSA is originated every
  MinLSInterval seconds at least 90 percent of the time. (Simulations
  can be used to determine the best threshold.) 



___
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-ospf-lls-05.txt

[Spencer Dawkins]

Just as a heads-up - this document is on the agenda for the next telechat - 
I agree with Abhay's suggestions for changes that will appear in the next 
revision, but the next revision hasn't come out yet, at least not that I've 
seen.


Thanks!

Spencer

- Original Message - 
From: Abhay Roy a...@cisco.com

To: Spencer Dawkins spen...@wonderhamster.org
Cc: Alex Zinin zi...@psg.com; Liem Nguyen lhngu...@cisco.com; Barry 
Friedman fried...@redback.com; Derek Young mye...@cisco.com; 
i...@ietf.org; General Area Review Team gen-art@ietf.org; David Ward 
dw...@cisco.com; Acee Lindem a...@redback.com; Abhay Roy 
a...@cisco.com

Sent: Friday, December 12, 2008 11:19 PM
Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-lls-05.txt



Thanks for the review. Please see inline for comments..

On 11/5/2008 8:34 AM, Spencer Dawkins 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 resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-ospf-lls-05.txt
Reviewer: Spencer Dawkins
Review Date: 2008-11-05
IETF LC End Date: 2008-11-10

Summary: This document is on the right track for publication as Proposed 
Standard. I have a couple of 2119 questions.


Comments:

  The 16-bit LLS Data Length field contains the length (in 32-bit
  words) of the LLS block including the header and payload.
  Implementations MUST NOT use the Length field in the IP packet header
  to determine the length of the LLS data block.

Spencer: I'm not sure this is a 2119 MUST NOT - aren't you just saying 
that if you try it, you'll fail?


We discussed about it, and decided to remove the 2nd sentence above.



  The CA-TLV MUST only appear once in the the LLS block.  Also, when
  present, this TLV SHOULD be the last TLV in the LLS block.

Spencer: Why SHOULD and not MUST? At a minimum, I would expect to see 
some description of what should happen if CA-TLV is NOT the last TLV in 
the LLS block - and if the expectation is that processing continues, I'm 
not sure what this sentence means...


The thinking was we could have found the TLV at a fixed location to 
speed up authenticating the LLS block. But after discussing more on it, we 
decided to get rid of this requirement.


I will make the changes in the next revision..

Regards,
-Abhay




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

[Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-korhonen-mip4-service-06
Reviewer: Spencer Dawkins
Review Date: 2008-12-02
IETF LC End Date: 2008-12-24
IESG Telechat date: (not known)
Summary: This draft is on the right track for publication as Informational 
(should it be standards-track, if you're expecting this to be widely 
deployed? But I'll leave that to the IESG).


I do have comments, especially involving 2119 language.

Comments:

(Can Jouni's e-mail address really be
  Email: [EMAIL PROTECTED]
?)

1.  Introduction

  This document describes a Service Selection Extension for Mobile IPv4
  that is intended to assist home agents to make specific service
  selections for the mobility service subscription during the
  registration procedure.  The service selection may affect home agent
  routing decisions, Home Address assignment policies, firewall
  settings, and security policies.  The Service Selection extension
  SHOULD be used in every Registration Request that makes a new
  registration to the home agent.  The Service Selection extension from
  the Registration Request MAY be echoed back in the Registration
  Reply.

Spencer: I don't usually see 2119 normative language in the introduction of 
Internet Drafts... at a minimum, these statements appear before the 
requirements key words are introduced in section 2. I THINK most of these 
requirements are restated later in the document anyway, so they could 
probably be dropped here.


  In absence of a specifically indicated service the home agent MUST
  act as if the default service, plain Internet access had been
  requested.  There is no absolute requirement that this default
  service be allowed to all subscribers, but it is highly RECOMMENDED
  in order to avoid having normal subscribers employ operator-specific
  configuration values in order to get basic service.

  Some of the potential use-cases were listed earlier in this section.
  The general aim is better manageability of services and service
  provisioning from both operators and service providers point of view.
  However, it should be understood that there are potential deployment
  possibilities where selecting a certain service may restrict
  simultaneous access to other services from an user point of view.
  For example, services may be located in different administrative
  domains or external customer networks that practice excessive
  filtering of inbound and outbound traffic.

Spencer: I wasn't clear on who this understanding is directed to - it almost 
reads like you're warning users that bad things might happen if you use a 
specific service, but surely the user specifies the service because an 
operator requires this?


3.  Service Selection Extension

  At most one Service Selection extension MAY be included in any Mobile
  IPv4 Registration Request message.  It SHOULD be included at least in

Spencer: seems to be missing a qualifier: When a non-default service is 
selected, the Service Selection extension SHOULD be included ...?


Spencer: If this is qualified, could the SHOULD be a MUST?

Spencer: If it remains as SHOULD, what happens if the Service Selection 
extension is not included in the initial binding registration, but is 
included in subsequent binding registrations?


  the Registration Request message that is sent for the initial binding
  registration when the mobile node and the home agent do not have an
  existing binding.  The Service Selection extension MUST be placed in
  the Registration Request message as follows:

  o  When present the extension MUST appear after the MN-NAI extension,
 if the MN-NAI is also present in the message

  o  If the extension was added by the mobile node to a Registration
 Request it MUST appear prior any authentication-enabling
 extensions [RFC3344][RFC4721]

Spencer (editorial): s/prior/before/ or s/prior/prior to/

  o  In the event the foreign agent adds the Service Selection
 extension to a Registration Request, the extension MUST appear
 prior to any Foreign-Home authentication-enabling extensions
 [RFC3344]

4.1.  Mobile Node Considerations

  A mobile node or its proxy representative MAY include the Service
  Selection extension into any Registration Request message.  The
  Service Selection extension can be used with any mobile node
  identification method.  The extension is used to identify the service
  to be associated with the mobility session and SHOULD only be

Spencer: this seems to be more restrictive than previous text that allowed 
the extension to be included in non-initial registration request messages...


  included into the initial Registration Request message sent to a home
  agent.  If the mobile node wishes to change the selected service

[Gen-art] Gen-ART Last Call review of draft-dasgupta-ccamp-path-comp-analysis-02

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-dasgupta-ccamp-path-comp-analysis-02
Reviewer: Spencer Dawkins
Review Date: 2008-11-25
IETF LC End Date: 2008-12-14
IESG Telechat date: (not known)

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

Comments:

You can drop the 2119 boilerplate text (because you don't use it).

There are some nits (I noticed s/Virutal/Virtual/ and s/Eventhough/Even 
though/) for the editor. 



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

Re: [Gen-art] Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

[Spencer Dawkins]

Hi, Aaron,

(dropping the IETF discussion list from the cc: list)

I think we're good, except on this point:


2.2.  Action reject

 The reject action cancels the implicit keep and refuses delivery of
 a message.  The reason string is a UTF-8 [UTF-8] string specifying
 the reason for refusal.  Unlike the ereject action described above,
 this action would always favor preserving the exact text of the
 refusal reason.  Typically the reject action refuses delivery of a
 message by sending back an MDN to the alleged sender (see
 Section 2.2.1).  However implementations MAY refuse delivery over
 protocol (as detailed in Section 2.5), if and only if all of the

Spencer (clarity): refuse delivery over protocol reads roughly to  me. 
is there an adjective for protocol that might make this  sentence 
clearer? i'm not sure that over protocol is even required  - is it? if 
not, you could just delete the two words.


The phrase over protocol, or some equivalent, is crucial because the 
meaning of refuse is not as clear as anybody has hoped. I prefer to 
leave the text as it is.


The great thing about last call review comments is that you can do the 
right thing, but ... I may not have been clear, but what I was saying was 
that I don't know what refuse delivery over protocol actually refers to. 
Is this refuse delivery over SMTP protocol? That's all I was asking... I 
wasn't trying to talk you out of over protocol, just being a little 
clearer what you were saying.


Do the right thing, of course. :-)

Thanks,

Spencer 



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

[Gen-art] Gen-ART Review of draft-ietf-smime-sha2-09.txt

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-smime-sha2-09.txt
Reviewer: Spencer Dawkins
Review Date: 2008 11 14
IETF LC End Date: 2008-11-27
IESG Telechat date: (if known)

Summary: This document is ready for publication as a Proposed Standard.

Comments: My review comments from 03 have been addressed - thanks!

Spencer

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

[Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rsvp-proxy-proto-07.txt

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments 
you may receive. 


Document: draft-ietf-tsvwg-rsvp-proxy-proto-07.txt
Reviewer: Spencer Dawkins
Review Date: 2008-11-10
IETF LC End Date: 2008-11-14
IESG Telechat date: (not known) 


Summary: Ready for publication as Proposed Standard

Comments: none

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

[Gen-art] Gen-ART Last Call review of draft-ietf-ospf-lls-05.txt

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-ospf-lls-05.txt
Reviewer: Spencer Dawkins
Review Date: 2008-11-05
IETF LC End Date: 2008-11-10

Summary: This document is on the right track for publication as Proposed 
Standard. I have a couple of 2119 questions.


Comments:

  The 16-bit LLS Data Length field contains the length (in 32-bit
  words) of the LLS block including the header and payload.
  Implementations MUST NOT use the Length field in the IP packet header
  to determine the length of the LLS data block.

Spencer: I'm not sure this is a 2119 MUST NOT - aren't you just saying that 
if you try it, you'll fail?


  The CA-TLV MUST only appear once in the the LLS block.  Also, when
  present, this TLV SHOULD be the last TLV in the LLS block.

Spencer: Why SHOULD and not MUST? At a minimum, I would expect to see some 
description of what should happen if CA-TLV is NOT the last TLV in the LLS 
block - and if the expectation is that processing continues, I'm not sure 
what this sentence means... 



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

[Gen-art] Gen-ART Last Call review of draft-ietf-emu-eap-gpsk-15

[Spencer Dawkins]

Document: draft-ietf-emu-eap-gpsk-15
Reviewer: Spencer Dawkins
Review Date:  2008-10-24
IETF LC End Date: 2008-11-03
IESG Telechat date: (not known)

Summary: Ready for publication as Proposed Standard

Comments: There are a small number of nits I found (tagged as Spencer 
(clarity):) for your review... I'll send them separately...


Spencer 



___
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-sip-xcapevent-03

[Spencer Dawkins]

Hi, Russ,

04 is ready for publication as Proposed Standard.

Thanks,

Spencer



Spencer:

It looks like all of your comments were accepted.

The -04 version has been posted.  It is on the agenda for Thursday.  Can 
you take a quick look and make sure that the document is Gen-ART ready.


Russ



Subject: Re: Gen-ART Review of draft-ietf-sip-xcapevent-03
From: Jari Urpalainen [EMAIL PROTECTED]
To: ext Spencer Dawkins [EMAIL PROTECTED]
Date: Mon, 22 Sep 2008 14:55:16 +0300


Thanks Spencer, comments in-line

On Fri, 2008-09-19 at 14:16 -0500, ext Spencer Dawkins 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 resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-sip-xcapevent-03
 Reviewer: Spencer Dawkins
 Review Date: 2008-09-19
 IETF LC End Date: 2008-10-02
 IESG Telechat date:  not known

 Summary: this document is on the right track for publication as a 
 Proposed

 Standard but a few changes are required before publication. The
document has
 a number of 2119 issues. There are a few areas where I thought I 
 understood

 the text but had to guess at its meaning. I flagged these as clarity
 comments unless I thought they were disguising a technical issue.

 Comments: clarity comments included here are for the editor's 
 convenience

 and are not actually part of the Gen-ART review.

 Abstract

This document describes an xcap-diff SIP event package for the SIP
Event Notification Framework, with the aid of which clients can

 Spencer (clarity): s/with the aid of which clients can/which
clients can use
 to/

ok

receive notifications of the partial changes of Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) resources.  The
initial synchronization and document updates are based on using the
XCAP-Diff format.

 Spencer (technical): Is this are based on the XCAP-Diff format? If 
 not, I

 don't understand.

right.

 1.  Introduction

While the XCAP protocol allows several authorized users or devices 
 to

modify the same XML document, XCAP does not provide an effective
synchronization mechanism (except polling) to keep resources

 Spencer (clarity): s/except polling/beyond polling/

ok

equivalent between a server and a client.  This memo defines an
xcap-diff event package that, together with the SIP event
notification framework [RFC3265] and the XCAP-diff format
[I-D.ietf-simple-xcap-diff], allows a user to subscribe to changes 
 in
an XML document, and to receive notifications whenever a change in 
 an

XML document takes place.

There are three basic features that this event package enables with
the XCAP-Diff [I-D.ietf-simple-xcap-diff] change notification 
 format.


Firstly, it can list a collection [RFC4918] content of an XCAP

 Spencer (clarity): a collection content reads oddly, unless this is a
 technical term.

perhaps it was programmer thinking... changed to Firstly, it can list
the URI references of XCAP documents from a collection [RFC 4918]
located on an XCAP server.

server, which means in practice listing the URI references of XCAP
documents from a collection.  This is important when a subscriber is
doing an initial synchronization or a comparison of existing server
resources to the locally cached XCAP documents, for example.  The
version-history of document comparisons are based on the strong
entity tag (ETag) values of XCAP documents which are also indicated
with the XCAP-Diff format.

Secondly, this event package can signal whenever a change is
happening in those resources.  The changes can be reported with 
 three

ways.  The simplest model is that only document creations, updates
and removals are indicated.  The actual contents of those documents
are not shown and the subscriber uses the (HTTP) RFC 2616 [RFC2616]

 Spencer (clarity): s/shown/included in the notification/?
right.


protocol for a retrieval of document contents.  The two more complex
modes allow the changes of documents to be indicated straightaway
with the XML-Patch-Ops [I-D.ietf-simple-xml-patch-ops] semantics
inside the XCAP-Diff [I-D.ietf-simple-xcap-diff] format.  A client
can then apply a conditional patch to locally cached documents based
on the strong ETag values of documents.  The most complex model
produces the smallest documents but it doesn't necessarily show the
full HTTP version-history information unlike the other, but 
 typically


 Spencer (clarity): s/but//

ok

more verbose one.

Lastly, XML element or attribute contents (XCAP components) can be
received in-band, that is straight within the XCAP-Diff
notification format.  For example, an XCAP element content can be
requested and indicated without the need

[Gen-art] Gen-ART Last Call review of draft-ietf-idr-as-representation-01.txt

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-idr-as-representation-01.txt
Reviewer: Spencer Dawkins
Review Date: 2008 10 17
IETF LC End Date: 2008 10 20
IESG Telechat date: 2008 10 23

Summary: This document is ready for publication as a Proposed Standard.

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

Re: [Gen-art] Late Last Call Gen-ART review of draft-ietf-avt-rfc4749-dtx-update-01

[Spencer Dawkins]

Hi, Aurelien,

I think we're good on almost everything in your response.

On the SHOULD/MUST below, it could very well be OK to have this as SHOULD, 
but we've been asking for some indication of reasons why SHOULDs might not 
be implemented - which could be as simple as there is a lot of deployed 
code that didn't implement this, because it was a SHOULD in RFC 3551.


If you leave this as SHOULD, you might want to say something about the 
effect on receivers, since conformant sender implementations aren't doing 
something that the spec assumed they would be doing. In this case, you're 
saying that the receiver can't look at the M-bit to identify the beginning 
of a talkspurt, right?


If you get any other feedback about SHOULD/MUST here, please take that into 
account, of course...


Thanks,

Spencer

- Original Message - 
From: [EMAIL PROTECTED]

To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; gen-art@ietf.org; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]

Sent: Tuesday, September 23, 2008 4:20 AM
Subject: RE: Late Last Call Gen-ART review of 
draft-ietf-avt-rfc4749-dtx-update-01



Hi

Thank you for the review.
Below some answers.

Aurelien


3.  RTP Header Usage

   If DTX is used, the first packet of a talkspurt, that is, the first
   packet after a silence period during which packets have not been
   transmitted contiguously, SHOULD be distinguished by setting the M

Spencer (review): why not MUST here?



[AS] It is the wording from RFC 3551 (4.1).
It could be a MUST, but I saw no reason to be stronger than the RTP spec. 



___
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-forces-mib-07

[Spencer Dawkins]

Hi, Robert,

I would report this as ready for publication as Proposed Standard...

Thanks,

Spencer

- Original Message - 
From: Robert Haas
To: Spencer Dawkins
Cc: Patrick Droz ; General Area Review Team ; Jamal Hadi Salim ; 
[EMAIL PROTECTED] ; Ross Callon
Sent: Tuesday, September 09, 2008 8:47 AM
Subject: Re: Gen-ART Review of draft-ietf-forces-mib-07



Hi Spencer,
I released a new version of the draft to change to ZeroBasedCounters and 
took the opportunity to rename the counters as you suggested. Now they are 
called *Oper* instead of *Other*:
http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-09.txt
Regards,
-Robert

Spencer Dawkins [EMAIL PROTECTED] wrote on 09/03/2008 05:02:54 
PM:

 [image removed]

 Re: Gen-ART Review of draft-ietf-forces-mib-07

 Spencer Dawkins

 to:

 Robert Haas

 09/03/2008 05:06 PM

 Cc:

 Patrick Droz, General Area Review Team, Jamal Hadi Salim,
 ietf, Ross Callon

 Hi, Robert,

 Thanks for the quick response on all the comments -  to be explicit,
 version 8 addresses all my comments, except for one question  (below).

 It actually could be OK to retain the OtherMsg name  and definition,
 if there is a reason to do so (one reason might be deployed
 systems use this name and definition). What I was saying was that
 it violates  the Principle of Least Astonishment - you could also
 clearly define 3 as 2,  but implementers would still think 3
 was 3 when scanning  quickly.

 :-)

 This is an IETF Last Call review comment, so other  reviewers can
 tell you Spencer is worried about nothing, and Gen-ART comments
 are never blocking unless an AD includes them in a DISCUSS.

 I'll trust that you guys will do the right thing,  which might or
 might not be to make a change.

 Thanks for hearing me out.

 Spencer
 o  Number of other ForCES  messages sent from the CE
 (forcesAssociationOtherMsgSent) and received by the CE
 (forcesAssociationOtherMsgReceived) since the association 
  entered
the UP state.  Only messages other  than Heartbeat, Association
Setup, Association  Setup Response, and Association Teardown are
 counted.
 
  Spencer (technical): I think I know what you're  saying here, but
 you're not
  counting other messages (because you  exclude some of the
 other messages.
  The point is that you didn't  get into the table with Association
  Setup/Association Setup Response,  and you leave the table
 immediately after
  Association Teardown, so  you don't have to count these messages, isn't 
  it?
  :-(

 I agree, but I'd rather keep this explicit. As for  OtherMsg vs
 OperationalMsg: I'd rather keep it as is, given that we define
 what are these other messages. 

___
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-forces-mib-07

[Spencer Dawkins]

Hi, Robert,

Thanks for the quick response on all the comments - to be explicit, version 8 
addresses all my comments, except for one question (below).

It actually could be OK to retain the OtherMsg name and definition, if there is 
a reason to do so (one reason might be deployed systems use this name and 
definition). What I was saying was that it violates the Principle of Least 
Astonishment - you could also clearly define 3 as 2, but implementers would 
still think 3 was 3 when scanning quickly.

:-)

This is an IETF Last Call review comment, so other reviewers can tell you 
Spencer is worried about nothing, and Gen-ART comments are never blocking 
unless an AD includes them in a DISCUSS.

I'll trust that you guys will do the right thing, which might or might not be 
to make a change.

Thanks for hearing me out. 

Spencer
  o  Number of other ForCES messages sent from the CE
 (forcesAssociationOtherMsgSent) and received by the CE
 (forcesAssociationOtherMsgReceived) since the association entered
 the UP state.  Only messages other than Heartbeat, Association
 Setup, Association Setup Response, and Association Teardown are
 counted.
   
   Spencer (technical): I think I know what you're saying here, but you're not 
   counting other messages (because you exclude some of the other 
messages. 
   The point is that you didn't get into the table with Association 
   Setup/Association Setup Response, and you leave the table immediately after 
   Association Teardown, so you don't have to count these messages, isn't it? 
   :-( 

  I agree, but I'd rather keep this explicit. As for OtherMsg vs 
OperationalMsg: I'd rather keep it as is, given that we define what are these 
other messages. ___
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-forces-mib-07

[Spencer Dawkins]

OK...

Summary: This document is very close to ready for publication as a 
Proposed
Standard. I have two technical comments below, but both are minor issues
that could resolved in AUTH48 if you think they have merit.

 An aside: The purpose of AUTH48 state is not (should not be) to resolve 
 even minor issues.  Ideally, no issues should arise in AUTH48, but the 
 world is not a perfect place.  But let's not get in the habit of sweeping 
 minor changes to the every end of the publication process.  The revision 
 process is pretty cheap.

Agreed. I've been seeing a lot of Gen-ART reviewers, including myself, who 
say could be resolved in AUTH48 as a unit of size, but I can see how 
reasonable people assume that it's a suggestion of tactics :-)

Thanks for the opportunity to break old habits when they become even less 
reasonable.

Spencer 

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

[Gen-art] Gen-ART Review of draft-ietf-forces-mib-07

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-forces-mib-07
Reviewer: Spencer Dawkins
Review Date: 2008-09-01
IETF LC End Date: 2008-09-08
IESG Telechat date: (not known)

Summary: This document is very close to ready for publication as a Proposed 
Standard. I have two technical comments below, but both are minor issues 
that could resolved in AUTH48 if you think they have merit.

Comments:

OBTW, idnits 2.08.11 runs cleanly (one spurious warning about [RFC]).

3.  Introduction

   More specifically, the information in the ForCES MIB module relative
   to associations that are up includes:

Spencer (clarity): I'd suggest s/associations/associations between Control 
Elements and Forwarding Elements/, unless that's wrong (and if it is, I'd 
still suggest between X and Y, whatever X and Y are). Later uses of 
association would be fine, of course, this is just providing initial 
context.

Spencer (clarity): I'd suggest s/up/in the UP state/, or at least 
all-caps-ing UP so it looks like a state.


4.  ForCES MIB Overview

   The MIB module contains the latest ForCES protocol version supported
   by the CE (forcesLatestProtocolVersionSupported).  Note that the CE
   must also allow interaction with FEs supporting earlier versions.

Spencer (clarity): I'd suggest s/CE/Control Element (CE)/ (and same for FE, 
ID, etc.) The reader can figure stuff like this out, but spelling it out for 
the reader is just too easy.

   o  Number of other ForCES messages sent from the CE
  (forcesAssociationOtherMsgSent) and received by the CE
  (forcesAssociationOtherMsgReceived) since the association entered
  the UP state.  Only messages other than Heartbeat, Association
  Setup, Association Setup Response, and Association Teardown are
  counted.

Spencer (technical): I think I know what you're saying here, but you're not 
counting other messages (because you exclude some of the other messages. 
The point is that you didn't get into the table with Association 
Setup/Association Setup Response, and you leave the table immediately after 
Association Teardown, so you don't have to count these messages, isn't it? 
:-(

If it's not too late to change this to OperationalMsg or something 
similar, I'd suggest that, for clarity. If it is too late to change this ...

   Finally, the MIB module defines the following notifications:

   o  Whenever an association enters the UP state, a notification
  (forcesAssociationEntryUp) is issued containing the version of the
  ForCES protocol running.  Note that as CE ID and FE ID are
  indexes, they appear in the OID of the ForCES-protocol running-

Spencer (technical): this is intended as a question, because I don't know 
MIB practices, but it looks to me like CE ID and FE ID are concatenated into 
ONE index, so they aren't indexes - right? I'm looking at the INDEX for 
ForcesAssociationEntry.

The rest of the document is pretty clear about this, so I'd suggest CE ID 
and FE ID are concatenated to form the table index, or something similar, 
unless I don't understand (it happens).

  version object.  Optionally, a notification
  (forcesAssociationEntryUpStats) can instead be issued with all
  associated information for this association, except
  forcesAssociationTimeDown. 

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

Re: [Gen-art] Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

[Spencer Dawkins]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sieve-refuse-reject-07
Reviewer: Spencer Dawkins
Review Date: 2008-08-10
IETF LC End Date: 2008-08-10 (oops!)
IESG Telechat date: N/A

Summary: Almost ready for publication as a Proposed Standard. I have some 
clarity questions below, and two technical questions involving 2119 language 
...


Comments:

Abstract

  This memo updates the definition of the Sieve mail filtering language
  reject extension, originally defined in RFC 3028.

  A Joe-job is a spam run forged to appear as though it came from an

Spencer (clarity): I'm OK with the use of joe-job (or, at a minimum, I'm 
OK with what you guys say it is), but there's not a clear statement in the 
abstract that the update to 3028 is in response to the joe-job practice. 
I'd suggest something like ... originally defined in RFC 3028, because the 
definition in RFC 3028 did not allow messages to be refused during the STMP 
transaction, and experience has shown this to be valuable in response to 
joe-jobs.


  innocent party, who is then generally flooded by automated bounces,
  Message Disposition Notifications (MDNs), and personal messages with
  complaints.  The original Sieve reject action defined in RFC 3028
  required use of MDNs for rejecting messages, thus contributing to the
  flood of Joe-job spam to victims of Joe-jobs.

  This memo updates the definition of the reject action to allow
  messages to be refused during the SMTP transaction, and defines the
  ereject action to require messages to be refused during the SMTP
  transaction, if possible.

  The ereject action is intended to replace the reject action
  wherever possible.

Spencer (clarity): a LOT later in the document, the following text appears: 
The ereject action is similar to reject, but will always favor protocol 
level message rejection. That's a really helpful summary - I'd like to see 
something like that much earlier in the document, maybe here.


1.  Introduction

  The Sieve mail filtering language [SIEVEBIS], as originally defined
  in RFC 3028 [SIEVE], specified that the reject action shall discard
  a message and send a Message Disposition Notification [MDN] to the
  envelope sender along with an explanatory message.  RFC 5228
  [SIEVEBIS] does not define any reject action, hence the purpose of
  this document.

Spencer (clarity): hmm. I'm almost sure that The Sieve mail filtering 
language [SIEVEBIS] was NOT originally defined in RFC 3028 [SIEVE]... :-) 
If you drop the first [SIEVEBIS] reference in this sentence, I think it's 
correct.


Spencer (clarity): It's not particularly easy for me to understand this 
paragraph, given that SIEVEBIS is used as the reference for RFC 5228 in 
the last sentence. I might suggest the updated Sieve mail filtering 
language [SIEVEBIS] does not define any reject action ...


  This document updates the definition of the reject action to permit
  refusal of the message during the SMTP transaction, if possible, and
  defines a new ereject action to require refusal of the message
  during the SMTP transaction, if possible.

Spencer (clarity): a LOT later in the document, the following text appears: 
The ereject action is similar to reject, but will always favor protocol 
level message rejection. That's a really helpful summary - I'd like to see 
something like that much earlier in the document, maybe here.


  Implementations are further encouraged to use spam-detection systems
  to determine the level of risk associated with sending an MDN, and
  this document allows implementations to silently drop the MDN if the
  rejected message is deemed to be likely spam.

  Further discussion highlighting the risks of generating MDNs and the
  benefits of protocol-level refusal can be found in [Joe-DoS].

2.1.1.  Rejecting a message at the SMTP/LMTP protocol level

  Sieve implementations that are able to reject messages at the SMTP/
  LMTP level MUST do so and SHOULD use the 550 response code.  Note

Spencer (technical): since rejection is a MUST, I'd expect to see guidance 
about why using 550 might not be the right thing to do (why is this a 
SHOULD?). There's some text at the bottom of 2.5 about using 4XX first, but 
it should appear here, I think.


  that if a message is arriving over SMTP and has multiple recipients,
  some of whom have accepted the message, Section 2.1.2 defines how to
  reject such a message.

2.1.2.  Rejecting a message by sending a DSN

  An implementation may receive a message via SMTP that has more than
  one RCPT TO that has been accepted by the server, and at least one
  but not all of them are refusing delivery (whether the refusal is
  caused by a Sieve ereject action or for some other reason).  In
  this case, the server MUST