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
> >> should

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)" 
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) 
*Cc:* Francesca Palombini ; 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) 
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 
*Cc:* MORTON, ALFRED C (AL) ; 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) 
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 
> *Cc:* MORTON, ALFRED C (AL) ; 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.
>
> 9.2.1.  Bid Down Attac

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] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05

[Spencer Dawkins at IETF]

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
___
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  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
>>> .
>>>
>>> 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  wrote:


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

.

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

Document: draft-ietf-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] timing of reviews

[Spencer Dawkins]

On 5/24/2013 8:14 AM, Mary Barnes wrote:


Yes - or scope limited (only some WGs or areas at the beginning).

[MB] Absolutely, it needs to have a limited scope initially.  As Brian
said, the concept is not new, it's just that few took advantage of it.


Mary is the best person to comment on the time period when I was a 
Gen-ART reviewer, but I do remember a few working group chairs asking 
for early reviews (which were granted in every case I heard about). I'm 
not sure how many chairs knew they could ask for early reviews, and of 
course, I don't know why they wanted early reviews. But it's fair to say 
that nobody discouraged early reviews, at least not where I could hear that.


To all the reviewers:

Thank all of you for your review work. I dropped off Gen-ART when I 
joined the IAB, but still read your reviews (and am now reading them 
more closely :-)


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 con

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

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

