Re: [Gen-art] [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03

[Eliot Lear]

On 04.01.22 18:02, tom petch wrote:


*From:* Eliot Lear
*Sent:* Tuesday, January 04, 2022 16:28
*To:* tom petch; gen-art@ietf.org; Russ Housley
*Cc:* draft-ietf-opsawg-sbom-access@ietf.org; ops...@ietf.org
*Subject:* Re: [OPSAWG] some YANG thoughts on 
draft-ietf-opsawg-sbom-access-03


Hi Tom,

Thanks for your review.  Please see below.



On security, YANG Guidelines, RFC8407, says that there MUST be 
Security Considerations and that they MUST be patterned on the latest 
template. No exemption for read only or grouping only!


Any risk is with the data being referred to, not the reference.  We can 
say that.




For example, I note that you refer to HTTP whereas the template only 
uses HTTPS, underpinned by TLS.  It is fine to say that the data is 
read only.  It is also fine to say that the data is in the public 
domain and so privacy is not a concern.


That really can't be helped because some of the underlying systems 
involved may not support TLS.  Integrity must be handled at different 
layer, and if confidentiality is important, that will have to be 
expressed there as well.  This really is an operational reality.  Again, 
this is a discovery mechanism that describes how to locate the data and 
what protocols to use.  We are not specifying the protocols or formats.



Eliot



OpenPGP_signature
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [OPSAWG] some YANG thoughts on draft-ietf-opsawg-sbom-access-03

[Eliot Lear]

Hi Tom,

Thanks for your review.  Please see below.

On 14.12.21 11:15, tom petch wrote:

From: OPSAWG  on behalf of Russ Housley via Datatracker 

Sent: 13 December 2021 22:02
Subject: [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03

Reviewer: Russ Housley
Review result: Almost Ready



Note: I am not a good persone to review the YANG specification.  I
assume one of the YANG Doctors will have a look at this document too.



You could say that there is no YANG Module as YANG Modules must be registered 
with IANA and the IANA Considerations in this I-D do not do so:-)

So
IANA Considerations must register the module as per YANG Guidelines

Added.


Security Considerations must use the template referenced by YANG Guidelines


This one's a little weird, since we are augmenting the MUD module, which 
isn't intended to be retrieved via NETCONF, and nothing here is intended 
to be writeable.  I could add read-only to all of this stuff.





The title in the revision reference clause bears little relationship to that of 
the I-D

Corrected.


YANG prefix must be unique and should be easy to use; I think that 
'mud-transparency' is about 12 characters longer than I would class as easy to 
use (e.g. mudtx)

Sold.


URL is insecure and to an obsolete web site (tools)

No mention of NMDA or lack of support thereof


Text welcome for this.




Lots of abbreviations not expanded on first use

In our modern pageless format, Section one would be easier to refer to with 
more subsections such as one for terminology with expanded abbreviations


Generally we should expand abbreviations on first use.  I will clean 
those up.





Why have a grouping and a uses which for me makes the module harder to 
understand?  It is not as if this grouping is going to be imported in lots of 
places AFAICT.


It may.  That is why it's a grouping.

Again, thanks for the review.

Eliot




OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03

[Eliot Lear]

Hi Russ,

And thanks for your review. Please see below.

On 13.12.21 23:02, Russ Housley via Datatracker wrote:

Reviewer: Russ Housley
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-opsawg-sbom-access-03
Reviewer: Russ Housley
Review Date: 2021-12-13
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready


Note: I am not a good persone to review the YANG specification.  I
assume one of the YANG Doctors will have a look at this document too.


Major Concerns:

Section 1 says:

To satisfy these two key use cases, objects may be found in one of
three ways:

This lead to some confusion for me.  Earlier in the document, it says:

This specification does not allow for vulnerability information to be
retrieved directly from the endpoint.  That's because vulnerability
information changes occur at different rates to software updates.

After thinking about it, I realized that the objects do not include
vulnerability information, but pointers to obtain vulnerability
information.  Please reword to others do not need to give it the
same amount of thought.


What I propose is first the following early on in the introduction:


This memo doesn't specify the format of  this information, but rather
only how to locate and retrieve these    objects.







Minor Concerns:

Section 1, first sentence: The reference to "A number of activities"
is very vague.  It is not wrong.  Please be more specific, provide
some references, or drop the vague reference altogether.


It'd be fun to reference an executive order.  Never done that before.



Section 1 says:

In the second case, when a device does not have an appropriate
retrieval interface, but one is directly available from the
manufacturer, a URI to that information must be discovered.

s/must/MUST/ ?


Sure.



Nits:

The terms "software" and "firmware" are used with essentially the same
meaning in this document.  If there is a difference, it needs to be
explained.  If they are the same in the context of this document, please
say so.


I've removed the term "firmware".


Abstract, last sentence: please add "(MUD)" and also a pointer to
RFC 8520.


I think this got rewritten.  Let me know when you see the update.

Thanks again for the review.

   Eliot




OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Tzdist-bis] Genart last call review of draft-murchison-tzdist-tzif-14

[Eliot Lear]

Hi Dale,

Thanks for the review.  I know Paul has some comments, but here are mine.


On 01.10.18 04:42, 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.
>
> For more information, please see the FAQ at
>
> .
>
> Document:  draft-murchison-tzdist-tzif-14
> Reviewer:  Dale R. Worley
> Review Date:  2018-09-30
> IETF LC End Date:  2018-10-09
> IESG Telechat date:  unknown
>
> Summary:
>This draft is on the right track but has open issues, described
>in the review.
>
> Major issues:
>
> 1. The draft does not specify the versioning and compatibility
> principles governing TZif files and their processors.  Certain
> passages suggest that processors are expected to *not* examine the
> version number in a file, but instead, extensions to the file format
> are made by adding further data blocks to the end of the file, and
> later-version processors handle earlier-version files by noticing that
> latter data blocks are missing.  This approach implies that processors
> based on earlier versions to not notice that there appears to be
> trailing garbage in the file.  But silent acceptance of trailing
> garbage is not specified, and this strategy is different from most
> IETF standards.

These files are self-contained, and may contain multiple versions of the
same information for compatibility purposes.  This is discussed in
Section 4 of the document.  I think it would be good to address your
last sentence by adding a new second bullet point to that section, as
follows:

>  o  Implementations that only understand Version 1 MUST ignore any
> data that extends beyond the calculated end of the version 1 data block.

I think it also makes sense to modify the following as well.

OLD:
>    o  Implementations SHOULD calculate the total lengths of the 32- and
>   64-bit headers and data blocks and compare them against the actual
>   file size, as part of a validity check for the file.

> NEW:
>    o  Implementations more recent than version 1 SHOULD calculate the
> total lengths of the 32- and
>    ^^^ 
>   64-bit headers and data blocks and compare them against the actual
>   file size, as part of a validity check for the file.
>

If there is text that suggests that version information not be
considered, could you please call that out?

And it's worth noting that a vast amount of code out there operates in
just this fashion today.


>
> 2. The semantics of the various data items -- what they mean and how
> they are to be used in processing -- is only hinted at.  I suspect
> that the draft is targeted at members of the community who already
> thoroughly understand the semantics of the data items (based on their
> names), but this is not stated, nor is any reference given to where
> one might learn this information.  OTOH, the glossary (in section 2)
> gives definitions of several terms that suggest the document is
> attempting to define the semantics, but the definitions given are
> nowhere near sufficient to specify those semantics.

This isn't really actionable.  Also, Section 2 is not in itself meant to
provide comprehensive definition of all elements.  Much of that is done
in Section 3 for each data element.  Thus I propose no change here.

>
> 3. Apparently (see comments on section 4), characters outside the
> ASCII set are allowed in time zone designations.  If so, their
> encoding needs to be specified.

This element is a reference to a POSIX string and must be handled in
accordance with POSIX rules.  This is already referenced.

