Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Suresh Krishnan]

Hi Mike,

On Feb 10, 2017 11:30 PM, "C. M. Heard"  wrote:

On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best serve both our future and our heritage
> > > > if we declared RFC1981 as historic, and either left the idea there,
> > > > or declared it as historic and wrote a new text from a clean start?
> > >
> > > I don't see that. It's a stable, widely deployed, interoperable
> > > mechanism. That is rather orthogonal to the issue that has been
raised,
> > > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > > across the Internet.
> >
> > I will not debate whether it is faulty or not,
>
> It's faulty by the standard of RFC4890 (which is Informational).
>
> > but it seems that in practice the Internet breaks the mechanism.
> > However it breaks it is a way that seems disruptive to some user
> > traffic. The document is really guidance one how hosts might use
> > ICMP for optimization, and arguabl[y] need not be a standard at all.
>
> I think that's a mischaracterisation of the mechanism (and the draft).
> PMTUD is not an optimisation. Without it, you get black holes.

Actually, no. You do not have to use PMTUD to avoid black holes.
Other options include:

- Send packets no larger than 1280 bytes (this is always an option)
- Use PLPMTUD (for transports that do their own packetization and
  that can detect packet loss)


How does this work for UDP?


> > My remark about heritage is that this vintage draft is very much a
> > product of its time, and really needs modernizing, and after
> > modernizing ought to look quite different, and thus maybe we
> > should employ a procedure other than a simple replacement.

I am afraid that I have to agree with this. Classic PMTUD by itself
is today not enough, but it can be a very useful optimization to
augment other techniques.


OK.


> It's proposed for Internet Standard. That means it must replace the
> PS document and must specify the same thing, plus corrections,
> minus unused features.

All true, and my conclusion is that is it should not be promoted to IS.


What criteria for advancement to IS do you think are not met by this
document?

I would have no problem with republishing at PS to correct the errata
and aid the eventual advance of RFC 4821 (PLPMTUD).

If this document does go forward, the words in Appendix B (Changes
Since RFC 1981) relating to RFC 4821 should be removed, since
there was no mention of RFC 4821 in RFC 1981.


Not sure I understand your concern. This is a change log since RFC1981. And
it is a fact that the reference to RFC4821 was added into this draft. Can
you clarify?

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

Re: [Gen-art] Review of draft-ietf-mmusic-sctp-sdp-23

[Christer Holmberg]

Hi Brian,

I will fix the case in the next version.

Thanks! 

Regards,

Christer 



Sent from my iPhone

> On 11 Feb 2017, at 1.06, Brian Carpenter  wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready
> 
> Gen-ART telechat review of draft-ietf-mmusic-sctp-sdp-23
> 
> 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-mmusic-sctp-sdp-23.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-02-11
> IETF LC End Date: 2017-02-09
> IESG Telechat date: 2017-02-16
> 
> Summary: Ready
> 
> 
> Comment:
> 
> 
> Thanks for handling my Last Call comments.
> 
> Nit:
> 
> 
> Thanks for the IPv6 example. But RFC5952 recommends 
> lower case as the canonical form: 2001:db8::a8fd
> 

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[C. M. Heard]

On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best serve both our future and our heritage
> > > > if we declared RFC1981 as historic, and either left the idea there,
> > > > or declared it as historic and wrote a new text from a clean start?
> > >
> > > I don't see that. It's a stable, widely deployed, interoperable
> > > mechanism. That is rather orthogonal to the issue that has been raised,
> > > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > > across the Internet.
> >
> > I will not debate whether it is faulty or not,
>
> It's faulty by the standard of RFC4890 (which is Informational).
>
> > but it seems that in practice the Internet breaks the mechanism.
> > However it breaks it is a way that seems disruptive to some user
> > traffic. The document is really guidance one how hosts might use
> > ICMP for optimization, and arguabl[y] need not be a standard at all.
>
> I think that's a mischaracterisation of the mechanism (and the draft).
> PMTUD is not an optimisation. Without it, you get black holes.

Actually, no. You do not have to use PMTUD to avoid black holes.
Other options include:

- Send packets no larger than 1280 bytes (this is always an option)
- Use PLPMTUD (for transports that do their own packetization and
  that can detect packet loss)

> > My remark about heritage is that this vintage draft is very much a
> > product of its time, and really needs modernizing, and after
> > modernizing ought to look quite different, and thus maybe we
> > should employ a procedure other than a simple replacement.