[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.2

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 ;  
  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  
  To:Avshalom Houri/Haifa/i...@ibmil 
  Cc:General Area Review Team , "" 

  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

[Gen-art] Gen-ART review of draft-ietf-isms-dtls-tm-10

[Spencer Dawkins]

I had reviewed -09 at IETF Last Call time, all my questions have been 
answered in -10, and I didn't see any issues resulting from new text. Ready 
for publication as a Proposed Standard.


Spencer

- Original Message - 
From: "Spencer Dawkins" 

To: 
Cc: "General Area Review Team" ; 


Sent: Wednesday, April 14, 2010 8:10 AM
Subject: [Gen-art] Gen-ART review of draft-ietf-isms-dtls-tm-09



Document: draft-ietf-isms-dtls-tm-09
Reviewer: Spencer Dawkins
Review Date: 2010-04-14 (epic fail on getting review done - sorry!)
Last Call ends: 2010-04-02
IESG Telechat date: 2010-05-06

Summary: This specification is almost ready for publication as a Proposed 
Standard. I do have some (late Last Call) questions, almost all of which 
are around either 2119 language or clarity.


Thanks,

Spencer


3.  How the TLSTM fits into the Transport Subsystem


  The diagram below depicts where the TLS Transport Model fits into the
  architecture described in RFC3411 and the Transport Subsystem:

Spencer (clarity): the words "TLS Transport Model" appears nowhere in the 
following figure that I could see. I'm pretty sure I know what you're 
talking about (the box labeled "(D)TLS TM"), but I'm guessing. My 
suggestion is to rephrase so that the reader can match the previous 
sentence and the figure - perhaps "... the TLS Transport Model, shown as 
(D)TLS TM, fits ..."



  +--+
  |Network   |
  +--+
 ^   ^  ^
 |   |  |
 v   v  v
  +---+
  | +--+  |
  | |  Transport Subsystem |  ++  |
  | | +-+ +-+ +---+ +---+  |  ||  |
  | | | UDP | | SSH | |(D)TLS |. . .| other |<--->| Cache  |  |
  | | | | | TM  | | TM| |   |  |  ||  |
  | | +-+ +-+ +---+ +---+  |  ++  |
  | +--+ ^|
  |  ^   ||
  |  |   ||
  | Dispatcher   v   ||
  | +--+ +-+  ++ ||
  | | Transport| | Message Processing  |  | Security   | ||
  | | Dispatch | | Subsystem   |  | Subsystem  | ||
  | |  | | ++  |  | ++ | ||
  | |  | |  +->| v1MP   |<--->| | USM| | ||
  | |  | |  |  ++  |  | ++ | ||
  | |  | |  |  ++  |  | ++ | ||
  | |  | |  +->| v2cMP  |<--->| | Transport  | | ||
  | | Message  | |  |  ++  |  | | Security   |<--+|
  | | Dispatch<>|  ++  |  | | Model  | |  |
  | |  | |  +->| v3MP   |<--->| ++ |  |
  | |  | |  |  ++  |  | ++ |  |
  | | PDU Dispatch | |  |  ++  |  | | Other  | |  |
  | +--+ |  +->| otherMP|<--->| | Model(s)   | |  |
  |  ^   | ++  |  | ++ |  |
  |  |   +-+  ++  |
  |  v|
  |  +---+-+---+  |
  |  ^ ^   ^  |
  |  | |   |  |
  |  v v   v  |
  | +-+   +-+   +--+  +-+ |
  | |   COMMAND   |   | ACCESS  |   | NOTIFICATION |  |PROXY| |
  | |  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  | |
  | | application |   | |   | applications |  | application | |
  | +-+   +-+   +--+  +-+ |
  |  ^ ^  |
  |  | |  |
  |  v v  |
  | +--+  |
  | | MIB instrumentation  |  SNMP entity |
  +---+

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

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

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 chan

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

[Spencer Dawkins]

Document: draft-ietf-isms-dtls-tm-09
Reviewer: Spencer Dawkins
Review Date: 2010-04-14 (epic fail on getting review done - sorry!)
Last Call ends: 2010-04-02
IESG Telechat date: 2010-05-06

Summary: This specification is almost ready for publication as a Proposed 
Standard. I do have some (late Last Call) questions, almost all of which are 
around either 2119 language or clarity.


Thanks,

Spencer


3.  How the TLSTM fits into the Transport Subsystem


  The diagram below depicts where the TLS Transport Model fits into the
  architecture described in RFC3411 and the Transport Subsystem:

Spencer (clarity): the words "TLS Transport Model" appears nowhere in the 
following figure that I could see. I'm pretty sure I know what you're 
talking about (the box labeled "(D)TLS TM"), but I'm guessing. My suggestion 
is to rephrase so that the reader can match the previous sentence and the 
figure - perhaps "... the TLS Transport Model, shown as (D)TLS TM, fits ..."



  +--+
  |Network   |
  +--+
 ^   ^  ^
 |   |  |
 v   v  v
  +---+
  | +--+  |
  | |  Transport Subsystem |  ++  |
  | | +-+ +-+ +---+ +---+  |  ||  |
  | | | UDP | | SSH | |(D)TLS |. . .| other |<--->| Cache  |  |
  | | | | | TM  | | TM| |   |  |  ||  |
  | | +-+ +-+ +---+ +---+  |  ++  |
  | +--+ ^|
  |  ^   ||
  |  |   ||
  | Dispatcher   v   ||
  | +--+ +-+  ++ ||
  | | Transport| | Message Processing  |  | Security   | ||
  | | Dispatch | | Subsystem   |  | Subsystem  | ||
  | |  | | ++  |  | ++ | ||
  | |  | |  +->| v1MP   |<--->| | USM| | ||
  | |  | |  |  ++  |  | ++ | ||
  | |  | |  |  ++  |  | ++ | ||
  | |  | |  +->| v2cMP  |<--->| | Transport  | | ||
  | | Message  | |  |  ++  |  | | Security   |<--+|
  | | Dispatch<>|  ++  |  | | Model  | |  |
  | |  | |  +->| v3MP   |<--->| ++ |  |
  | |  | |  |  ++  |  | ++ |  |
  | | PDU Dispatch | |  |  ++  |  | | Other  | |  |
  | +--+ |  +->| otherMP|<--->| | Model(s)   | |  |
  |  ^   | ++  |  | ++ |  |
  |  |   +-+  ++  |
  |  v|
  |  +---+-+---+  |
  |  ^ ^   ^  |
  |  | |   |  |
  |  v v   v  |
  | +-+   +-+   +--+  +-+ |
  | |   COMMAND   |   | ACCESS  |   | NOTIFICATION |  |PROXY| |
  | |  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  | |
  | | application |   | |   | applications |  | application | |
  | +-+   +-+   +--+  +-+ |
  |  ^ ^  |
  |  | |  |
  |  v v  |
  | +--+  |
  | | MIB instrumentation  |  SNMP entity |
  +---+

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. Bu

[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

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

[Spencer Dawkins]

Hi, Tero,

Thanks for the quick response (so I can remember what I was thinking :-)...

Deleting everything that you and I are OK with, I'm looking at these 
questions.


Thanks,

Spencer


   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...


That is why you need centralized policy management... If you have that
then changing the policy in the whole organization should be quite
easy (or at least possible)...


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.



   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 know
   the same protocols as a deep inspection device, an unknown protocol
   should not be handled any differently than a cleartext instance of an
   unknown protocol if possible.

Spencer (minor): Are you saying that it might not be possible to handle 
the
two things the same way? I don't understand why. Prohibited by policy, 
sure,

and there may be other reasons to treat them differently, but I don't
understand why this is "should" ...


That is not "SHOULD" in RFC2119 sense (this document does not specify
protocol so there is no need for 2119 language).

The text is just trying to say that in normal case for deep inspection
engine it does not matter whether the unknown protocol was with
ESP-NULL or without it. There is no real reason to change policy based
on that fact, so both of them can/will/should receive same handling.


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.



8.3.1.  TCP checks

   The most obvious field, TCP checksum, might not be usable, as it is
   possible that the packet has already transited a NAT box, thus the IP
   numbers used in the checksum are wrong, thus the checksum is wrong.

Spencer (minor): this isn't something I'm smart about, but would you 
expect

to see NAT boxes changing IP addresses and not fixing-up transport
checksums? That's begging for the receiver of these packets to discard 
them

based on checksum mismatches, isn't it? I know a NAT could be doing
anything, but that that seems short-sighted.


No, I do expect NAT boxes to fix checksums IF they see them. In
transport mode ESP-NULL case the checksum is INSIDE the ESP, thus NAT
boxes will not see it, and cannot fix it.

In the transport mode NAT-T in IPsec, there is special processing
rules for that in the responder, where they will fix the (decrypted)
checksums before giving the packet forward (See 3.1.2 of RFC3948).

So as NAT boxes assume that when they see ESP it means the packet is
encrypted, they not even try to fix the checksum and when the deep
engine device gets the NATed packet in the checksum is incorrect
because of that.


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"



The deep inspection engine could try to find out the NAT mapping and
take that in to account when calculating the checksum, but it gets
quite complicated thus I do not think it is worth while to do that
here.


   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.

Spencer (minor): is this true when you have a transmit window size 
greater

[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

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

[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
  

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  is false and  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  is false and  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  is true and  is defined as "udp" then the
 algorithm MUST stop with an error.
  o  If  is true and  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  is true and  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  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, 
  for the Name, "turn" for the Service if  is false or
  "turns" for the Service if  is true.  The sam

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" 

To: "Spencer Dawkins" 
Cc: ; ; "General 
Area Review Team" 

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  is false and  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  is false and  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  is true and  is defined as "udp" then the
 algorithm MUST stop with an error.
  o  If  is true and  is defined as "tcp" but the
 list o

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

[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-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  is false and  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  is false and  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  is true and  is defined as "udp" then the
 algorithm MUST stop with an error.
  o  If  is true and  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  is true and  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  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, 
  for the Name, "turn" for the Service if  is false or
  "turns" for the Service if  is true.  The same transport
  that was used to generate a list of tuples is used with each of
  this tuples for contacting the TURN server.  The SRV algorithm

Spencer (nit): s/this/these/

  recommends doing an A query if 

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" 

To: "Alexey Melnikov" 
Cc: "General Area Review Team" ; 
; ; "Nicolas Williams" 


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



Alexey Melnikov  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" 

To: 
Cc: "General Area Review Team" 
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", &

[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-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

Re: [Gen-art] Last Call: draft-ietf-pkix-attr-cert-mime-type (Theapplication/pkix-attr-cert Content Type for AttributeCertificates) to Informational RFC

[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-pkix-attr-cert-mime-type-02
Reviewer: Spencer Dawkins
Review Date: 2009-11-30
IETF LC End Date: 2009-11-29
IESG Telechat date: (Not known)

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

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" 

To: "Spencer Dawkins" 
Cc: 
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
 

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" 

To: 
Cc: "General Area Review Team" 
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

[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
  negot

[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] 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-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 com

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: 

To: ; 
Cc: ; 
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-l3vpn-2547bis-mcast-bgp-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-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.


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)

  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)

  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:


"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 of the route SHOULD
  be set to the same IP address as the one carried in the Originating
  Router's IP Address field.

Spencer (minor): I'm not sure why this is a SHOULD and not a MUST, but if it 
is a SHOULD, I'd expect to see some guidance about what happens if it's not 
observed - does the mechanism still work?


10. Non-congruent Unicast and Multicast Connectivity

  It is possible to deploy MVPN such the multicast routing and the

Spencer (minor): is this "such that"? This is probably a nit but I'm having 
to guess at the parsing.


  unicast routing are "non-congruent". For instance, the CEs may be
  distributing to the PEs a special set of unicast routes that are to
  be used exclusively for the purpose of upstream multicast hop
  selection, and not used for unicast routing at all. (For example,
  when BGP is the CE-PE unicast routing protocol, the CEs may be using
  SAFI 2 ("Network Layer Reachability Information used for multicast
  forwarding" [IANA-SAFI]), and either IPv4 or IPv6 AFI to distribute a
  special set of routes that are to be used for, and only for, upstream
  multicast hop selection.) In such a situation, we will speak of the
  MVPN as having

Re: [Gen-art] [PCN] Fwd: Gen-ART Review of draft-ietf-pcn-baseline-encoding-05

[Spencer Dawkins]

Hi, Steve,

Thanks for the quick response.



 DSCPs.  Guidelines for mixing traffic-types within a PCN-domain
 are given in [I-D.ietf-pcn-marking-behaviour].

  o  Any packet that is not-PCN but which shares the same Diffserv
 codepoint as PCN-enabled traffic MUST have the ECN field of its
 outermost IP header equal to 00.

Spencer (minor): this is the only point in the specification (that I
can
find) that makes reference to the "outermost IP header". I'm not sure
whether to suggest s/outermost// here or to ask that a statement be
added
earlier in the document to clearly state that PCN encoding only
protects
inelastic traffic when it's used for the outermost IP header, but the
current text seems to call attention to this in a way that makes the
reader
wonder what is special about THIS requirement that isn't true of the
other
requirements listed.


I'm sorry, but I'm having a hard time following this comment.  Could you
please clarify?


I'm probably not saying this well - my question is basically why this 
requirement calls out "ECN field of its outermost IP header", when other 
requirements that mention ECN field do not. If there's a reason why 
s/outermost// in this case would be wrong, I don't know what it is, and 
that's what worries me - should the other requirements ALSO say "outermost"?


I'm not asking for this change, just trying to understand.

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-pcn-baseline-encoding-05

[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-pcn-baseline-encoding-05
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-09-03
Review Date: 2009-08-21
IESG Telechat date: (not known)

Summary: this specification is almost ready for publication as a Proposed 
Standard. I have one minor question below (flagged as "Spencer (minor)"), 
along with some editorial suggestions to be considered when this document is 
edited (either in the working group or by the RFC Editor).


Abstract

  The objective of Pre-Congestion Notification (PCN) is to protect the
  quality of service (QoS) of inelastic flows within a Diffserv domain.

Spencer (clarity): I'm not sure what the relationship between a Diffserv 
domain and a PCN-domain is - this couuld be clearer, especially in an 
Abstract. I note that RFC 5559 doesn't use the term PCN-domain in its 
Abstract ... I can guess, but I'm just guessing.


  The overall rate of the PCN-traffic is metered on every link in the
  PCN-domain, and PCN-packets are appropriately marked when certain
  configured rates are exceeded.  The level of marking allows the
  boundary nodes to make decisions about whether to admit or block a
  new flow request, and (in abnormal circumstances) whether to
  terminate some of the existing flows, thereby protecting the QoS of
  previously admitted flows.  This document specifies how such marks
  are to be encoded into the IP header by re-using the Explicit
  Congestion Notification (ECN) codepoints within this controlled
  domain.  The baseline encoding described here provides for only two
  PCN encoding states, Not-marked and PCN-marked.

4.  Encoding two PCN States in IP

  The following rules apply to all PCN traffic:

  o  PCN-traffic MUST be marked with a PCN-compatible Diffserv
 Codepoint.  To conserve DSCPs, Diffserv Codepoints SHOULD be
 chosen that are already defined for use with admission controlled
 traffic.  Appendix A.1 gives guidance to implementiors on suitable

Spencer (clarity): s/implementiors/implementers/?

 DSCPs.  Guidelines for mixing traffic-types within a PCN-domain
 are given in [I-D.ietf-pcn-marking-behaviour].

  o  Any packet that is not-PCN but which shares the same Diffserv
 codepoint as PCN-enabled traffic MUST have the ECN field of its
 outermost IP header equal to 00.

Spencer (minor): this is the only point in the specification (that I can 
find) that makes reference to the "outermost IP header". I'm not sure 
whether to suggest s/outermost// here or to ask that a statement be added 
earlier in the document to clearly state that PCN encoding only protects 
inelastic traffic when it's used for the outermost IP header, but the 
current text seems to call attention to this in a way that makes the reader 
wonder what is special about THIS requirement that isn't true of the other 
requirements listed.


4.3.  PCN-Compatible Diffserv Codepoints

  Enabling PCN marking behaviour for a specific DSCP disables any other
  marking behaviour (e.g. enabling PCN disables the default ECN marking
  behaviour introduced in [RFC3168]).  All traffic metering and marking

Spencer (clarity): here, and in Section 6, the text uses "disables" to 
describe the relationship between PCN and ECN. If I understand the point, 
the domain is substituting one behavior for another. I might suggest 
"replaces" to describe the relationship in both locations.


  behaviours are discussed in [I-D.ietf-pcn-marking-behaviour].  This
  ensures compliance with the BCP guidance set out in [RFC4774].

4.3.1.  Co-existence of PCN and not-PCN traffic

  The scarcity of pool 1 DSCPs coupled with the fact that PCN is
  envisaged as a marking behaviour that could be applied to a number of
  different DSCPs makes it essential that we provide a not-PCN state.
  As stated above (and expanded in Appendix A.1) the aim is for PCN to
  re-use existing DSCPs.  Because PCN re-defines the meaning of the ECN

Spencer (clarity): here, the text uses "re-defines", which I like better 
than "disables", but if you go for "replaces" previously and in section 6, 
you might want to use the same wording here.


  field for such DSCPs it is important to allow an operator to still
  use the DSCP for traffic that isn't PCN-enabled.  This is achieved by
  providing a not-PCN state within the encoding scheme.

A.1.  Choice of Suitable DSCPs

  The PCN Working Group chose not to define a single DSCP for use with
  PCN for several reasons.  Firstly the PCN mechanism is applicable to
  a variety of different traffic classes.  Secondly standards track
  DSCPs are in increasingly short supply.  Thirdly 

[Gen-art] Gen-ART Review of draft-ietf-dime-pmip6-03.txt

[Spencer Dawkins]

Version 03 resolves all of the comments I had on -02. 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 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.

[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-vcarddav-webdav-mkcol-05

[Spencer Dawkins]

Hi, Cyrus,

This works for me.

Thanks for getting back to me quickly, and I hope you enjoyed your vacation.

Spencer



Hi Spencer,
Thanks for your review - I was on vacation last week so I am only getting 
around to replying now.


--On August 7, 2009 6:36:41 AM -0500 Spencer Dawkins 
 wrote:



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.


Sure - seems reasonable. Change done in my working copy.


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 :-)


As per comments from Julian I won't make this change.


   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".


The text here is an exact copy of that in 4918. Strictly speaking all 
instructions are executed, it is just that some succeed and some fail. 
Perhaps better text is:


"If any one instruction fails to execute successfully, then all 
instructions MUST fail (i.e., either all succeed or all fail)".



   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


Fixed.


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.


Well ultimately I would like to see MKCALENDAR deprecated in favor of 
extended MKCOL - however, given the ever growing deployments of CalDAV 
that is probably not going to happen any time soon.


So, I have changed the title to:

"Using Extended MKCOL as an Alternative to MKxxx Methods"

and changed "replace" to "alternative for" in a couple of places.


--
Cyrus Daboo



___
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-vcarddav-webdav-mkcol-05

[Spencer Dawkins]

Hi, Julian,

I agree with your point here (on how RFC 2119 works). I thought the document 
would be clearer with 2119 language here, but it should not be included if 
you aren't comfortable using it.


Thanks,

Spencer



Spencer Dawkins wrote:

...
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 :-)

...


-0.5

As far as I can tell, it is a myth that things can only be normative when 
using RFC 2119 keywords. As a matter of fact, RFC 2119 points out:


6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.


So I'd prefer document authors to be more conservative in using those 
terms...


BR, Julian 


___
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: 

To: ; 
Cc: ; 
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

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

[Spencer Dawkins]

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.


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

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 ses

[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-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-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-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-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 re

[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

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-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

[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" 

To: "Spencer Dawkins" 
Cc: "Sanjay Harwani (sharwani)" ; "Subbaiah Venkata" 
; "Danny McPherson" ; ; 
"General Area Review Team" ; "Ross Callon" 
; "Acee Lindem" ; "Abhay Roy (akr)" 


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)" 

To: "Spencer Dawkins" ; "Subbaiah Venkata"
; "Danny McPherson" ; "Carlos 
Pignataro

(cpignata)" 
Cc: ; "General Area Review Team" ; 
"Ross
Callon" ; "Acee Lindem" ; "Abhay 
Roy

(akr)" 
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)

 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.


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

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" 

To: "Spencer Dawkins" 
Cc: "Sanjay Harwani (sharwani)" ; "Subbaiah Venkata" 
; "Danny McPherson" ; ; 
"General Area Review Team" ; "Ross Callon" 
; "Acee Lindem" ; "Abhay Roy (akr)" 


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)" 

To: "Spencer Dawkins" ; "Subbaiah Venkata"
; "Danny McPherson" ; "Carlos 
Pignataro

(cpignata)" 
Cc: ; "General Area Review Team" ; "Ross
Callon" ; "Acee Lindem" ; "Abhay 
Roy

(akr)" 
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)

 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.


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 name and Router ID in its hostname mapping table.

Spencer (minor): I'm suspecting that if this att

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)" 
To: "Spencer Dawkins" ; "Subbaiah Venkata" 
; "Danny McPherson" ; "Carlos Pignataro 
(cpignata)" 
Cc: ; "General Area Review Team" ; "Ross 
Callon" ; "Acee Lindem" ; "Abhay Roy 
(akr)" 

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)
   
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.
   

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  :-) 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

[Gen-art] Gen-ART review of draft-ietf-ospf-dynamic-hostname-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 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.


  DNS is used as the centralized mapping table, a network operator may
  desire a different name mapping than the existing in the DNS, or new
  routers may not yet be in DNS.

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  :-) 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. 



___
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-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 N

[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 do

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

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]

(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

[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

[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
 

[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-rmt-bb-lct-revised-09

[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-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 about how a sender could "identify a 
receiver 

[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

[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 , 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 ,
 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

Re: [Gen-art] Gen-ART LC reviewofdraft-ietf-isms-transport-security-model-12

[Spencer Dawkins]

And, just to point out the most interesting text on the page that Mary
referenced:

Q: How can I join the Gen-ART review team?

A: Interested volunteers should contact the General Area director, listed on
the membership page.

:-)

Thanks,

Spencer



Yes, every document that goes through IETF-LC is assigned one gen-art
reviewer to review the document, but the gen-art review process isn't
really a formal part of the IETF document process - it happens in
parallel with IETF-LC and the reviews are done on behalf of the General
Area director.  It would not be possible for us to cover all the docs
with more than one reviewer - the team is quite small.  The reality
(from my experience) seems to be that the only reviews you can count on
during IETF-LC are those from gen-art, sec-dir (they follow a similar
model as I understand it) and other areas as applicable (e.g., APP, OPS,
etc.). Although some of the latter reviews often happen earlier in the
process.  Each of the reviews from the Gen-ART team are prefaced with a
link to a Gen-ART FAQ:
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

Regards,
Mary Barnes
Gen-ART secretary

-Original Message-
From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On
Behalf Of Ben Campbell
Sent: Thursday, April 16, 2009 9:30 AM
To: Tom.Petch
Cc: General Area Review Team; i...@ietf.org
Subject: Re: [Gen-art] Gen-ART LC review
ofdraft-ietf-isms-transport-security-model-12


On Apr 16, 2009, at 2:29 AM, Tom.Petch wrote:


I am surprised not to have seen more formal reviews of the quartet for



isms I-Ds whose Last Call has just finished, updating as they do a
Standard, while at the same time introducing a Transport subsystem and



model, and also introducing a new (to snmp) way of providing Security.

I do not know what or how these reviews are triggered but I would have



expected a good deal more than this one and the one that appeared as I



was drafting this response, a round dozen even.


Gen-art reviews are assigned to a team of volunteers (i.e. the general
area review team.) I'm not sure about the assignment criteria, but I
_think_ we try to catch most, if not every, draft being IETF last called
for publication.




Tom Petch


- Original Message -
From: "Ben Campbell" 
To: ; ; "General Area
Review Team"

Cc: ; 
Sent: Friday, April 10, 2009 10:05 PM
Subject: Gen-ART LC review of draft-ietf-isms-transport-security-
model-12




___
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 mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art




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

[Gen-art] Gen-ART review of draft-ietf-rmt-pi-norm-revised-09

[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-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

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:

  ":stream;;"

  ";;: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 server admini

Re: [Gen-art] Gen-ART Review of draft-ietf-mpls-ldp-capabilities-03

[Spencer Dawkins]

Just to let people know, all of my comments from 02 have been addressed in 
the 03 revision. Ready for publication as a 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-mpls-ldp-capabilities-02
Reviewer: Spencer Dawkins
Review Date: 2008-04-30
IETF LC End Date: 2008-04-25 (yeah, I'm late)
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as a Proposed Standard.

Comments:

Almost all my "review comments" below are about 2119 language - this is a
very SHOULD-y draft. I'd especially call Russ's attention to my comment
about multiple occurrences of the same capability in one message, in 
Section

7.

idnits 2.08.08 reports "no issues", FWIW.

Abstract

  A number of enhancements to the Label Distribution Protocol (LDP)
  have been proposed.  Some have been implemented, and some are
  advancing toward standardization.  It is likely that additional
  enhancements will be proposed in the future.  At present LDP has no
  guidelines for advertising such enhancements at LDP session
  initialization time.  There is also no mechanism to enable and
  disable enhancements after the session is established.  This document
  provides guidelines for advertising LDP enhancements at session
  initialization time.  It also defines a mechanism to enable and
  disable enhancements after LDP session establishment.

Spencer (clarity): here and in the Introduction, the draft says 
"guidelines

at session initialization time, mechanism to enable/disable after session
establishment". Aren't both of these mechanisms? s/provides
guidelines/defines a mechanism/?

1. Introduction

  A number of enhancements to LDP as specified in [RFC5036] have been
  proposed.  These include LDP Graceful Restart [RFC3478], Fault
  Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for
  layer 2 circuits [RFC4447], a method for learning labels advertised
  by next next hop routers in support of fast reroute node protection
  [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for
  signaling inter-area LSPs [IALDP].  Some have been implemented, and
  some are advancing toward standardization.  It is likely that
  additional enhancements will be proposed in the future.

Spencer (clarity): I think I understand what all the words mean, but 
should

this be "additional enhancements will be implemented", or even "deployed"?

  At present LDP has no guidelines for advertising such enhancements at
  LDP session initialization time.  There is also no mechanism to
  enable and disable enhancements after the session is established.

  This document provides guidelines for advertising LDP enhancements at
  session initialization time.  It also defines a mechanism to enable
  and disable enhancements after LDP session establishment.

  LDP capability advertisement provides means for an LDP speaker to
  announce what it can receive and process.  It also provides means for
  a speaker to inform peers of deviations from behavior specified by

Spencer (clarity): are "a speaker" and "an LDP speaker" interchangeable in
this specification? I'm assuming so...

  [RFC5036].  An example of such a deviation is LDP graceful restart
  where a speaker retains MPLS forwarding state for LDP-signaled LSPs
  when its LDP control plane goes down.  It is important to point out
  that not all LDP enhancements require capability advertisement.  For
  example, upstream label allocation does but inbound label filtering,
  where a speaker installs forwarding state for only certain FECs, does
  not.

3. The LDP Capability Mechanism

  The LDP capability advertisement mechanism operates as follows:

- Each LDP speaker is assumed to implement a set of enhancements
  each of which has an associated capability.  At any time a
  speaker may have none, one or more of those enhancements
  "enabled".  When an enhancement is enabled the speaker advertises
  the associated capability to its peers.  By advertising the
  capability to a peer the speaker asserts that it shall perform
  the protocol actions specified for the associated enhancement.
  For example, the actions may involve receiving and processing
  messages from a peer that the enhancement requires.  Unless the

Spencer (clarity): I got a bit lost here. Suggest "For example, the
enhancement may require the LDP speaker to receive and process
enhancement-specific messages from its peer" - is this still correct?

  capability has been advertised the speaker will not perform
  protocol actions specified for the corresponding enhancement.

- In

Re: [Gen-art] Gen-ART LC review of draft-ietf-lemonade-streaming-09

[Spencer Dawkins]

Hi, Dave,

Ah - then this really does reduce to a general IMAP-wide "don't send 
credentials over unencrypted channels" warning, that more appropriately 
belongs somewhere else.


Thanks!

Spencer

My biggest concern was whether the media server might be configured  with 
MY IMAP credentials,


Ah, no, it's referring to the media server's credentials, not yours.

It (probably) doesn't know yours, or at least only knows them  sufficient 
for you to authenticate to it.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade




___
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-09

[Spencer Dawkins]

Hi, Neil,

Thanks for the quick response (so I can still remember writing the review 
:-)...


Deleting stuff we agree on - I think my suggestion here


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.


You're right, I actually took this verbatim from an earlier version of 
the IMAP URL RFC, but I notice the latest version has removed this  text. 
There is no particular need for it in this doc either, as the  base IMAP 
RFCs cover the perils of using non-encrypted communication  channels 
adequately enough, and as such it's not a security concern of  this doc. 
So I lean towards removing the sentence completely, or  simply lowercasing 
the SHOULD NOT.


is removing the sentence.

My biggest concern was whether the media server might be configured with MY 
IMAP credentials, and might decide it was a good idea to send MY IMAP 
credentials "in the clear". If that's possible, I'd hope for MUST NOT, but 
you're probably saying that this spec is not the right place to fight the 
battle of clear-text security credentials, even for IMAP, and I can see that 
being the case.


Thanks,

Spencer 



___
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-lemonade-streaming-09

[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-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:

  ":stream;;"

  ";;: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 server administrator may put
 pre-requisites on media server administrator before this
 relationship can be established, for example to guarantee the
 secu

[Gen-art] Gen-ART review of draft-ietf-netconf-tls-07.txt

[Spencer Dawkins]

Just to let people know - version 07 also looks fine to me ("ready for 
publication as a 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-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




___
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

[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

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" 

To: "Spencer Dawkins" 
Cc: ; "General Area Review Team" ; "Lisa 
Dusseault" 

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