I'll leave it to Ken and Paul to address nits.

Eliot
>
> Minor issues:
>
> Nits/editorial comments: 
>
>
> 1.  Introduction
>
>This specification does not define the source of leap second
>information, nor does it define the source the time zone data,
>metadata, identifiers, aliases, localized names, or versions as
>defined in Section 3 of [RFC7808].  One such source is the IANA-
>hosted time zone database [RFC6557].
>
> The sequence "nor does it define the source the time zone data" is
> gramatically incorrect.  I would suggest it should be "... the source
> of ...", but making that change leaves the semantically heterogenous
> list "the time zone data, metadata, identifiers, aliases, localized
> names, or versions".  Also, it's not clear how "as defined in Section
> 3 of [RFC7808]" attaches to the sentence, since the closest item in
> the list, "versions", is defined in section 3 and not RFC 7808.  I
> suspect that some part of the wording was accidentally deleted.
>
> 2.  Conventions Used in This Document
>
>Daylight Saving Time (DST):  The time according to a 

Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20

[Eliot Lear]

Hi Robert and everyone else,

Circling for a landing here...


On 11.04.18 18:15, Robert Sparks wrote:
> With this, I'm puzzled about the use of the word standardized at all.
> I think I'm hearing that you expect MUD controllers to know about some
> well-known classes by convention and that groups like fairhair or
> someone else might make a list of classes that MUD controllers might
> collectively decide to build in knowledge of. Am I getting closer to
> the right picture? (This is opposed to a set of classes that are
> created by a standards action and listed in a registry somewhere).

I've attempted to clarify this language as we discussed.  On the point
of standardization, I've made a clean separation:

  * URNs: standardized (and therefore hopefully well documented)
behaviors, such as DNS and NTP.
  * URIs that take the form of URLs.  These are just class names that
the administrator has to fill out, or are otherwise somehow
pre-populated.

I hope that this resolves any lingering confusion.

Thanks again for working to improve this document.  I really appreciate it!

Eliot

___
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-opsawg-mud-20

[Eliot Lear]

All the way down...


On 11.04.18 18:15, Robert Sparks wrote:
>
>>
>> Similarly, the use of the word standardized naked like that is
>> probably unhelpful.
> Can I infer you plan to edit it out or dress it more?

Yes.

>> One could imagine, for instance, Fairhair or some other consortium
>> deciding to create standard classes.
>>
>> What I propose is two changes to facilitate better understanding:
>>
>>  1. To include the simple example described above.
>>  2. To add an optional "documentation"  element in the "mud"
>> container that consists of a URL that points to documents for
>> each class, when so used.
>>
> Sure.
>>
>> Thoughts?
>>
> With this, I'm puzzled about the use of the word standardized at all.
> I think I'm hearing that you expect MUD controllers to know about some
> well-known classes by convention and that groups like fairhair or
> someone else might make a list of classes that MUD controllers might
> collectively decide to build in knowledge of. Am I getting closer to
> the right picture? (This is opposed to a set of classes that are
> created by a standards action and listed in a registry somewhere).

The class is just a name that expands out to a bunch of IP addresses. 
It happens to take the form of a URI, but it's really just a name. 
There could be well known NAMES, and indeed we create a URN registry
just for that purpose.  Maybe I need to be a bit more clearer on that point?

Eliot
___
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-opsawg-mud-20

[Eliot Lear]

Hi Robert,

A few additional comments below:


On 10.04.18 16:22, Robert Sparks wrote:
>
>
>
> On 4/10/18 5:43 AM, Eliot Lear wrote:
>>
>> Hi Robert and thanks again for the review.  Please see below for
>> responses.  These are my personal views.  The WG chairs / shepherds
>> may have different opinions.
>>
> Thank you for the very quick response!
>>
>>
>> On 09.04.18 19:57, Robert Sparks wrote:
>>> Reviewer: Robert Sparks
>>> 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 wait for direction from your
>>> document shepherd or AD before posting a new version of the draft.
>>>
>>> For more information, please see the FAQ at
>>>
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> Document: draft-ietf-opsawg-mud-20
>>> Reviewer: Robert Sparks
>>> Review Date: 2018-04-09
>>> IETF LC End Date: 2017-11-07
>>> IESG Telechat date: 2018-04-19
>>>
>>> Summary: Almost ready but with minor issues to address before publication 
>>> as a
>>> standards track RFC 
>>>
>>> Minor issues:
>>>
>>> Section 3.15 is confused, and I don't think you'll get the implementation 
>>> you
>>> intend with the MUST in the current language. direction-indicated is not a
>>> flag. The text about dropping should talk about matching the direction that 
>>> was
>>> indicated.
>>
>> Having reread this section (and perhaps I am a bit too close to the
>> text), perhaps it is a bit confused.  How about something along the
>> following lines:
>>
>> 3.15.  direction-initiated
>>
>>    When applied this matches the direction in which a TCP connection is
>>    initiated.  When direction initiated is "from-device", packets
>> that are
>>    transmitted in the direction of a thing MUST be dropped unless the
>> thing
>>    has first initiated a TCP connection.  This node may be implemented in
>>    its simplest form by looking at naked SYN bits, but may also be
>> implemented
>>    through more stateful mechanisms.
>>  
>>   [RFC6092] specifies IPv6 guidance best
>>    practices.  While that document is scoped specifically to IPv6, its
>>    contents are applicable for IPv4 as well. 
>>
>>
>> Better?
> wfm
>>
>>> The quoted issues below are from my early review of -08. I don't think 
>>> they've
>>> been addressed or responded to. Apologies if I missed a response.
>>>
>>>> The document proposes "reputation services". It needs more words about
>>>> whether those exist, and what scopes the architecture imagines (an
>>>> enterprise might have a different idea of a reputation service than a
>>>> residence). There is a notion of "decent web reputations" in the security
>>>> considerations section. Who determines that? The security considerations
>>>> section should talk about attacks against the reputation services.
>>>> I think there needs to be more discussion of the PKI used for signing MUD
>>>> files.
>>>  
>>
>> While this section is admittedly a bit vague, we need some
>> operational experience to develop the appropriate use of PKI as an
>> anchor for reputations.  This having been said, if you have a
>> specific proposal for text, I'd be interested in what you have to say.
> Do you envision enterprises or manufacturers creating a new set of
> anchors of trust, or are you hoping to reuse the web PKI or something
> else? If you don't know and all of these are on the table, mentioning
> it would help implementers avoid assumptions that could hinder deployment.

Thanks for the guidance.   In fact I think we need to more clearly
specify the signature in terms of the purpose.  The tools (openssl)
support S/MIME signing easily enough for CMS.  I think this is what we
want, and it implies that we are *not* using the webpki, but instead
just getting an S/MIME certificate.  This implies that the signers will
have to be "admitted" on first sight.  Would that work for you?

Also see below.


>>
>>>> Consider discussing whether the stacks used by typical things will let
>>>> them add DHCP options (or include bits in the other protocols being 
>>>> enabled). If it's well known (I can't say) that these stacks typically
>>>> _won't_ p

Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20

[Eliot Lear]

Hi Robert and thanks again for the review.  Please see below for
responses.  These are my personal views.  The WG chairs / shepherds may
have different opinions.


On 09.04.18 19:57, Robert Sparks wrote:
> Reviewer: Robert Sparks
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-opsawg-mud-20
> Reviewer: Robert Sparks
> Review Date: 2018-04-09
> IETF LC End Date: 2017-11-07
> IESG Telechat date: 2018-04-19
>
> Summary: Almost ready but with minor issues to address before publication as a
> standards track RFC 
>
> Minor issues:
>
> Section 3.15 is confused, and I don't think you'll get the implementation you
> intend with the MUST in the current language. direction-indicated is not a
> flag. The text about dropping should talk about matching the direction that 
> was
> indicated.