I am afraid that I have to agree with this. Classic PMTUD by itself
is today not enough, but it can be a very useful optimization to
augment other techniques.

> It's proposed for Internet Standard. That means it must replace the
> PS document and must specify the same thing, plus corrections,
> minus unused features.

All true, and my conclusion is that is it should not be promoted to IS.
I would have no problem with republishing at PS to correct the errata
and aid the eventual advance of RFC 4821 (PLPMTUD).

If this document does go forward, the words in Appendix B (Changes
Since RFC 1981) relating to RFC 4821 should be removed, since
there was no mention of RFC 4821 in RFC 1981.

Mike Heard

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

[Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-08

[Pete Resnick]

Reviewer: Pete Resnick
Review result: Ready with Nits

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-ccamp-flexible-grid-ospf-ext-08
Reviewer: Pete Resnick
Review Date: 2017-02-10
IETF LC End Date: 2017-01-31
IESG Telechat date: 2017-02-16

Summary: Ready with Nits

A couple of nits that I mentioned in my earlier review that you might
want to address, but none of them are essential. (You may have decided
that I was wrong; that's OK too.) I didn't bother Cc'ing the IETF list
on this, since they're both very minor.

Major issues: None

Minor issues: None

Nits/editorial comments: 

3.1:

   A set of non-overlapping available frequency ranges MUST be 
   disseminated in order to allow efficient resource management of 
   flexi-grid DWDM links and RSA procedures which are described in 
   Section 4.8 of [RFC7698]. 

Those MUSTs look weird to me. I think instead of "MUST be" you mean
"are", since it doesn't look like an implementation really has a
choice here.

3.2:

   Hence, in order to support all possible applications and 
   implementations the following information should be advertised for
   a flexi-grid DWDM link:
   
Is that "should" in there meant to be normative? That is, do bad
things happen if I don't advertise one of those items? Or do you just
mean "the following information is advertised..."? 



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

[Gen-art] Review of draft-ietf-mmusic-sctp-sdp-23

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready

Gen-ART telechat review of draft-ietf-mmusic-sctp-sdp-23

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-mmusic-sctp-sdp-23.txt
Reviewer: Brian Carpenter
Review Date: 2017-02-11
IETF LC End Date: 2017-02-09
IESG Telechat date: 2017-02-16

Summary: Ready


Comment:


Thanks for handling my Last Call comments.

Nit:


Thanks for the IPv6 example. But RFC5952 recommends 
lower case as the canonical form: 2001:db8::a8fd

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

Re: [Gen-art] Review of draft-ietf-dmm-4283mnids-04

[Charlie Perkins]

Hello Dale,

Thanks for the thorough review.  My follow-up comments are inline below.


On 1/31/2017 11:34 AM, Dale Worley wrote:

1. The Introduction states

Other types of identifiers are in
common use, and even referenced in RFC 4283.

For the reader's sanity, some sort of accounting needs to be made of
these "other types of identifiers", especially because each type of
identifier needs an identifier type number.  The text in 4283 is

Some examples of identifiers
include Network Access Identifier (NAI), Fully Qualified Domain
Name
(FQDN), International Mobile Station Identifier (IMSI), and Mobile
Subscriber Number (MSISDN).

Are there any other types "in common use"?


I will add some text according to your suggestion.  My criterion for 
whether the identifier type was included in the document was whether or 
not anyone had asked for it to be included.




- NAI (type 1) is defined by 4283.
- Fully Qualified Domain Name (FQDN) seems not to be specified
- International Mobile Station Identifier (IMSI) (type 3) is defined
in
   this draft
- Mobile Subscriber Number (MSISDN) seems not to be specified


It is not the jurisdiction of the MNIDs document to specify these 
identifiers, but citations for the specifications are located elsewhere 
in the document.  I will also include those citations here.




2. Is it intended to have an IMEI identifier type?  The introduction
mentions an IMEI type, but there is no specification for it, nor is
there an identifier type number assigned for it.

... types for IMSI
[ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
GUTI
[ThreeGPP-IDS].

Initially I suspected it was it was present in an earlier revision
and
then later deleted without this reference being updated.  But all
versions of draft-ietf-dmm-4283mnids and its predecessor
draft-perkins-dmm-4283mnids mention IMEI in this way as one
identifier
type, but none specify it in any way.  The only discussion I can find
on the DMM mailing list of IMEI is:


https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid=d29575f767ce67a1e67a7767008ee6af


 From: Marco Liebsch 
 To: DMM
 Date: Wed, 10 September 2014 13:29 UTC
 Re: [DMM] regarding the re-chartering..

 It seems the MNID is somehow overloaded to carry both,
node-specific
 IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI.
 There may be value in adding the IMEI to the list of possible
types of
 node-specific IDs.

Either the presence of IMEI in this list is a simple mistake that has
persisted in all versions of the draft, or specifying IMEI has always
been intended but has always been overlooked.


I don't know why this happened, but I am happy to include an identifier 
type for IMEI as well as a citation for it.  Thanks for catching this 
and looking through the archives!




3. The definition of identifier types for both EUI-48 and EUI-64
suggests that it might be desirable to define an identifier type for
arbitrary hardware (link-level) addresses.  It seems that the natural
differentiator for that purpose is the "hardware type" used in ARP,
so
a EUI-48 address would be represented as

 MN identifier type (one octet) 5 (say)
 hardware type (two octets) 1
 EUI-48 (six octets)

and an EUI-64 similarly, with hardware type 27.

Although with only two subtypes in common use, generalizing this
might
not be worth the effort.


Actually, I am O.K. either way on this matter.  However, at this point 
in time it does not seem that we are likely to see any other link 
hardware address types to be used as MNIDs.




4. Several of the identifier types can be represented as URNs:

- IMEI can be represented as a URN as urn:gsma:imei:...
- all of the RFID types have a URN representation (called the
   "pure-identity URI" in the RFID specifications), which starts
   urn:epc:id:...

Since all URN types are ensured of being unique and persistent, it
seems that we could define a MNID type for URNs generally, and then
any RFID URI or an IMEI (as a URN) could be used as a value of that
type.

If this idea is adopted, it seems that the other 3GPP types (IMSI,
P-TMSI, and GUTI) should be given defined encodings as URNs in new
sub-namespaces of the "gsma" URN namespace, to parallel the encoding
of IMEIs defined in RFC 7254.

This consolidation could be significantly beneficial.  It allows MNID
to use any URN scheme as an identifier.  It reduces the three
different RFID representations to one.  It incorporates any future
expansion of RFID schemes (because all schemes will have a
pure-identity URN representation).  A disadvantage is that the URN
encodings are long, but the security considerations section states
that MNIDs are used only on the first registration at the home agent,
so there isn't much need for brevity.

Similarly, this approach incorporates any future expansion of mobile
identifiers that GSMA decides to define, as long as GSMA 

[Gen-art] Gen-ART Last Call review of draft-ietf-dmm-hnprenum-05

[Meral Shirazipour]

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-dmm-hnprenum-05
Reviewer: Meral Shirazipour
Review Date: 2017-02-10
IETF LC End Date:   2017-02-10
IESG Telechat date: -


Summary:
This draft is ready to be published as Standards Track RFC but I have comments.

Major issues:
Minor issues:
Nits/editorial comments:
-Abstract:
Current:
"However, the current PMIPv6 specification does not specify related operations 
when an HNP renumbering is happened.".
Suggestion for more clarity:
"However, the current PMIPv6 specification does not specify related operations 
when an HNP renumbering has happened (e.g. due to change of service provider, 
change of site topology, etc.).".
-[Page 3], "to an MAG">"to a MAG"

-[Page 7], "the proceduer"--->"the procedure"

Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Brian E Carpenter]

On 10/02/2017 23:20, Stewart Bryant wrote:
> 
> 
> On 10/02/2017 03:25, Brian E Carpenter wrote:
>> Stewart,
>>
>> On 10/02/2017 04:19, Stewart Bryant wrote:
>> ...
>>> I wonder if we would best serve both our future and our heritage
>>> if we declared RFC1981 as historic, and either left the idea there,
>>> or declared it as historic and wrote a new text from a clean start?
>> I don't see that. It's a stable, widely deployed, interoperable
>> mechanism. That is rather orthogonal to the issue that has been raised,
>> which is that faulty ICMPv6 filtering blocks it on many, many paths
>> across the Internet.
> 
> I will not debate whether it is faulty or not, but it seems that in 

It's faulty by the standard of RFC4890 (which is Informational).

> practice the
> Internet breaks the mechanism. However it breaks it is a way that seems
> disruptive to some user traffic. The document is really guidance
> one how hosts might use  ICMP for optimization, and arguable need
> not be a standard at all.

I think that's a mischaracterisation of the mechanism (and the draft).
PMTUD is not an optimisation. Without it, you get black holes.

> 
> My remark about heritage is that this vintage draft is very much a 
> product of
> its time, and really needs modernizing, and after modernizing ought to
> look quite different, and thus maybe we should employ a procedure
> other than a simple replacement.

It's proposed for Internet Standard. That means it must replace the
PS document and must specify the same thing, plus corrections, minus
unused features.

>> ...
>>> It is concerning that the draft does not talk in any detail about
>>> how modern ECMP works, i.e. using the five tuple, and noting that
>>> the PMTU may be different depending on the transport layer port
>>> numbers.
>> Has this problem been analysed for, say, IPv4? And does the real world
>> contain ECMP setups with different MTUs on different paths?
> 
> I don't know if anyone has looked. Since the mechanism is 
> self-correcting albeit
> with some disruption to user traffic it looks to the application and the 
> application
> user, just like the Internet not working for a few moments.
> 
> In a well managed SP network there should not be, but neither should there
> be asymmetric path costs, but there are. The less well manage private
> networks are less well managed.
> 
> 
>>
>>> Given that a very large fraction of packets will traverse an MPLS
>>> network at some point, I am surprised that there is no text talking
>>> about the importance of providing support for this feature in the
>>> MPLS domain. RFC3988 talks to this point, but is only experimental.
>> I don't understand. How does the fact that there might be some MPLS
>> segments along the path affect end-to-end PMTUD?
> 
> The point that RFC3988 makes is that MPLS looks like a single hop to IP 
> and the
> PE has to fragment or has to reply with an ICMP error message to support
> PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to 
> result
> in the right response at the end node.
> 
> My point is that the draft is silent on the subject, and perhaps it 
> should not be.

Well, in general it's silent on tunnels. They have to emulate links,
as stated in section 2. I still don't see why an MPLS tunnel is a special case.

> 
> However your question make me ask a further question. The draft is also 
> silent
> on NATs. Is there any advice needed for people designing and configuring 
> NATs?

Yes, for NAT64/NAT46 - in RFC6145. For NAT66, the advice is "don't".

>>
>>> ==
>>>
>>> If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
>>> could use the flow id as the local representation of a path. Packets
>>> sent to a particular destination but belonging to different flows may
>>> use different paths, with the choice of path depending on the flow
>>> id.  This approach will result in the use of optimally sized packets
>>> on a per-flow basis, providing finer granularity than PMTU values
>>> maintained on a per-destination basis.
>>>
>>> SB> How widely is flow-id supported in networks? I thought that the
>>> SB> current position was that it was unreliable as an ECMP indicator
>>> SB> and thus routers tended to glean information from the packet themselves.
>> This is future-proofing. Agreed, usage today is limited.
>>
>> (But it would be better to call it the Flow Label for consistency with other
>> recent RFCs.)
> 
> Well the question is whether it is simply limited today, or broken today 
> in a manner that
> is irrecoverable? 

Nothing's broken. It's just underused.

> I don't know, but I do know that the mainstream ECMP
> approach is the five-tuple.

Sure, but see RFC6438 for some of the difficulties that
causes with IPv6.

> There is something akin to the flow label being
> deployed in MPLS. However
> what distinguishes the MPLS Entropy Label is that it is inserted (and 
> removed) by the
> service provider and is therefore trusted by the 

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Templin, Fred L]

Hi, about ECMP I think RFC1981bis should be OK even if ECMP is used in the
network as long as ICMP PTBs are not blocked. RFC1981bis will eventually
converge to the minimum MTU of all paths in the multipath, and so it is
still OK to store the MTU in the network layer where it would be shared
by all flows.

ECMP does present challenges for RFC4821, however. If a first transport
session discovers a large MTU and shares it with a second transport
session, the second session may take a very different path where there
is a smaller MTU and encounter a black hole. IMHO, it might be a good
idea to file an erratum to RFC4821 explaining how ECMP might cause
problems if discovered MTUs are shared between sessions.

Thanks - Fred
fred.l.temp...@boeing.com

> -Original Message-
> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Stewart Bryant
> Sent: Friday, February 10, 2017 2:21 AM
> To: Brian E Carpenter ; Stewart Bryant 
> ; gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> 
> 
> On 10/02/2017 03:25, Brian E Carpenter wrote:
> > Stewart,
> >
> > On 10/02/2017 04:19, Stewart Bryant wrote:
> > ...
> >> I wonder if we would best serve both our future and our heritage
> >> if we declared RFC1981 as historic, and either left the idea there,
> >> or declared it as historic and wrote a new text from a clean start?
> > I don't see that. It's a stable, widely deployed, interoperable
> > mechanism. That is rather orthogonal to the issue that has been raised,
> > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > across the Internet.
> 
> I will not debate whether it is faulty or not, but it seems that in
> practice the
> Internet breaks the mechanism. However it breaks it is a way that seems
> disruptive to some user traffic. The document is really guidance
> one how hosts might use  ICMP for optimization, and arguable need
> not be a standard at all.
> 
> My remark about heritage is that this vintage draft is very much a
> product of
> its time, and really needs modernizing, and after modernizing ought to
> look quite different, and thus maybe we should employ a procedure
> other than a simple replacement.
> 
> 
> > ...
> >> It is concerning that the draft does not talk in any detail about
> >> how modern ECMP works, i.e. using the five tuple, and noting that
> >> the PMTU may be different depending on the transport layer port
> >> numbers.
> > Has this problem been analysed for, say, IPv4? And does the real world
> > contain ECMP setups with different MTUs on different paths?
> 
> I don't know if anyone has looked. Since the mechanism is
> self-correcting albeit
> with some disruption to user traffic it looks to the application and the
> application
> user, just like the Internet not working for a few moments.
> 
> In a well managed SP network there should not be, but neither should there
> be asymmetric path costs, but there are. The less well manage private
> networks are less well managed.
> 
> 
> >
> >> Given that a very large fraction of packets will traverse an MPLS
> >> network at some point, I am surprised that there is no text talking
> >> about the importance of providing support for this feature in the
> >> MPLS domain. RFC3988 talks to this point, but is only experimental.
> > I don't understand. How does the fact that there might be some MPLS
> > segments along the path affect end-to-end PMTUD?
> 
> The point that RFC3988 makes is that MPLS looks like a single hop to IP
> and the
> PE has to fragment or has to reply with an ICMP error message to support
> PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to
> result
> in the right response at the end node.
> 
> My point is that the draft is silent on the subject, and perhaps it
> should not be.
> 
> However your question make me ask a further question. The draft is also
> silent
> on NATs. Is there any advice needed for people designing and configuring
> NATs?
> 
> >
> >> ==
> >>
> >> If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
> >> could use the flow id as the local representation of a path. Packets
> >> sent to a particular destination but belonging to different flows may
> >> use different paths, with the choice of path depending on the flow
> >> id.  This approach will result in the use of optimally sized packets
> >> on a per-flow basis, providing finer granularity than PMTU values
> >> maintained on a per-destination basis.
> >>
> >> SB> How widely is flow-id supported in networks? I thought that the
> >> SB> current position was that it was unreliable as an ECMP indicator
> >> SB> and thus routers tended to glean information from the packet 
> >> themselves.
> > This is future-proofing. Agreed, usage today is limited.
> >
> > (But it would be better to call it the Flow Label for 

Re: [Gen-art] [DMM] Review of draft-ietf-dmm-4283mnids-04

[Suresh Krishnan]

Hi Charlie,

> On Feb 10, 2017, at 10:30 AM, Charlie Perkins  
> wrote:
> 
> Hello folks,
> 
> The last two days have been crammed full with other urgent work requirements. 
>  I will respond to these comments today.

Great.

> 
> Suresh, do you mean to ask if I can submit a revised document before Monday?

No. If you can agree on the changes to be applied with Dale by Monday/Tuesday I 
think it would be great. If there are other comments in IESG eval, you can 
address them as well in a new revision.

Thanks
Suresh



smime.p7s
Description: S/MIME cryptographic signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [DMM] Review of draft-ietf-dmm-4283mnids-04

[Charlie Perkins]

Hello folks,

The last two days have been crammed full with other urgent work 
requirements.  I will respond to these comments today.


Suresh, do you mean to ask if I can submit a revised document before Monday?

Regards,
Charlie P.


On 2/10/2017 6:17 AM, Suresh Krishnan wrote:

Hi Charlie,
   I have not yet seen a response to this review. Do you think you will be able 
to get to this in the next day or two? The document is on the February 16 2017 
telechat and I would like to see resolution to these issues in time for the 
other ADs to ballot.

Thanks
Suresh

On 2/2/17, 1:10 AM, "Charlie Perkins"  wrote:

 Hello Sri,
 
 The review was indeed super.  I'll respond sometime in the next few days.
 
 Regards,

 Charlie P.
 
 
 On 2/1/2017 9:09 PM, Sri Gundavelli (sgundave) wrote:

 > Thank you Dale for a great review.
 >
 >
 > Charlie/Authors - Can you please respond to Dale and address these
 > comments.
 >
 >
 > Regards
 > Sri
 >
 >
 > On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" 
 on behalf of wor...@ariadne.com> 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-ietf-dmm-4283mnids-04
 >> Reviewer:  Dale R. Worley
 >> Review Date:  31 Jan 2017
 >> IETF LC End Date:  2 Feb 2017
 >> IESG Telechat date:  16 Feb 2017
 >>
 >> Summary:
 >>
 >>This draft is on the right track but has open issues,
 >> described
 >>in the review.
 >>
 >> Technical issues:
 >>
 >> 1. The Introduction states
 >>
 >>Other types of identifiers are in
 >>common use, and even referenced in RFC 4283.
 >>
 >> For the reader's sanity, some sort of accounting needs to be made of
 >> these "other types of identifiers", especially because each type of
 >> identifier needs an identifier type number.  The text in 4283 is
 >>
 >>Some examples of identifiers
 >>include Network Access Identifier (NAI), Fully Qualified Domain
 >> Name
 >>(FQDN), International Mobile Station Identifier (IMSI), and Mobile
 >>Subscriber Number (MSISDN).
 >>
 >> Are there any other types "in common use"?
 >>
 >> - NAI (type 1) is defined by 4283.
 >> - Fully Qualified Domain Name (FQDN) seems not to be specified
 >> - International Mobile Station Identifier (IMSI) (type 3) is defined
 >> in
 >>   this draft
 >> - Mobile Subscriber Number (MSISDN) seems not to be specified
 >>
 >> 2. Is it intended to have an IMEI identifier type?  The introduction
 >> mentions an IMEI type, but there is no specification for it, nor is
 >> there an identifier type number assigned for it.
 >>
 >>... types for IMSI
 >>[ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
 >> GUTI
 >>[ThreeGPP-IDS].
 >>
 >> Initially I suspected it was it was present in an earlier revision
 >> and
 >> then later deleted without this reference being updated.  But all
 >> versions of draft-ietf-dmm-4283mnids and its predecessor
 >> draft-perkins-dmm-4283mnids mention IMEI in this way as one
 >> identifier
 >> type, but none specify it in any way.  The only discussion I can find
 >> on the DMM mailing list of IMEI is:
 >>
 >>
 >> 
https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid
 >> =d29575f767ce67a1e67a7767008ee6af
 >>
 >> From: Marco Liebsch 
 >> To: DMM
 >> Date: Wed, 10 September 2014 13:29 UTC
 >> Re: [DMM] regarding the re-chartering..
 >>
 >> It seems the MNID is somehow overloaded to carry both,
 >> node-specific
 >> IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI.
 >> There may be value in adding the IMEI to the list of possible
 >> types of
 >> node-specific IDs.
 >>
 >> Either the presence of IMEI in this list is a simple mistake that has
 >> persisted in all versions of the draft, or specifying IMEI has always
 >> been intended but has always been overlooked.
 >>
 >> 3. The definition of identifier types for both EUI-48 and EUI-64
 >> suggests that it might be desirable to define an identifier type for
 >> arbitrary hardware (link-level) addresses.  It seems that the natural
 >> differentiator for that purpose is the 

[Gen-art] Review Assignments

[Jean Mahoney]

Hi all,

The following reviewers have assignments:

For telechat 2017-02-16

Reviewer   Type  LC end Draft
Brian CarpenterTelechat  2017-02-09 draft-ietf-mmusic-sctp-sdp-23 *
Francis Dupont Last Call 2017-02-14 
draft-freytag-lager-variant-rules-03 *
Orit Levin Last Call 2017-01-31 draft-ietf-sidr-delta-protocol-06
Pete Resnick   Telechat  2017-01-31 
draft-ietf-ccamp-flexible-grid-ospf-ext-08 *
Lucy Yong  Last Call 2017-01-30 
draft-ietf-sidr-rpki-rtr-rfc6810-bis-08

For telechat 2017-03-02

Reviewer   Type  LC end Draft
Stewart Bryant Last Call 2017-02-20 draft-ietf-httpbis-rfc5987bis-04
Francis Dupont Last Call 2017-02-24 draft-kivinen-802-15-ie-04
Francis Dupont Telechat  2017-02-24 draft-kivinen-802-15-ie-04
Jouni Korhonen Last Call 2017-02-13 
draft-ietf-pals-mpls-tp-dual-homing-coordination-05
Meral Shirazipour  Last Call 2017-02-10 draft-ietf-dmm-hnprenum-05
Robert Sparks  Last Call 2017-03-01 draft-ietf-6man-rfc4291bis-07
Robert Sparks  Telechat  2017-01-17 draft-ietf-mpls-residence-time-13 *
Peter Yee  Last Call 2017-03-01 draft-ietf-6man-rfc2460bis-08

Last calls:

Reviewer   Type  LC end Draft
Fernando Gont  Last Call 2017-01-23 draft-ietf-dime-agent-overload-09
Vijay Gurbani  Last Call 2017-02-15 draft-ietf-grow-mrt-add-paths-03
Robert Sparks  Last Call 2017-03-09 draft-leiba-rfc2119-update-01
Dale WorleyLast Call 2017-02-20 
draft-ietf-slim-negotiating-human-language-06

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Francis Dupont
  Roni Even
  Fernando Gont
  Vijay Gurbani
  Wassim Haddad
  Joel Halpern
  Christer Holmberg
  Russ Housley
  Jouni Korhonen
  Paul Kyzivat

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments: 

-- End LC Template --

-- Begin Telechat Template --
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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --


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

Re: [Gen-art] [DMM] Review of draft-ietf-dmm-4283mnids-04

[Suresh Krishnan]

Hi Charlie,
  I have not yet seen a response to this review. Do you think you will be able 
to get to this in the next day or two? The document is on the February 16 2017 
telechat and I would like to see resolution to these issues in time for the 
other ADs to ballot.

Thanks
Suresh

On 2/2/17, 1:10 AM, "Charlie Perkins"  wrote:

Hello Sri,

The review was indeed super.  I'll respond sometime in the next few days.

Regards,
Charlie P.


On 2/1/2017 9:09 PM, Sri Gundavelli (sgundave) wrote:
> Thank you Dale for a great review.
>
>
> Charlie/Authors - Can you please respond to Dale and address these
> comments.
>
>
> Regards
> Sri
>
>
> On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley"  on behalf of wor...@ariadne.com> 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-ietf-dmm-4283mnids-04
>> Reviewer:  Dale R. Worley
>> Review Date:  31 Jan 2017
>> IETF LC End Date:  2 Feb 2017
>> IESG Telechat date:  16 Feb 2017
>>
>> Summary:
>>
>>This draft is on the right track but has open issues,
>> described
>>in the review.
>>
>> Technical issues:
>>
>> 1. The Introduction states
>>
>>Other types of identifiers are in
>>common use, and even referenced in RFC 4283.
>>
>> For the reader's sanity, some sort of accounting needs to be made of
>> these "other types of identifiers", especially because each type of
>> identifier needs an identifier type number.  The text in 4283 is
>>
>>Some examples of identifiers
>>include Network Access Identifier (NAI), Fully Qualified Domain
>> Name
>>(FQDN), International Mobile Station Identifier (IMSI), and Mobile
>>Subscriber Number (MSISDN).
>>
>> Are there any other types "in common use"?
>>
>> - NAI (type 1) is defined by 4283.
>> - Fully Qualified Domain Name (FQDN) seems not to be specified
>> - International Mobile Station Identifier (IMSI) (type 3) is defined
>> in
>>   this draft
>> - Mobile Subscriber Number (MSISDN) seems not to be specified
>>
>> 2. Is it intended to have an IMEI identifier type?  The introduction
>> mentions an IMEI type, but there is no specification for it, nor is
>> there an identifier type number assigned for it.
>>
>>... types for IMSI
>>[ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
>> GUTI
>>[ThreeGPP-IDS].
>>
>> Initially I suspected it was it was present in an earlier revision
>> and
>> then later deleted without this reference being updated.  But all
>> versions of draft-ietf-dmm-4283mnids and its predecessor
>> draft-perkins-dmm-4283mnids mention IMEI in this way as one
>> identifier
>> type, but none specify it in any way.  The only discussion I can find
>> on the DMM mailing list of IMEI is:
>>
>>
>> 
https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid
>> =d29575f767ce67a1e67a7767008ee6af
>>
>> From: Marco Liebsch 
>> To: DMM
>> Date: Wed, 10 September 2014 13:29 UTC
>> Re: [DMM] regarding the re-chartering..
>>
>> It seems the MNID is somehow overloaded to carry both,
>> node-specific
>> IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI.
>> There may be value in adding the IMEI to the list of possible
>> types of
>> node-specific IDs.
>>
>> Either the presence of IMEI in this list is a simple mistake that has
>> persisted in all versions of the draft, or specifying IMEI has always
>> been intended but has always been overlooked.
>>
>> 3. The definition of identifier types for both EUI-48 and EUI-64
>> suggests that it might be desirable to define an identifier type for
>> arbitrary hardware (link-level) addresses.  It seems that the natural
>> differentiator for that purpose is the "hardware type" used in ARP,
>> so
>> a EUI-48 address would be represented as
>>
>> MN identifier type (one octet) 5 (say)
>> hardware type (two octets) 1
>> EUI-48 (six octets)
>>
>> and an EUI-64 similarly, with hardware type 27.
>>
>> Although with only two subtypes in common use, generalizing this
>> might
>> not be worth the effort.
   

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Stewart Bryant]

On 10/02/2017 03:25, Brian E Carpenter wrote:

Stewart,

On 10/02/2017 04:19, Stewart Bryant wrote:
...

I wonder if we would best serve both our future and our heritage
if we declared RFC1981 as historic, and either left the idea there,
or declared it as historic and wrote a new text from a clean start?

I don't see that. It's a stable, widely deployed, interoperable
mechanism. That is rather orthogonal to the issue that has been raised,
which is that faulty ICMPv6 filtering blocks it on many, many paths
across the Internet.


I will not debate whether it is faulty or not, but it seems that in 
practice the

Internet breaks the mechanism. However it breaks it is a way that seems
disruptive to some user traffic. The document is really guidance
one how hosts might use  ICMP for optimization, and arguable need
not be a standard at all.

My remark about heritage is that this vintage draft is very much a 
product of

its time, and really needs modernizing, and after modernizing ought to
look quite different, and thus maybe we should employ a procedure
other than a simple replacement.



...

It is concerning that the draft does not talk in any detail about
how modern ECMP works, i.e. using the five tuple, and noting that
the PMTU may be different depending on the transport layer port
numbers.

Has this problem been analysed for, say, IPv4? And does the real world
contain ECMP setups with different MTUs on different paths?


I don't know if anyone has looked. Since the mechanism is 
self-correcting albeit
with some disruption to user traffic it looks to the application and the 
application

user, just like the Internet not working for a few moments.

In a well managed SP network there should not be, but neither should there
be asymmetric path costs, but there are. The less well manage private
networks are less well managed.





Given that a very large fraction of packets will traverse an MPLS
network at some point, I am surprised that there is no text talking
about the importance of providing support for this feature in the
MPLS domain. RFC3988 talks to this point, but is only experimental.

I don't understand. How does the fact that there might be some MPLS
segments along the path affect end-to-end PMTUD?


The point that RFC3988 makes is that MPLS looks like a single hop to IP 
and the

PE has to fragment or has to reply with an ICMP error message to support
PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to 
result

in the right response at the end node.

My point is that the draft is silent on the subject, and perhaps it 
should not be.


However your question make me ask a further question. The draft is also 
silent
on NATs. Is there any advice needed for people designing and configuring 
NATs?





==

If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
could use the flow id as the local representation of a path. Packets
sent to a particular destination but belonging to different flows may
use different paths, with the choice of path depending on the flow
id.  This approach will result in the use of optimally sized packets
on a per-flow basis, providing finer granularity than PMTU values
maintained on a per-destination basis.

SB> How widely is flow-id supported in networks? I thought that the
SB> current position was that it was unreliable as an ECMP indicator
SB> and thus routers tended to glean information from the packet themselves.

This is future-proofing. Agreed, usage today is limited.

(But it would be better to call it the Flow Label for consistency with other
recent RFCs.)


Well the question is whether it is simply limited today, or broken today 
in a manner that
is irrecoverable? I don't know, but I do know that the mainstream ECMP 
approach
is the five-tuple. There is something akin to the flow label being 
deployed in MPLS. However
what distinguishes the MPLS Entropy Label is that it is inserted (and 
removed) by the

service provider and is therefore trusted by the service provider.



I think your other comments are all valuable.

Thank you.

Stewart

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