Having reread this section (and perhaps I am a bit too close to the
text), perhaps it is a bit confused.  How about something along the
following lines:

3.15.  direction-initiated

   When applied this matches the direction in which a TCP connection is
   initiated.  When direction initiated is "from-device", packets that are
   transmitted in the direction of a thing MUST be dropped unless the thing
   has first initiated a TCP connection.  This node may be implemented in
   its simplest form by looking at naked SYN bits, but may also be
implemented
   through more stateful mechanisms.
 
  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well. 


Better?

>
> The quoted issues below are from my early review of -08. I don't think they've
> been addressed or responded to. Apologies if I missed a response.
>
>> The document proposes "reputation services". It needs more words about
>> whether those exist, and what scopes the architecture imagines (an
>> enterprise might have a different idea of a reputation service than a
>> residence). There is a notion of "decent web reputations" in the security
>> considerations section. Who determines that? The security considerations
>> section should talk about attacks against the reputation services.
>> I think there needs to be more discussion of the PKI used for signing MUD
>> files.
>  

While this section is admittedly a bit vague, we need some operational
experience to develop the appropriate use of PKI as an anchor for
reputations.  This having been said, if you have a specific proposal for
text, I'd be interested in what you have to say.

>> Consider discussing whether the stacks used by typical things will let
>> them add DHCP options (or include bits in the other protocols being 
>> enabled). If it's well known (I can't say) that these stacks typically
>> _won't_ provide that functionality, then you should punch up the
>> discussion of the controllers mapping other identifiers to MUD URLs on
>> behalf of the thing.

We did indeed add some text about this, almost verbatim to what you have
above (I think at your suggestion).  This can be found in the
introduction toward the bottom of page 9.

>  
>> You suggest the DHCP Client (which is a thing) SHOULD log or report 
>> improper acknowledgments from servers. That's asking a bit much from
>> a thing. I suspect the requirement is unrealistic and should be removed
>> or rewritten to acknowledge that things typically won't do that.

I propose to delete that paragraph to match that we do not wish DHCP
servers to modify their state.  This would address your concern (also
see below).

>  
>> The security and deployment considerations sections talk about what the
>> need for coordination if control over the domain name used in the URL
>> changes. It should talk more about what happens if the new administration
>> of the domain is not interested in facilitating a transition (consider
>> the case of a young company with a few thousand start-up-ish things out
>> there that loses a suit over its name). Please discuss whether or not
>> suddenly losing the MUD assisted network configuration is expected to
>> leave the devices effectively cut-off. 

The example you are talking about is a subset of what happens if the
file simply doesn't exist.  At worst, one is left in a situation no
worse than we are today: that is, someone will have to manually decide
policy, or apply a default policy.  This particular text is the subject
of separate piece of work that Thorsten Dahm and Steve Rich are
considering, and it is also the subject of some ongoing research.  That
is to say: we might be able to do better in the future when we have some
operational experience.


>  
>> Right 

Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

[Eliot Lear]

I wrote:


On 29.01.18 23:07, Eliot Lear wrote:
>
> The line in question is as follows:
>
>   This includes,
>   but is not limited to, native and unmodified IPv4 and IPv6
>   connectivity, global reachability, and no additional limitation
>   that would materially impact their Internet use.
>
> How about:
>
> This includes,
>   but is not limited to, native and unmodified IPv4 and IPv6
>   connectivity, global reachability, and no additional limitation
>   that would materially impact their Internet use.

And what I meant to propose was this:

    It MUST be possible to provision
 Internet Access to the Facility and IETF Hotels that allows
 local attendees to utilize the Internet for all their IETF,
 business, and day to day needs; as well as sufficient
 bandwidth and access for remote attendees. This includes, but
is not
 limited to, native and unmodified IPv4 and IPv6 connectivity,
 global reachability, and no  additional limitation that would
 materially impact their Internet use.
 

Sorry for the confusion.


signature.asc
Description: OpenPGP digital signature
___
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-mtgvenue-iaoc-venue-selection-process-11

[Eliot Lear]

Hi Alissa,


On 30.01.18 16:54, Alissa Cooper wrote:

>>> 'It is anticipated that
>>>   those roles will evolve.  The IASA MUST keep the
>>>   community informed in this regard, and MAY do so without updating
>>>   this memo.'
>> I don't think the MUST significantly changes the meaning, so I'm ambivalent 
>> about the change. Since this text was put in to address a comment in AD 
>> Evaluation, I'm inclined to hear from Alissa.
> Perhaps the concern could be addressed by saying “without first updating this 
> memo”? The point I raised is that this document shouldn’t gate the ability 
> for the roles to change, but certainly if they do change the document should 
> be updated (or obsoleted by a new document) to match the reality.
>

Editorially I don't think there is a full sentence that we want to add
to capture this.  The IASA is not responsible for this document, and I
don't think we want to make them responsible for it.  The community is
responsible.  Therefore, I suggest we run with Dan's text that simply
requires the IASA to keep the community informed of changes in a timely
fashion, and trust that the IASA will find the right means to do so.

Eliot





signature.asc
Description: OpenPGP digital signature
___
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-mtgvenue-iaoc-venue-selection-process-11

[Eliot Lear]

Ok.  I'll push an update based on these changes in the next few days,
barring additional comments.


On 30.01.18 17:02, Dan Romascanu wrote:
>
>
>
> On Tue, Jan 30, 2018 at 5:54 PM, Alissa Cooper  > wrote:
>
>
> > On Jan 29, 2018, at 1:12 PM, Pete Resnick
> > wrote:
> >
> >
> >> 8. Section 4:
> >>
> >> 'It is anticipated that
> >>   those roles will evolve.  The IASA is responsible for keeping the
> >>   community informed in this regard, and MAY do so without updating
> >>   this memo.'
> >>
> >> I would be a little concerned if some of the key roles would
> change without
> >> this document being updated. I understand the need to be
> flexible, but we need
> >> to put some limits. Maybe at least emphasize the need to inform
> the community
> >> by a MUST. For example:
> >>
> >> 'It is anticipated that
> >>   those roles will evolve.  The IASA MUST keep the
> >>   community informed in this regard, and MAY do so without updating
> >>   this memo.'
> >
> > I don't think the MUST significantly changes the meaning, so I'm
> ambivalent about the change. Since this text was put in to address
> a comment in AD Evaluation, I'm inclined to hear from Alissa.
>
> Perhaps the concern could be addressed by saying “without first
> updating this memo”? The point I raised is that this document
> shouldn’t gate the ability for the roles to change, but certainly
> if they do change the document should be updated (or obsoleted by
> a new document) to match the reality.
>
> Thanks,
> Alissa
>
>
>
> That would be fine with me.
>
> Regards,
>
> Dan
>



signature.asc
Description: OpenPGP digital signature
___
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-mtgvenue-iaoc-venue-selection-process-11

[Eliot Lear]

Hi Pete and thanks Dan for the review.  Please see below.


On 29.01.18 19:12, Pete Resnick wrote:
> Dan,
>
> Thanks so much for the thorough review. I'll try to get each of these
> into the issues list. Comments inline:
>
> On 24 Jan 2018, at 11:46, Dan Romascanu wrote:
>
>> Reviewer: Dan Romascanu
>> Review result: Ready with Issues
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> .
>>
>> Document: draft-ietf-mtgvenue-iaoc-venue-selection-process-11
>> Reviewer: Dan Romascanu
>> Review Date: 2018-01-24
>> IETF LC End Date: 2018-01-31
>> IESG Telechat date: 2018-02-08
>>
>> Summary:
>>
>> This is an important document for the IETF process, resulting from many
>> discussions in the IETF and the different associated groups and
>> committees. The
>> memo is well written and reflects these discussions. The comments
>> from the
>> Gen-ART perspective represent a review for clarity and consistency,
>> and not a
>> personal input on the content of the document.
>>
>> Major issues:
>>
>> Minor issues:
>>
>> 1. in Section 1:
>>
>> '   IETF Hotels:
>>   One or more hotels, in close proximity to the Facility, where the
>>   IETF guest room allocations are negotiated and IETF SSIDs are in
>>   use.'
>>
>> a few comments here:
>> - taking into account the previous definition of Facility, it looks
>> better s/in
>> close proximity/within or in close proximity/
>
> That seems like a perfectly reasonable change. Unless I hear
> objections from others, let's do it.
>
>> - 'where the IETF guest room
>> allocations are negotiated' - do we mean to say 'where IETF guest
>> room rates
>> are applied'?
>
> It's not just the rates, but also the number of rooms reserved. This
> seems just editorial to me, though probably worth addressing. I'm glad
> to have you or Eliot suggest text to clarify.

How about "where IETF guest room block allocations are negotiated and
contracted"?

>
>> - 'and IETF SSIDs are in use' : do we really need to include this
>> in the definition of the IETF Hotels and if yes, this is the way to
>> say it?
>> SSID is somehow technology specific, and imposes a restriction on the
>> hotel
>> network (network name) that is not really critical. What is critical
>> is for the
>> participants to have the Internet Access mandatory requirements met
>> in their
>> hotel room, and even this needs not be part of the definition.
>
> Interesting. I suppose "SSID" could turn out to be anachronistic. I
> don't think there would be any objection to generalizing the text.
> Eliot, will you take a stab at this?

The point is that the IETF establishes its own network services at these
hotels.  How about- where "network services managed by the IASA (e.g.,
the "IETF" SSID) are available"?

>
>> 2. Also in Section 1:
>>
>> 'Of particular note is that overflow hotels usually are
>>   not connected to the IETF network '
>>
>> We did not ask the IETF Hotel either to be connected to the IETF
>> network - see
>> also the above
>
> I understand your point: We do not necessarily have "connecting to the
> IETF network" as a requirement for the IETF Hotel; rather, they must
> meet the Internet Access criteria. I think this one should be
> addressed to be consistent with the resolution of the previous issue.

Right.  I can invert the above.
>
>> 3. Section 2:
>>
>>   2.  Avoid meeting in countries with laws that effectively exclude
>>   people on the basis of race, religion, gender, sexual
>>   orientation, national origin, or gender identity.
>>
>> The term 'national origin' has different connotations in different
>> cultures and
>> law systems. Some make a clear distinction between nationality and
>> citizenship.
>> I believe that the intention is to be inclusive, so I suggest:
>> s/national
>> origin, or gender identity./national origin, citizenship, or gender
>> identity./
>
> I think that's a reasonable change; I believe it matches the intent of
> the WG.
>
>> 4. Section 3.1 - the last bullet says nothing about remote access -
>> is this
>> intentional? It should say something also about global reachability from
>> outside for remote participants.
>
> Good catch. The bullet was written from the point of view of the local
> attendees, but I think it's reasonable to make note of remote
> attendees in this context. (It does say, "not limited to", but it
> makes sense to make this one explicit.)

The line in question is as follows:

  This includes,
  but is not limited to, native and unmodified IPv4 and IPv6
  connectivity, global reachability, and no additional limitation
  that would materially impact their Internet use.

How about:

This includes,
  but is not limited to, native 

Re: [Gen-art] Genart early review of draft-ietf-opsawg-mud-08

[Eliot Lear]

Hi Robert,

Thanks now for BOTH of your reviews.  I've a number of proposals below.

On 9/7/17 5:51 PM, Robert Sparks wrote:

> There is one aspect of caching semantics we should probably capture,
> which is that the cache-validity period should exceed the HTTP cache
> or expiry period as specified by max-age or Expires.  Does that sound
> about right to you?
> Goes in the right direction. Do you expect POST to work with this?

There is no particular POST operation required, but if someone wanted to
POST a MUD file, so long as they also POST a signature file, it should
be fine.

>>
>>> I think there needs to be more discussion of the PKI used for signing MUD
>>> files.
>>
>> We do have some discussion in Section 12.2.  I'm happy to add an
>> additional sentence or two, but would seek guidance on where you
>> think we're missing.
> So, are you expecting to reuse the web PKI here? Will the MUD files be
> signed with the same credentials used by the HTTP server? I'm thinking
> you aren't, and are waving your hands at where trust lies with the
> recommendation that signers be validated directly etc. Either way, I
> think you need to be more explicit and that what you expect for
> establishing trust is going to take more than a couple of sentences.

You're right.  I don't think we want to interlock the signature of the
file with the cert used on the web server.  It *could* be that, but the
focus on trust has to be the signer of the file.  How about something
like this:

The purpose of the signature on the file is to assign accountability
to an entity, whose reputation can be used to guide administrators
on whether or not to accept a given MUD file.  It is already common
place to check web  reputation on the location of a server on which
a file resides.  While it is likely that the manufacturer will be
the signer of the file, this is not strictly necessary, and may not
be desirable.  For one thing, in some environments, integrators may
install their own certificates.  For another, what is more important
is the accountability of the recommendation, and not the
cryptographic relationship between the device and the file. 


??

This follows the philosophy we've used previously in efforts like DKIM.


>>
>>> Consider discussing whether the stacks used by typical things will let
>>> them add DHCP options (or include bits in the other protocols being 
>>> enabled). If it's well known (I can't say) that these stacks typically
>>> _won't_ provide that functionality, then you should punch up the
>>> discussion of the controllers mapping other identifiers to MUD URLs on
>>> behalf of the thing.
>>
>> I agree.  We allude to this in the draft.  We say, for instance:
>>> It is possible that there may be other means for a MUD URL to be
>>> learned by a network.  For instance, if a device has a serial number,
>>> it may be possible for the MUD controller to perform a lookup of the
>>> device, if it has some knowledge as to who the device manufacturer
>>> is, and what its MUD file server is.  Such mechanisms are not
>>> described in this memo, but are possible.
>>
>> The case we have in mind is LoRaWAN.  Should we go further?
> I think explicitly acknowledging that some things stacks limit their
> behavior will pay back. 

How about a replacement paragraph:

It is possible that there may be other means for a MUD URL to be
learned by a network.  For instance, some devices may already be
fielded or have very limited ability to communicate a MUD URL, and yet
can be identified through some means, such as a serial number or a
public key.  In these cases, manufacturers may be able to map those
identifies to particular MUD URLs (or even the files themselves).
Similarly, there may be alternative resolution mechanisms available
for situations where Internet connectivity is limited or does not
exist.  Such mechanisms are not described in this memo, but are
possible.  Implementors should allow for this sort of flexibility of
how MUD URLs may be learned.

>
>>> You suggest the DHCP Client (which is a thing) SHOULD log or report 
>>> improper acknowledgments from servers. That's asking a bit much from
>>> a thing. I suspect the requirement is unrealistic and should be removed
>>> or rewritten to acknowledge that things typically won't do that.
>> I think there's a philosophical thing hiding here, though: what
>> expectations should we have of device.  As a SHOULD we're saying, if
>> you have good cause not to, ok.  But otherwise, for the sake of the
>> sanity of the customer, please log.
> Why not acknowledge in the document that the expectation is that most
> won't be able to.
> Painting as explicit and accurate picture as possible can only do
> good, no?
> (Again, I'm not trying to _assert_ that the majority of things can't,
> but that's my suspicion. People who work with this things on a daily
> basis should weigh in.)

Obviously a Thing can be literally 

Re: [Gen-art] Genart early review of draft-ietf-opsawg-mud-08

[Eliot Lear]

Robert,

As I wrote earlier, this was a great review.  Thanks for that.  Please
see below.


On 8/30/17 7:21 PM, Robert Sparks wrote:
> Reviewer: Robert Sparks
> Review result: Almost Ready
>
> This is an exciting concept, and the draft overall is approachable. I
> have identified a few areas I think need more detail, and have a 
> longish list of nits (please don't take that to be negative).
>
> ==Issues==
>
> I find the structure of the introduction unclear. Please consider
> reworking it.  I would suggest even more succinctly listing goals and
> constraints, and then intended applicability (these things are in the
> current text, but I think you can render them much more efficiently). In
> particular, the argument that implementers of things are incented only to
> provide the minimal amount of behavior to get their thingyness could be
> more strongly highlighted.

I've received conflicting reviews here.  Most like what's there and
while I'm open to specific textual changes, a full reorganization would
likely be destabilizing.

> The document proposes "reputation services". It needs more words about
> whether those exist, and what scopes the architecture imagines (an
> enterprise might have a different idea of a reputation service than a
> residence). There is a notion of "decent web reputations" in the security
> considerations section. Who determines that? The security considerations
> section should talk about attacks against the reputation services.

This is discussed in security considerations:
> It may also be useful
> to limit retrieval of MUD URLs to only those sites that are known to
> have decent web reputations.
What I am specifically talking about are web or domain reputation
services.  These are pretty commonplace today.  Your browser uses one,
and numerous companies offer them, including our own.  But to be
clearer, I propose to use the term "web or domain reputation services",
so that people know what I'm talking about.




> In the first paragraph of Section 2, it's not clear if you are trying
> to restrict the models to only those in the two documents in the list
> following the paragraph. 

Right.  This was caught earlier, and I'll correct.

> I am not a YANG doctor, so this may be in the weeds, but it feels like
> there's a discrepancy between the diagram at the end of section 2 and the
> element definitions in section 3. In particular 3.7 doesn't seem to align
> with what the diagram or the example in Appendix B uses. Should you be 
> defining "from-device-policy" and "to-device-policy" instead of
> "packet-direction"? (I'm wondering if 3.7 reflects an older design?)

Yupper.  Fixed (I think).
> At section 3.13, the description of my-controller is not quite right.
> This bit signals to the mud controller to use a mapping that it knows
> about or creates. Something else established that class (and maybe gave
> it a name). I talked about this with Eliot and he has a better 
> description to use.

Proposed text:

> This null-valued node signals to the MUD controller to use whatever
> mapping it has for this URL to a controller class".  This may require
> prompting the administrator for class members.  Future work should
> seek to automate membership management.

> It's not clear to me that this is a good use of .well-known. I suggest
> getting an expert review on the proposed usage. (I had a quick 
> conversation with Mark Nottingham and got some initial feedback that 
> I'm passing along here. I'm sure there's more that an in-depth review
> would identify.) Why wouldn't a URI template (RFC6570) do the job? 
> Rather than use RFC3986's query, consider pointing to HTML5 (which
> would bring the more familiar key=value format). 

The key issue is that we want to externalize versioning AND hardcode it
in the URL so that it's independent of transport.  Remember, there is
very little information exchange between the Thing and the network, and
I will claim that's a good thing.

> The document needs to say more about how HTTP is used. I assume you only
> intend to use GET, and that you expect redirects to be followed, and that
> nothing special needs to be considered with caching? The document needs
> to be explicit about it. Take a look at 
> . (There's been some conversation
> about it on the art list, so Eliot, at least, is already aware of it - 
> see )

What we say today is the following;
> Processing of this
> URL occurs as specified in {{RFC2818}} and {{RFC3986}}.
There is one aspect of caching semantics we should probably capture,
which is that the cache-validity period should exceed the HTTP cache or
expiry period as specified by max-age or Expires.  Does that sound about
right to you?

> I think there needs to be more discussion of the PKI used for signing MUD
> files.

We do have some discussion in Section 12.2.  I'm happy to add an
additional sentence or two, but would seek guidance on where 

Re: [Gen-art] [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08

[Eliot Lear]

Hi Ranga,

Robert wrote a great review, and I'll respond to him in due course with
suggested changes.  I wanted to take just a moment to comment to you on
your point:


On 8/31/17 12:00 AM, M. Ranganathan wrote:
>
>
> On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks  > wrote:
>
>
>
> Right now, you leave the DHCP server (when it's used) responsible for
> clearing state in the MUD controller. Please discuss what happens when
> those are distinct elements (as you have in the end of section
> 9.2) and
> the DHCP server reboots. Perhaps it would make sense for the DHCP
> server
> to hand the length of the lease it has granted to the MUD
> controller and
> let the MUD controller clean up on its own?
>
>
> I would like to add a few words to the comprehensive review presented
> by Robert Sparks (I hope it is proper etiquette on this list to do so).
>
> With respect to the observation above:
>
> There is also a cache timeout in the MUD profile. Does it make sense 
> that the MUD controller should take the minimum of the DHCP lease time
> and the cache timeout and use that to time out the installed ACLs (?)
> The DHCP server should also  pass to the MUD controller, some way of
> identifying the device to which the lease has been granted (for
> example the MAC address of the device).
>
> The draft also not specify how the DHCP server will communicate with
> the MUD controller (presumably via a simple REST interface but what is
> the URL to be used and how are the parameters passed?). I think this
> should be specified for interoperability between DHCP clients and MUD
> servers. Maybe words describing this interaction can be added here.

That's right.  At the moment, this is an "internalized" function.  That
is to say that the DHCP server is said to be tightly coupled to the MUD
controller without standardized interfaces.  In my first implementation,
I literally just tailed dhcpd syslog entries and triggered MUD based on
DHCPREQUEST messages.  Clean-up state had to do with RELEASE or periodic
SNMP queries.  Our implementation at Cisco does something different.

However... if the OPSAWG would like, and there is interest, we can
formalize that interface.  I don't want to do it in THIS draft (it's
already fairly involved), but there's nothing to say we couldn't do some
follow-on work.

Fair enough?

Eliot


signature.asc
Description: OpenPGP digital signature
___
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-tzdist-service-08

[Eliot Lear]

Hi Russ and thanks for the review.

Cyrus is going to answer you on these.  But I have three comments, below:

On 6/5/15 10:09 PM, Russ Housley wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 This review is in response to a request for early Gen-ART review.

 Document: draft-ietf-tzdist-service-08
 Reviewer: Russ Housley
 Review Date: 2015-06-05
 IETF LC End Date: 2015-06-17
 IESG Telechat date: unknown

 Summary: Almost Ready


 Major Concerns:

 In section 5.6, it is not clear to me how to distinguish the addition
 of a leap second from the removal of a leap second.  The UTC offset
 from TAI in seconds is provided.  And, so far, we have never seen a
 negative leap second.  Is the assumption that we will never see so
 many negative ones that the offset is les than zero?  Please clarify.

Right.  We should allow for this.  A related point: if this ever
happens, however: never mind this protocol, things are likely to break
all over.



 Minor Concerns:

 Section 4.2.1.3 says: 'The well-known URI is always present on the
 server, even when a TXT RR (Section 4.2.1.2) is used in the DNS to
 specify a context path.'  I think it would be better to reword this
 as a MUST statement.

 Section 10.1.1 says: Decisions made by the designated expert can be
 appealed to the IESG Applications Area Director, then to the IESG.
 The IESG just merged the Applications Area and the RAI Area, creating
 the ART Area.  Is there a way to word this that can avoid confusion
 when the IESG makes further organizational changes?

You're right, and I should have caught this.  My suggestion is that the
text be amended to refer to Section 3 of RFC 5226.


 Section 10.2 says: Change controller:  IETF.  Would it be better for
 the IESG to be the change controller?  This provides better alignment
 with Section 10.3.

If that is the norm, then yes.

Eliot




signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Eliot Lear]

Hi,

On 1/20/15 8:17 AM, Martin Thomson wrote:
 On 19 January 2015 at 02:37, Elwyn Davies elw...@dial.pipex.com wrote:
 Summary:
 Almost ready.  A well written document with just a few nits really.  I am
 slightly surprised (having not been following httpbis in detail) that HTTP/2
 is so tightly wedded to TCP - this is doubtless pragmatic but it adds to the
 ossification of the Internet and makes me slightly suspicious that it is an
 attempt to really confirm HTTP/2 as the waist of the neo-Internet.  Can't we
 ever use any other transport?
 I think that - overall - the desire for the timely replacement of
 HTTP/1.1 was stronger than the desire to attain perfection.

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

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

THIS version of HTTP is very much focused on multiple streams of
communication.  There is the equivalent of source quench,
prioritization, and windowing; and indeed the intent is to reduce the
number of parallel TCP connections.  This having been said, I don't see
this point as against HTTP2, but a reflection of the difficulty in
making substantial changes to the transport layer.  The IAB have had one
workshop that touched on this point (ITAT)[1] in which Elwyn
participated, and next week we will hold another (SEMI)[2].

Eliot
[1] http://tools.ietf.org/html/rfc7305
[2] https://www.iab.org/activities/workshops/semi/



signature.asc
Description: OpenPGP digital signature
___
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-ianaplan-icg-response-06

[Eliot Lear]

Hi Christer,

Thank you for your review.

On 12/9/14, 12:50 PM, Christer Holmberg wrote:
 General:
 --

 Q_1:

   In Section 2, the IETF reply text sometimes uses we to refer to IETF. 
 I think it would be good to say IETF.

   For example:

   We consider .ARPA part - IETF considers .ARPA part
   ...few cases where we may further... - ...few cases where 
 IETF may further...

   Etc.

   This may not be seen needed when reading the draft, but it will be 
 useful if e.g. the IETF reply text is quoted elsewhere.

I have done this where it has been possible to do without leaving an
awkward structure.   If the text is taken out of that context, it is
standard practice (at least in America) to use brackets to replace a
pronoun, such as [The IETF] for we.


 Abstract:
 

 Q_2:

   I think it would be good if the Abstract also would indicate that the 
 LS was primarily sent to ICANN. Currently the text only says that an LS was 
 sent somewhere, and that IETF was invited to reply.

I propose the following abstract to address your concern:

The U.S. NTIA has solicited a request from ICANN to propose
how the NTIA should end its oversight of the IANA functions.
After broad consultations, ICANN has in turn created the IANA
Stewardship Transition Coordination Group.  That group
solicited proposals for thre three major IANA functions:
names, numbers, and protocol parameters.  This document
contains the IETF response to that solicitation for protocol
parameters.  It is meant to be included in an aggregate
response to the NTIA alongside those for names and numbering
resources that are being developed by their respective
operational communities.

 Q_3:

   The last sentence of the Abstract says: The IETF community is invited 
 to comment and propose changes to this document.

   It is unclear what this document refers to. If it refers to the 
 aggregate proposal mentioned earlier, I think that should be more clear.

This sentence will be removed, as the invitation will have expired.



 Introduction:
 ---

 Q_4:

   In the 1st paragraph, I think it would be good to indicate that IETF 
 was invited to reply to the LS.


While we were expected to reply, I do not know that we received an
actual specific invitation.  I am happy to be told otherwise.

Regards,

Eliot




signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09

[Eliot Lear]

Alexey,

On 1/28/14, 9:37 AM, Alexey Melnikov wrote:

 I think David's right that some version of what Eliot said:
 there
 is a requirement for strict syntax parsing.  If the client blows it in
 any way, the server SHOULD return an error with a BAD response.
 ...should be added to the section about the line-length limit.  A
 sentence or two should do nicely.
 Yes, I agree.



Then my suggestion is to push out a new version with  some text along
these lines before the teleconference, please (tomorrow would be
ideal).  I will note that I believe this advice to be general in nature
and not limited to this capability, but we certainly can reinforce the
point here, and restate it if/when someone does an update to 3501
(probably when I have grandchildren, I would think).

Eliot
___
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-qresync-rfc5162bis-09

[Eliot Lear]

Hi Dave,

First, thank you for your review.  I personally appreciate to the time
you put in to all of your reviews.

On 1/27/14, 3:06 AM, Black, David wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

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

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

 Document: draft-ietf-qresync-rfc5162bis-09
 Reviewer: David L. Black
 Review Date: January 26, 2014
 IETF LC End Date: January 27, 2014

 Summary:
 This draft is basically ready for publication, but has minor issues that
 should be fixed before publication.

 This draft consolidates RFC 4551 (IMAP Conditional STORE) and RFC 5162
 (IMAP Quick Mailbox Resynchronization) into a single document and makes
 a few minor updates.  It also updates the command line length
 recommendation in RFC 2683 to support the longer command lines that
 can occur with these extensions.

 As this is an update, I checked the diffs against RFC 4551 and RFC 5162;
 they look reasonable.  I found one minor issue that should be relatively
 easy to address.

 Minor Issues:

 The command line length change in Section 4 applies to all IMAP commands,
 and hence affects old servers, including those that don't implement either
 of the extensions in this draft. That raises a backwards compatibility
 concern - what happens when a new client sends a  1000 character command
 line to an old server that isn't expecting more than 1000 characters?

As the draft indicates, this is problematic for the two extensions in
question. We have discussed this limitation in the working group, and
nobody seems to be concerned.  That's due to two factors, I think:
first, RFC 2683 is not normative (informational).  I am unaware of any
strict line length limitation in RFC 3501, for instance.  Instead, there
is a requirement for strict syntax parsing.  If the client blows it in
any way, the server SHOULD return an error with a BAD response.

This having been said, while the working group has discussed this
matter, it would be good to hear any additional voices of concern, in
the interests of interoperability.

This takes us to your next point:


 One possibility would be to apply the larger length recommendation only
 after the client determines that the server supports at least one of
 these extensions.

 Nits/editorial comments:

 The update to RFC 2683 would be easier to find from the table of contents
 if the title of Section 4 were changed to Long Command Lines (Update to
 RFC 2683).

 idnits 2.13.01 got confused by the command line examples, and flagged a
 downref:

   ** Downref: Normative reference to an Informational RFC: RFC 2683

 That downref appears to be ok and intended, as noted in the shepherd's
 writeup.

This will be addressed in a forthcoming update.  Barry has educated us
that really this is NOT an update to RFC2683, where the advice given in
that document is superceded by a specific option.  As such, this error
will evaporate.


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

Re: [Gen-art] [imapext] Gen-ART review of draft-ietf-qresync-rfc5162bis-09

[Eliot Lear]

Hi Barry, Dave, and Alexey,

On 1/27/14, 8:59 PM, Barry Leiba wrote:
 Actually, I think I convinced Barry that it is updating RFC 2683.
 Yes: because the new line-length-limit recommendation is meant to
 apply whether or not condstore or qresync are in play, this updates
 remains (it's the others that used to be there that we scrubbed).

 I think David's right that some version of what Eliot said:

 there
 is a requirement for strict syntax parsing.  If the client blows it in
 any way, the server SHOULD return an error with a BAD response.
 ...should be added to the section about the line-length limit.  A
 sentence or two should do nicely.



I don't see a problem, but for context I was really just borrowing from
RFC 3501, which already states that SHOULD (Section 2.2 if memory
serves).  Stating it again won't hurt.

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

Re: [Gen-art] Gen-Art telechat review of draft-farrell-perpass-attack-04

[Eliot Lear]

Jari,

I oppose changes made to the document in the last round as stated
below.  If they remain, I would urge publication as Informational and
not BCP:

In particular, architectural decisions, including which existing
technology is re-used, may significantly impact the vulnerability of
a protocol to PM.  Those developing IETF specifications therefore
need to consider mitigating PM when making these architectural
decisions and be prepared to justify their decisions.  Getting
adequate, early review of architectural decisions including whether
appropriate mitigation of PM can be made is important.  Revisiting
these architectural decisions late in the process is very costly.

In the fact of a lack of common understanding regarding the threat, this
text can subject a working group to abuse and confusion.  This isn't
theoretical, as it has happened in the past that working group chairs
and area directors in particular have derailed efforts, setting
standardization and deployment of useful technology back years, and this
wasn't that long ago.

Let's make this discussion concrete with a few examples: the
implications may be that a working group chair or any participant
(although chairs are in a very good position to cause damage) could
insist that DHCP not be used to carry new attributes because there is no
common understanding of the scope of remediation that will be required. 
Before certain ADs roll their eyes, the discussion gets derailed as follows:

 I propose the following DHCP option to configure my new frob.
 But DHCP is transmitted in the clear.  Please justify this decision.
(or worse)  and by the way here is my very heavy weight alternative
that requires a valid cert chain
 It's meant for the local wire.
 But we don't know the scope of the attack.
...
...
 Nevermind, I'll just use a vendor extension.  Goodbye.

Rinse and repeat with any other protocol that allows extensions.

It is fair to say that we should consider this threat at an
architectural level.  It's fair (albeit a truism) that finding design
flaws earlier in the process rather than later is less costly
(ENG-101).  Justification language like the above, however, is likely to
actively impede the IETF, as these sorts of things have in the past.

Eliot
___
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-kitten-sasl-openid-06.txt

[Eliot Lear]

Hi Brian,

Apologies for the belated review.  Please see comments below.

On 7/22/64 8:33 PM, Brian E Carpenter wrote:
 Please see attached review.


 some sort of...   any number of ways This is very loose language
 for a standards-track draft. I don't know what to suggest but it
 just seems too vague as it is. If all you can actually specify is
 a transport mechanism, then shouldn't the specification avoid hand-waving
 on other matters?

The issue is that OpenID was designed where you could serialize with
cookies.  You can't do that with a non-browser app in the middle. 
Still, the matter is internal to the RP.  There is no need for the
information to be interpreted by other parties, and as such we ought not
specify its form.  If you would like I can add some text around this
since it seems to be a point of confusion.

 
  2.2.  Discussion
 
 As mentioned above OpenID is primarily designed to interact with web-
 based applications.  Portions of the authentication stream are only
 defined in the crudest sense.  That is, when one is prompted to
 approve or disapprove an authentication, anything that one might find
 on a browser is allowed, including JavaScript, fancy style-sheets,
 etc.  Because of this lack of structure, implementations will need to
 invoke a fairly rich browser in order to ensure that the
 authentication can be completed.

 Errm what? Fairly rich is a useless statement from a specification PoV.
 And in any case, Section 2 is Applicability for non-HTTP Use Cases,
 so I don't understand what JS, style-sheets or browsers have to do
 with it.

The whole point of this mechanism is for non-browser apps to leverage
browsers for their authentication.  Note that you are quoting
discussion, and that any implementer would understand the context of
what that means (especially given the previous sentence).


 The second sentence seems to be missing a noun after astute. But more
 profoundly, this paragraph really isn't OK for a technical specification.
 It mixes up a vague explanation of server behaviour with an imprecise
 discussion of a solution not adopted. Could the paragraph be rewritten
 in a style that will help an implementor write code? Is it saying that
 on receipt of an = response the server should continue to wait?

We fixed the nit.  However, your profound comment is directed at
Discussion.  A precise normative specification  as well as an example
follows below the above text.

 Why is kitten-sasl-openid
 on the standards track when it depends on a document that clearly
 could have
 been proposed as standards track but wasn't?

No attempt is made here to back door standardize OpenID, but rather to
simply make it available to SASL applications.

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

Re: [Gen-art] Gen-art review of draft-lear-iana-timezone-database-03

[Eliot Lear]

Hi Elwyn,

Thank you again for the review.  Please see below.

 Summary:
 Almost ready for the IESG.  This is my second review of the document.  

 I suggested in the previous review that it might make life easier, 
 particularly 
 if an appeal was ever entered, if the document didn't use the RFC 5226 
 Designated 
 Expert mechanism but defined the role separately.  This hasn't happened but 
 the 
 distinction is now clearer.  To make it quite clear I would be inclined to 
 add 
 'except as regards appeals against decisions of the Designated Expert 
 (see Section 5)' after [RFC5226] in the definition of TZ Coordinator in 
 Section 2.

I've adopted your above suggested wording.

 Otherwise there are a couple of editorial nits.   

 .
 Nits/Editorial:
 s3: s/policy policy/policy/ (repeated word)

Corrected.
 s8, first para: s/filling/filling the role/ (maybe 'post')

This text changed based on another review.

 s8, last para: s/TZ Coordinators/TZ Coordinator/

Corrected.
 s10: s/Elwin/Elwyn/ (thanks for the ack!)

Corrected and apologies! I hate when that happens to me!

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

Re: [Gen-art] Gen-art review of draft-lear-iana-timezone-database-01

[Eliot Lear]

Elwyn, SM,

Thank you for your reviews.  Here is my current thinking:

1.  There was probably some confusion in that we probably meant section
5.2 and not 5.3 in RFC 5226.  Nevertheless, I find RFC 5226 difficult to
apply here because of the way it is worded.  Specifically, it is
designed for assignment purposes and not for change purposes.  Hence,
I've removed most references to 5226.  To be clear, the TZ coordinator
should be given great deference, but that in limited circumstances
appeals to the IESG must be allowed (one could imagine a designated
expert who went crazy and took sides in a political fight, for instance).

2.  Clearly there is a need for criteria for updating the database. 
We're going to take a swing at that.

3.  The licensing terms listed in the current draft seem to satisfy
almost nobody.  Therefore they have to be redone.  I have asked for
opinions on this very subject from one or two knowledgeable people, and
hope to have a new proposal before the draft cut-off date.

4.  I've accepted your minor point and your nits.

Eliot

On 1/13/11 2:13 AM, SM wrote:
 Hi Elwyn,
 At 09:10 12-01-11, Elwyn Davies wrote:
 This document is not quite ready for the IESG.  The appeals process (if
 there is to be one) needs to clarified as it currently points indirectly
 to a hole in RFC 5226. As explained below, I have a feeling that it
 would be wise to avoid tying the processes in this document to the
 Designated Expert processes in RFC 5226 despite the similarities.
 Making it clear what does apply and what doesn't is probably more work
 than doing it from scratch in this document, especially given the hole
 in RFC 5226.

 [snip]

 I think the draft should make it explicit that it is referring to the
 'Designated Expert' sections in RFC 5226 here if it continues to
 reference RFC 5226 - although there is a clear relationship with
 Designated Experts, the differences between the selection process and
 the operations of the TZ Coordinator and generic Deisgnated Experts may

 Yes, there are significant differences.  According to RFC 5226:

   The designated expert is responsible for initiating and coordinating
the appropriate review of an assignment request.

 It might be helpful to get some feedback from IANA and the IETF Trust
 on this draft before it is evaluated by the IESG.

 mean that citing RFC 5226 might lead to legalistic disputes about which
 set of rules applies.  Also, I am unable to find statements in RFC 5226
 backing up the sentence above.  Regrettably, RFC 5226 appears
 effectively to have a 'dsngling reference' in this area. Section 3.2,
 para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses
 'disputes and appeals in more detail'.  However s5.2 is titled 'Updating
 Registrations' and says nothing about appeals and disputes.  Section 7
 of RFC 5226 covers appeals of IANA decisions but says nothing specific
 about appealing designated expert rulings.  I think this area may need a
 little more work.  Overall, my inclination would be to make this a
 standalone document that does not try to partially modify the RFC 5226
 Designated Expert process and operations.  Appeals... *sigh*.

 Section 7 of RFC 5226 states that:

   Appeals of registration decisions made by IANA can be made using the
normal IETF appeals process as described in Section 6.5 of
[IETF-PROCESS].

 Section 4 of mentions that:

   In keeping with [RFC5226], the IESG selects the TZ
coordinator(s).  The IESG will use rough consensus of the TZ mailing
list as their primary guide to further action, when it exists, and
whatever other means they have at their disposal, when rough
consensus cannot be found.  As RFC-5226 states, the IESG is not a
normal avenue for appeals of specific decisions of the coordinator,
but rather a last resort when a coordinator is thought not to be
functioning in an appropriate way.

 That could be rewritten as:

The IESG selects the TZ coordinator(s).  The IESG will use the rough
consensus of the TZ mailing list as their primary guide for any
 action,
when it exists, and whatever other means they have at their disposal,
when rough consensus cannot be found.

The IESG is not an avenue for appeals of specific decisions of the
coordinator, but rather a last resort when a coordinator is thought
 not
to be functioning in an appropriate way.  An appeal can be made in
 such
a case by using the normal IETF appeals process as described in
 Section
6.5 of RFC 2606.

 The following sentence in Section 1.1 might have to be removed then:

   The TZ coordinatior is a Designated Expert, as defined in [RFC5226]

 Regards,
 -sm

___
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-dusseault-http-patch-15.txt

[Eliot Lear]

On 11/15/09 11:54 PM, Roy T. Fielding wrote:

On Nov 15, 2009, at 12:03 PM, John C Klensin wrote:

   

Hi.

fwiw, I find myself strongly agreeing with what I believe is
Brian's main point, although what I infer from it may be a
little different from what he does (or may not... I'm not sure):

We should not be adopting a patch protocol that lacks both the
tools for, or a serious discussion of, transactional integrity.
 

John, HTTP is not SQL.
   


+1.  Right tool for the right job, please.

Eliot
___
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-dusseault-http-patch-15.txt

[Eliot Lear]

Brian,


As far as I can tell, the proposal places the burden for ensuring
atomicity entirely on the server. However, PATCH is explicitly not
idempotent. If a client issues a PATCH, and the server executes the PATCH,
but the client then fails to receive an indication of success due to
an extraneous network glitch (and TCP reset?), then what prevents the client
issuing the same PATCH again? In other words, absent a two-phase commit,
there appears to be no transactional integrity.
   


I think Lisa should respond to this as well.  One of the issues here is 
that I believe there is an assumption that there will be some external 
means to know that in fact the PATCH succeeded, like for instance 
retrieving the impacted web pages and comparing results.  In thinking 
about this again, however, perhaps that may not be sufficient, if for 
instance, PATCH is used for purposes of a side effect that is not easily 
verified.  At that point you probably want something a kin to a 
transaction ID where you can check against that ID  to deterine if it 
had succeeded.


An alternative view, however, would be that for a specific object type 
where that is important, one could imbed such a transaction ID 
somewhere.  That's not so easy for common objects we retrieve today (you 
would have to add some sort of meta tag into an HTML doc, and who knows 
what you would do with images), but since those objects could easily be 
retrieved and compared, they're not the problem.


Put this another way: I don't think PATCH is a replacement for all the 
network database protocols and mechanisms that exist today, but simply 
closer to what it is named: a means to patch one or more objects.


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

[Gen-art] Re: genart review Re: [IANA #48214] RE: Last Call: 'A Timezone Option for DHCP' to Proposed Standard (draft-ietf-dhc-timezone-option)

[Eliot Lear]

Dear Eric,

Thank you for your review.  Please see the attached note from IANA.  Can 
you assist me in reconciling your note and theirs?  If I read their note 
correctly, they have sufficient information.  Is this not the case?


Eliot

Eric Gray (LO/EUS) 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-dhc-timezone-option-05.txt

A Timezone Option for DHCP

Reviewer: Eric Gray
Review Date: 2007.01.11
IETF LC End Date: 2007.01.11

Summary: 

This document is almost ready for publication as a Proposed 
Standard.  There is one issue that may need to be addresed.
Additional, minor, comment(s) and or NITs may be addressed 
at the author's or AD's discretion.


Comments: 


Issue - section 10 should specifically identify the values
that need to be assigned by IANA.  In fact, at some point,
it will be necessary to provide IANA with the substance of
any notes that should be added to the registry.

I recommend adding a specific note to this section and use
variable names to allow the RFC editor to easily update the
RFC with the values IANA provides.  It seems likely that it
should be sufficient simply to list the names used for the
values needed.

From my review, it appears that IANA needs to assign values
PCode and TCode identified in section 2 (New Timezone 
Options for DHCPv4), and OPTION_NEW_POSIX_TIMEZONE and
OPTION_NEW_TZDB_TIMEZONE identified in section 6 (New 
Timezone Options for DHCPv6).


I would suggest adding text similar to the following -

The values required are:

For DHCPv4 (section 2 of this memo)

PCode
TCode

For DHCPv6 (section 3 of this memo)

OPTION_NEW_POSIX_TIMEZONE
OPTION_NEW_TZDB_TIMEZONE

===

NIT - in the abstract, ... DHCP options each ... should be
... DHCP options for each ... (for added).

  


---BeginMessage---
IESG:

The IANA has reviewed the following Internet-Draft which is in Last
Call: draft-ietf-dhc-timezone-option-05.txt, and has the following 
comments/questions with regards to the publication of this document:

Upon approval of this document, the IANA will make three 
changes to the registries that support DHCP:

First, in the registry located at:
http://www.iana.org/assignments/bootp-dhcp-parameters
in the subregistry named, BOOTP Vendor Extensions and DHCP 
Options, two new values will be added:

Data 
Tag Name Length Meaning
---  -- ---
TBD PCode N IEEE 1003.1 String 
TBD TCode N Reference to the TZ Database

Second, in the registry located at:
http://www.iana.org/assignments/bootp-dhcp-parameters
in the subregistry named, BOOTP Vendor Extensions and 
DHCP Options, option 2 will be changed from:

Data 
Tag Name Length Meaning
---  -- ---
2 Time Offset 4 Time Offset in 
Seconds from UTC 

to the following:

Data 
Tag Name Length Meaning
---  -- ---
2 Time Offset 4 Time Offset in 
Seconds from UTC (note: deprecated by
TBA and TBA; see reference)

With reference changed to reflect the approved document.

Third, in the registry located at:
http://www.iana.org/assignments/dhcpv6-parameters
in the subregistry titled, DHCP Option Codes, two 
new values will be added:

Value Description 
- -- 
TBD OPTION_NEW_POSIX_TIMEZONE
TBD OPTION_NEW_TZDB_TIMEZONE

We understand the above to be the only IANA Actions 
for this document.

Thank you.

Yoshiko Chong
(on behalf of IANA)


 -- Forwarded Message
 From: The IESG [EMAIL PROTECTED]
 Reply-To: iesg@ietf.org
 Date: Mon, 11 Dec 2006 09:48:29 -0500
 To: IETF-Announce ietf-announce@ietf.org
 Cc: dhcwg@ietf.org
 Subject: [Iana-rfcs] Last Call: 'A Timezone Option for DHCP' to Proposed
 Standard (draft-ietf-dhc-timezone-option)
 
 The IESG has received a request from the Dynamic Host Configuration WG
 to consider the following document:
 
 - 'A Timezone Option for DHCP '
draft-ietf-dhc-timezone-option-05.txt as a Proposed Standard
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action.  Please send any comments to the
 iesg@ietf.org or ietf@ietf.org mailing lists by 2006-12-31.
 
 The file can be obtained via
 http://www.ietf.org/internet-drafts/draft-ietf-dhc-timezone-option-05.txt
 
 
 ___
 IETF-Announce mailing list
 IETF-Announce@ietf.org
 https://www1.ietf.org/mailman/listinfo/ietf-announce
 
 ___
 Iana-rfcs mailing list
 [EMAIL PROTECTED]
 https://rs.icann.org/mailman/listinfo/iana-rfcs
 
 -- End of Forwarded Message
 
 


---End Message---
___
Gen-art mailing list
Gen-art@ietf.org